Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add namespace field to activation log #4609

Merged
merged 5 commits into from
Sep 26, 2019

Conversation

jiangpengcheng
Copy link
Contributor

Add namespace field to activation log while using DockerToActivationFileLogStore

Description

Currently there is no namespace field but a namespaceId in the activation log while save activation logs to a separate file, while I think add namesapce will be more convenient for users when they process the log file, such as using Logstash to send logs to different indices(e.g. openwhisk-%{namespace}) in ElasticSearch

Related issue and scope

  • I opened an issue to propose and discuss this change (#????)

My changes affect the following components

  • API
  • Controller
  • Message Bus (e.g., Kafka)
  • Loadbalancer
  • Invoker
  • Intrinsic actions (e.g., sequences, conductors)
  • Data stores (e.g., CouchDB)
  • Tests
  • Deployment
  • CLI
  • General tooling
  • Documentation

Types of changes

  • Bug fix (generally a non-breaking change which closes an issue).
  • Enhancement or new feature (adds new functionality).
  • Breaking change (a bug fix or enhancement which changes existing behavior).

Checklist:

  • I signed an Apache CLA.
  • I reviewed the style guides and followed the recommendations (Travis CI will check :).
  • I added tests to cover my changes.
  • My changes require further changes to the documentation.
  • I updated the documentation where necessary.

@rabbah
Copy link
Member

rabbah commented Sep 6, 2019

LGTM but please send to dev list.

@jiangpengcheng
Copy link
Contributor Author

ok, I sent the email

@jiangpengcheng
Copy link
Contributor Author

reopen to trigger the travis check

@sven-lange-last
Copy link
Member

@jiangpengcheng it seems that Travis is frequently failing on this PR - I guess the system test part?

I restarted only the system test part for you because all other Travis tests have passed.

I also had the situation for a lot of my PRs that 3 of 4 Travis checks passed successfully - but only system test was failing. I wonder whether we have an interference between tests such that the system test will always / very likely fail if the other Travis tests are running as well...

@codecov-io
Copy link

codecov-io commented Sep 9, 2019

Codecov Report

Merging #4609 into master will decrease coverage by 5.67%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #4609      +/-   ##
==========================================
- Coverage   84.44%   78.76%   -5.68%     
==========================================
  Files         183      183              
  Lines        8306     8350      +44     
  Branches      572      564       -8     
==========================================
- Hits         7014     6577     -437     
- Misses       1292     1773     +481
Impacted Files Coverage Δ
...abase/ArtifactWithFileStorageActivationStore.scala 91.66% <100%> (+0.75%) ⬆️
...rpool/logging/DockerToActivationFileLogStore.scala 68.08% <100%> (ø) ⬆️
...core/database/cosmosdb/RxObservableImplicits.scala 0% <0%> (-100%) ⬇️
...ore/database/cosmosdb/cache/CacheInvalidator.scala 0% <0%> (-100%) ⬇️
...core/database/cosmosdb/CosmosDBArtifactStore.scala 0% <0%> (-95.89%) ⬇️
...tabase/cosmosdb/cache/CacheInvalidatorConfig.scala 0% <0%> (-94.74%) ⬇️
...sk/core/database/cosmosdb/CosmosDBViewMapper.scala 0% <0%> (-92.6%) ⬇️
...e/database/cosmosdb/cache/ChangeFeedListener.scala 0% <0%> (-86.67%) ⬇️
...e/database/cosmosdb/cache/KafkaEventProducer.scala 0% <0%> (-76.48%) ⬇️
...whisk/core/database/cosmosdb/CosmosDBSupport.scala 0% <0%> (-74.08%) ⬇️
... and 23 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 400a791...5ee2fc6. Read the comment docs.

@sven-lange-last
Copy link
Member

I'm also ok with the changes introduced by this PR.

At the same time, I see that the different classes for providing action container (aka. user) logs are diverging. We have two different strategies to persist user logs in a log store:

  1. The LogStore implementation extracts user logs from the action container (https://github.com/apache/openwhisk/blob/master/common/scala/src/main/scala/org/apache/openwhisk/core/containerpool/logging/LogStore.scala) and returns the extracted logs (collectLogs). As a side effect of the extraction, logs are forwarded to the supported log store. This is what DockerToActivationFileLogStore is doing.

  2. The LogStore implementation extracts user logs from the action container (https://github.com/apache/openwhisk/blob/master/common/scala/src/main/scala/org/apache/openwhisk/core/containerpool/logging/LogStore.scala) and returns the extracted logs (collectLogs). There is no forwarding to a log store (example: DockerToActivationLogStore). The extracted logs are attached to the activation.

The ArtifactActivationStore is responsible for persisting activations (https://github.com/apache/openwhisk/blob/master/common/scala/src/main/scala/org/apache/openwhisk/core/database/ArtifactActivationStore.scala). As a side effect of storing the activation, logs are transformed and forwarded to a log store. With this approach, parts of the activation itself are also forwarded to a log store. Example: ArtifactWithFileStorageActivationStore.

This pull request changes DockerToActivationFileLogStore while it does not cover ArtifactWithFileStorageActivationStore - see this code location:

val additionalFields = Map(config.userIdField -> context.user.namespace.uuid.toJson)

This pull request should probably also cover ArtifactWithFileStorageActivationStore.

At the same time, we cannot expect that this pull request addresses the code duplication of diverging log processing approaches...

@jiangpengcheng
Copy link
Contributor Author

@sven-lange-last
thanks for the review, I wasn't aware of the ArtifactWithFileStorageActivationStore before, and seems it does almost the same thing as the DockerToActivationFileLogStore

and about the checks, the result is strange because all cases are passed in my local env, I didn;t know the reason.

Since close and reopen PRs seems kind of ugly, I wonder whether it's ok to add some "comment" triggers to re-trigger travis build by contributors themself? e.g. "build system", "build unittest".

Copy link
Member

@rabbah rabbah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will a sequence activation have the same set of extra annotations?

@rabbah rabbah mentioned this pull request Sep 12, 2019
20 tasks
@jiangpengcheng
Copy link
Contributor Author

Will a sequence activation have the same set of extra annotations?

@rabbah sorry, I don't get it, what's the annotations do you mean?

@rabbah
Copy link
Member

rabbah commented Sep 20, 2019

Take a look at makeSequenceActivation in SequenceActions.

@jiangpengcheng
Copy link
Contributor Author

I think this PR doesn't related to any annotations but just add a namespace field while write activations/activation logs to a separate file, a "sequence activation" will not do that AFAIK

@sven-lange-last
Copy link
Member

@jiangpengcheng please give me some time to check your latest updates...

JsObject(
Map("type" -> "user_log".toJson) ++ Map("message" -> log.toJson) ++ Map(
"activationId" -> activation.activationId.toJson) ++ Map(
"namespace" -> activation.namespace.asString.toJson) ++ additionalFields)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for attending to my feedback and also covering other log stores.

At the same time: can you please move the namespace extension over to ArtifactWithFileStorageActivationStore? This would be the equivalent class to DockerToActivationFileLogStore where you inject namespace via additionalMetadata.

ActivationFileStorage is just a helper that performs writing of logs and activations to a file. The log store implementations that make use of ActivationFileStorage should decide which additional metadata they want to add. ArtifactWithFileStorageActivationStore is such a log store.

See

val additionalFields = Map(config.userIdField -> context.user.namespace.uuid.toJson)
activationFileStorage.activationToFile(activation, context, additionalFields)

^^ I suggest to inject the additional namespace field here.

Hint: IBM is using the ActivationFileStorage in a private implementation for IBM's logging system that requires different fields unique to IBM that do not make sense in the openwhisk context. That's why we want to keep ActivationFileStorage as open as possible.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess you also need to update this line in the test to inject the namespace field:

val additionalFields = Map(config.userIdField -> context.user.namespace.uuid.toJson)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but then activation will also has an extra "namespace" field, is that ok?

activationToFileExtended(activation, context, additionalFields, additionalFields)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's have a look at the code:

override def store(activation: WhiskActivation, context: UserContext)(
implicit transid: TransactionId,
notifier: Option[CacheChangeNotification]): Future[DocInfo] = {
val additionalFields = Map(config.userIdField -> context.user.namespace.uuid.toJson)
activationFileStorage.activationToFile(activation, context, additionalFields)
super.store(activation, context)
}

If you add the namespace field to the additionalFields map in line 58, it will be persisted to logs via activationFileStorage.activationToFile() in line 60.

The additionalFields map won't be considered when storing the activation to the database (line 61).

Do you come to the same conclusion?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes
what I mean is that when write activation to file, it will also has an additional field "namespace"(alghough this just override the original "namespace" filed of activation):

def activationToFile(activation: WhiskActivation,
context: UserContext,
additionalFields: Map[String, JsValue] = Map.empty): Unit = {
activationToFileExtended(activation, context, additionalFields, additionalFields)
}
// used by external ArtifactActivationStore SPI implementation
def activationToFileExtended(activation: WhiskActivation,
context: UserContext,
additionalFieldsForLogs: Map[String, JsValue] = Map.empty,
additionalFieldsForActivation: Map[String, JsValue] = Map.empty,
includeResult: Boolean = writeResultToFile): Unit = {
val transcribedLogs = transcribeLogs(activation, additionalFieldsForLogs)
val transcribedActivation = transcribeActivation(activation, additionalFieldsForActivation, includeResult)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We clarified the open questions in a personal Slack communication and agreed on a solution.

Copy link
Member

@sven-lange-last sven-lange-last left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for applying recent changes to ArtifactWithFileStorageActivationStore. Changes look good to me now.

Unfortunately, there still is a code formatting issue...

> Task :common:scala:checkScalafmt FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':common:scala:checkScalafmt'.
> Files incorrectly formatted: /home/travis/build/apache/openwhisk/common/scala/src/main/scala/org/apache/openwhisk/core/database/ArtifactWithFileStorageActivationStore.scala
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 1m 17s

@jiangpengcheng
Copy link
Contributor Author

oh, sorry, I missed this file in last commit

Copy link
Member

@sven-lange-last sven-lange-last left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for attend to all feedback. Ready to be merged from my point of view. @rabbah are you ok with merging?

@jiangpengcheng do you want this change to be merged or do you want to add anything?

@jiangpengcheng
Copy link
Contributor Author

nothing to update here

Copy link
Member

@rabbah rabbah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had misunderstood this PR initially as adding a new annotation to the WhiskActivation document (to record the namespace). Thanks Sven for clarifying the change for me. I defer to you on readiness. The changes LGTM.

@sven-lange-last sven-lange-last merged commit a581bea into apache:master Sep 26, 2019
BillZong pushed a commit to BillZong/openwhisk that referenced this pull request Nov 18, 2019
Add the activation namespace to all activation log lines forwarded to external logging solutions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants