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

Treat blackbox action code as attachment #3979

Merged
merged 8 commits into from
Aug 29, 2018

Conversation

chetanmeh
Copy link
Member

Treats blackbox action code as attachment

Description

This is next installment in the attachment saga (previous in this series #3945). With this change code related to blackbox action would also be stored as attachment.

  1. Change is backward compatible in reading code
  2. Upon update or new action being created the code would be stored as attachment

Related issue and scope

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.

@chetanmeh chetanmeh added the wip label Aug 21, 2018
@chetanmeh chetanmeh self-assigned this Aug 21, 2018
@codecov-io
Copy link

codecov-io commented Aug 22, 2018

Codecov Report

Merging #3979 into master will decrease coverage by 4.58%.
The diff coverage is 93.75%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #3979      +/-   ##
==========================================
- Coverage   85.82%   81.24%   -4.59%     
==========================================
  Files         146      146              
  Lines        7084     7095      +11     
  Branches      440      443       +3     
==========================================
- Hits         6080     5764     -316     
- Misses       1004     1331     +327
Impacted Files Coverage Δ
...src/main/scala/whisk/core/entity/Attachments.scala 90.47% <100%> (+1.58%) ⬆️
.../scala/src/main/scala/whisk/core/entity/Exec.scala 82.23% <100%> (+0.53%) ⬆️
...src/main/scala/whisk/core/entity/WhiskAction.scala 86.25% <90%> (+0.15%) ⬆️
...core/database/cosmosdb/RxObservableImplicits.scala 0% <0%> (-100%) ⬇️
...core/database/cosmosdb/CosmosDBArtifactStore.scala 0% <0%> (-95.1%) ⬇️
...sk/core/database/cosmosdb/CosmosDBViewMapper.scala 0% <0%> (-92.6%) ⬇️
...whisk/core/database/cosmosdb/CosmosDBSupport.scala 0% <0%> (-81.82%) ⬇️
...abase/cosmosdb/CosmosDBArtifactStoreProvider.scala 0% <0%> (-58.83%) ⬇️
.../scala/src/main/scala/whisk/core/entity/Size.scala 89.47% <0%> (-5.27%) ⬇️
...la/whisk/core/database/cosmosdb/CosmosDBUtil.scala 92% <0%> (-4%) ⬇️
... and 2 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 1cc3832...00473fa. Read the comment docs.

@chetanmeh chetanmeh removed the wip label Aug 22, 2018
@chetanmeh chetanmeh requested a review from dubee August 22, 2018 08:20
@chetanmeh
Copy link
Member Author

This PR is now ready for review

@chetanmeh
Copy link
Member Author

Rebased to. resolve the conflict. @dubee Would you be able to review this PR?

@markusthoemmes markusthoemmes assigned dubee and unassigned chetanmeh Aug 24, 2018
Copy link
Contributor

@markusthoemmes markusthoemmes left a comment

Choose a reason for hiding this comment

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

Greatly crafted refactorings and enhancement! 🎉

The tests look solid to me and seem to address any migration paths there might be. It also seems like this is roughly the same change as needed when making all actions attachement based and since the migration logic worked there, I'm quite confident it will work here as well.

A second pair of 👀 will make sense though, as I'm not very proficient in this area.

Great job @chetanmeh, very much appreciated 🎉

|}""".stripMargin.parseJson.asJsObject
val action = WhiskAction.serdes.read(json)
action.exec should matchPattern { case BlackBoxExec(_, Some(Inline("foo")), None, false, false) => }
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for testing this!

| }
|}""".stripMargin.parseJson.asJsObject
js shouldBe js2
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice tests, I like 👍

@markusthoemmes
Copy link
Contributor

PG2 3553 👍

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.

LGTM.


private def isBinary(code: JsValue, obj: JsObject): Boolean = {
code match {
case JsString(c) => isBinaryCode(c)
Copy link
Member

Choose a reason for hiding this comment

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

i know you preserved the previous behavior... but should be check for the presence of the binary field first and only if it's missing (indicating an old schema), compute the binary bit?

Copy link
Member Author

Choose a reason for hiding this comment

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

Not sure on that - Current read flow would happen for 2 cases

  1. Deserializing the json obtained from ArtifactStore where the binary flag would have been set at time of serialization
  2. Deserializing the user providing json

Would it fine to trust the binary field if provided by user? Probably yes ... but wanted to check on that

val exec = """{
| "kind": "blackbox",
| "image": "docker-custom.com/openwhisk-runtime/magic/nodejs:0.0.1",
| "code": "while (true)",
Copy link
Member

Choose a reason for hiding this comment

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

do we need another test where this is b64 encoded?

val j1 = """{
| "kind": "blackbox",
| "image": "docker-custom.com/openwhisk-runtime/magic/nodejs:0.0.1",
| "code": "SGVsbG8gT3BlbldoaXNr",
Copy link
Member

Choose a reason for hiding this comment

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

ok you have it here (the b64 test).

| "kind": "blackbox",
| "image": "docker-custom.com/openwhisk-runtime/magic/nodejs:0.0.1",
| "code": "SGVsbG8gT3BlbldoaXNr",
| "binary": false
Copy link
Member

Choose a reason for hiding this comment

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

note binary: false should never be stored in the repo incorrectly (since the system always computes it) --- note this is relevant for my comment above about checking if the binary field exists first.

@dubee dubee merged commit fcd0e4b into apache:master Aug 29, 2018
BillZong pushed a commit to BillZong/openwhisk that referenced this pull request Nov 18, 2019
* Use attachments with BlackBoxExec

* Simplify code to avoid code duplication

* Test for blackbox serialization

* Test for cache for blackbox action
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.

5 participants