Page History

...

• Goal: Minimize reliance on Ansible (for building in configurations)

• Goal would be to Dockerize as much as possible

• Considerations:

• Have Kube YAML files as the primary source of configuration

• Utilize ENVIRONMENT vars

• “bake” other configs into Docker images

• Use shared storage via Kubernetes volumes:

• 3rd party volumes are managed through YAML files (e.g NFS volume mounts or any persistent infrastructure mount options. see here)

• Action Items:

• Nginx:

• Build Nginx with all OpenWhisk specific requirements (wsk, blackbox) pre-built into the Docker image.‘nginx.conf’ file should be generated when the Docker image comes up. This image should accept environment variables to setup deployment specific properties (i.e. URL for OpenWhisk Controller DNS address).

• helps generate certificates
• create a Kube ConfigMap from those certs and a static Nginx.conf file. Where this nginx.conf file is specific to an environment
• Have yaml file(s) for the Kube Deployment and Service which uses the generated ConfigMap

• Controller:

• Provide the ability for the controller to receive updates that new invoker instances are able to be used.

• This could be having invoker instances communicate directly to the controller <or>

• The controller watches for updates to a key-value pairs it cares about in Consul.

• Kafka:

• On the initial startup, Kafka should register the “health” and “command” topics.

• Ensure that Kafka is able to receive topic creation requests from Invoker instances

• Zookeeper:

• None?

• Invoker:

• Have the Invoker register its Kafka topics by interacting with Kafka.

• Have the Invoker register itself with the Controller:

• The Invoker must register itself directly to the controller <or>

• The Invoker registers all key-value pair information about itself into Consul

• Have only one Invoker instance be deployed to a Kube node and ensure that no other Kube Pods run alongside it as well

• Consul:

• One of two options:

• Have consul exist as the central point where components register their information as they come up. Then all other components can receive updates from consul <or>

• Remove consul from part of the OpenWhisk Deployment.

• CouchDB:

• Goal: Come up with a standardized way to setup and configure CouchDB as OW’s default document store.

• Considerations:

• This component is somewhat unique on the OpenWhisk deployment strategy as it only has to be done once and does not have rolling updates

• Questions:

• How can I configure CouchDB to with seed information for OpenWhisk?

• Can we better leverage public Docker image by wrapping it for our needs (config)?

• How can I have the OpenWhisk components talk to CouchDB?

• Assumptions:

• Over time we are working towards a “pluggable” document store approach, but this is beyond short-term scope. Despite this approach we still need to “Dockerize” our init/config as the “default”.

...