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

Openwhisk in a standalone runnable jar #4516

Merged
merged 66 commits into from
Jun 26, 2019

Conversation

chetanmeh
Copy link
Member

@chetanmeh chetanmeh commented Jun 18, 2019

Enables running a minimal OpenWhisk (with in memory store) as a runnable jar outside of docker

Description

Currently users looking to explore OpenWhisk directly have few options like devtools docker compose, mini kube etc. This PR provides yet another option which enables launching a fully working OpenWhisk server via a runnable jar

java -jar openwhisk-standalone-1.0.0-SNAPSHOT.jar

This launches a fully functional OpenWhisk controller and invoker. You can run wsk commands against it and launch and execute actions etc.

image

To try it out currently you can download a pre built jar from here

Design

This PR builds up on lean openwhisk support. It configures OpenWhisk to use a MemoryArtifactStore (thus avoiding nead of a separate CouchDB container) and enables executing the standard wsk commands against it

See also the discussion thread

Key aspects

  • Configured by default to use a MemoryArtifactStore
  • Can be configured to use another store via simple config
  • Delievered as a jar executable
  • Adapts the config as per OS
  • Bootstraps a set of default users (guest and whisk.system)

Usage

First build the standalone module

./gradlew :core:standalone:build

In future

wget maven/openwhisk.jar

Launch the server

$ java -jar openwhisk-standalone-1.0.0-SNAPSHOT.jar -h
OpenWhisk standalone launcher
  -c, --config-file  <arg>   application.conf which overwrites the default
                             whisk.conf
  -m, --manifest  <arg>      Manifest json defining the supported runtimes
  -p, --port  <arg>          Server port
  -h, --help                 Show help message
$ java -jar openwhisk-standalone-1.0.0-SNAPSHOT.jar

When to use

This mode may be benefical in cases like

  • Running simple test against an OpenWhisk server say when testing compositions
  • Faster development cycle - No need to build and relaunch docker container to test out simple changes in regular development flow on OpenWhisk core codebase
  • Easier entrypoint for new users to get a feel of OpenWhisk features

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.

@chetanmeh
Copy link
Member Author

This is an initial version to seek feedback on approach. Based on feedback we can decide what all aspects to support with this approach

@rabbah
Copy link
Member

rabbah commented Jun 18, 2019

cool!

@bdelacretaz
Copy link
Member

Big +1 to this, great work! I do have a use case where we want to simulate OpenWhisk for local development of actions, looks like this would help a lot.

This is required for test run to avoid launched server influenced by whisk.properties generated for the tests
@rabbah rabbah added controller enhancement review Review for this PR has been requested and yet needs to be done. labels Jun 20, 2019
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! this is awesome.

@@ -285,8 +296,10 @@ class MemoryArtifactStore[DocumentAbstraction <: DocumentSerializer](dbName: Str
}

override def shutdown(): Unit = {
artifacts.clear()
attachmentStore.shutdown()
if (!ignoreShutdown) {
Copy link
Member

Choose a reason for hiding this comment

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

worth commenting this - i dont understand why it would be necessary at face value.

@rabbah
Copy link
Member

rabbah commented Jun 20, 2019

Can we add a test for this in Jenkins? Like with lean - stand it up, create/run/delete a single action as a sniff test.

@chetanmeh
Copy link
Member Author

There are still some pending issues like getting log collection to work on Mac. For now implementing an approach which uses docker logs command to fetch logs.

With that change the system test pass percentage improved

108 tests completed, 14 failed

@chetanmeh
Copy link
Member Author

Can we add a test for this in Jenkins? Like with lean - stand it up, create/run/delete a single action as a sniff test.

Yeah working on that. Its bit tricky to get it working in tests project as it needs some different default global config. For now only 14 out of 108 system tests fail

MemoryArtifactStore would always return same instance for same db name
Also ensure that a system property is only set if no existing value found. This ensures that in special case user can still supercede the value being set via explicitly providing a system property override
$ ./gradlew :core:standalone:build
```

This would create the runnable jar in `core/standalone/build/libs/` directory
Copy link
Member

Choose a reason for hiding this comment

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

maybe gradle ...:run to then start the built jar?

Copy link
Member Author

@chetanmeh chetanmeh Jun 25, 2019

Choose a reason for hiding this comment

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

Good point. Now you run the jar directly via $ ./gradlew :core:standalone:bootRun

@chetanmeh
Copy link
Member Author

if the runtimes file is missing, you get a stack trace instead of a nice error

Now it would show an error message like below

[openwhisk] Error: Validation failure for 'manifest' option parameters: /path/to/non-existing.json

@chetanmeh
Copy link
Member Author

Two suggestions: when startup detects that wsk is not configured properly, it will emit an ERROR which I think should be a WARN instead. I would also emit the wsk property set ... command as part of the same line if possible and color the whole text so it's easier to spot. It's easy to miss with text scrolling by.

Now it marks it as warning

image

…nerally named `whisk/` no pull would be done
@chetanmeh
Copy link
Member Author

i think the docker pull logic is too eager - it doesn't permit the use of local images that aren't on dockerhub

Fixed that now by ensuring that eager pull is only done for openwhisk/xxx images

@chetanmeh
Copy link
Member Author

i would also like to add a wskdev target for standalone.

Added wskdev standalone target now which directly launches the standalone jar via gradle

@rabbah rabbah merged commit 2f0155f into apache:master Jun 26, 2019
@chetanmeh chetanmeh deleted the openwhisk-standalone branch July 3, 2019 04:35
BillZong pushed a commit to BillZong/openwhisk that referenced this pull request Nov 18, 2019
A standalone controller, using the lean load balancer and an in memory store.

* Use WhiskerControl port 3233 as default!
* Allow disabling read of whisk.properties, required for test run to avoid launched server influenced by whisk.properties generated for the tests. Also ensure that a system property is only set if no existing value found. This ensures that in special case user can still supersede the value being set via explicitly providing a system property override.
* Ensure that MemoryStore is only created when needed
* Fetch logs via `docker logs` command on Mac
* Add a OpenWhisk colored banner
* Package the default runtimes.json
* Include log timestamps and filter till sentinel
* Use host.docker.internal as api host for Mac and Windows
* Enable colored logging
* Add support for --verbose flag to enable debug logging easily
* Color transactionId and source also. Also support disabling color logging if needed
* Expose extension point for format log message
* Api host name is defined via system property
* Add a set of pre flight checks to confirm if OpenWhisk can run properly on this host
* Also check if docker is running
* New StandaloneDockerContainerFactory which adapts as per OS
* Only do pull for images having `openwhisk` prefix. For local image generally named `whisk/` no pull would be done
* Add ./gradlew :core:standalone:bootRun command to run jar directly. Use Spring boot default bootRun target to run the jar. Also copy the jar to bin directory.
* Make test run against standalone server
* Support disabling pull of standard images all together. Required for test runs
* Disable pause/resume support for non linux setups
* Print the wsk and docker cli version
* Update README with details on how to connect to db
* Increase time allowed for server to start to 30 secs and log logs upon timeout failure
* Enable verifySystemShutdown in Mesos tests
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
controller enhancement review Review for this PR has been requested and yet needs to be done.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants