openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dragos Dascalita Haut <ddas...@adobe.com>
Subject Re: Configuration through environment vs. Consul KV
Date Fri, 03 Feb 2017 00:20:49 GMT
This thread about simplifying the configuration got me thinking if we can do something about
the configuration of the CouchDB as well.


IIUC before starting OW the CouchDB needs to be setup with:

1. A table for "subjects" with a minimum of 2 subjects : whisk.guest and whisk.system

2. A table for "actions" [1]

3. A table for "api gateway configuration" [1]

4. Create table views  [2]


I'm wondering if it would be easier to create a new docker container, extending the CouchDB
one, and when it starts initially it checks for the DB, the tables, and if they're missing
it configures them, or if table views need to be updated it updates them. Or is there an easier
way ?


WDYT ?

Thanks,
dragos
[1] - https://github.com/openwhisk/openwhisk/blob/master/tools/db/wipeTransientDBs.sh
[2] - https://github.com/openwhisk/openwhisk/blob/master/tools/db/loadTransientDBViews.sh

________________________________
From: Felix Meschberger <fmeschbe@adobe.com>
Sent: Monday, January 30, 2017 4:49:11 AM
To: dev@openwhisk.apache.org
Subject: Re: Configuration through environment vs. Consul KV

Hi Markus

I like this as in my understanding this also aligns with the current thinkings around µservice
deployments.

Plus: We support the „no surprises“ approach

Regards
Felix

Am 23.01.2017 um 15:52 schrieb Markus Thömmes <markusthoemmes@me.com<mailto:markusthoemmes@me.com>>:

Hi all,

I've got a cleanup idea in my mind, which I'd like to pass by you all to gather different
opinions and experiences.

Ansible configuration files (hosts and group_vars basically) are considered our truth. To
configure our components we have a mixture of ways to pass those values to them, though. The
most common way is:


  1.  Write the values into whisk.properties (arbitrary step, which is not necessary for the
rest)
  2.  Push the values into Consul's KV store
  3.  Component comes up, gets only Consul parameters via its environment and reads all the
values it needs from Consul

Some of our values are already passed by Environment vs. Consul though, for no apparent reason
like WHISK_VERSION_NAME in the Controller.

In my opinion, our configuration handling is a bit out of hand at this point and I haven't
found a reason why we're using Consul for configuration storage at all. It also defeats ansible's
purpose of keeping track of configuration changes.

An example: Say I want to change the database of a running OpenWhisk deployment because the
main one crashed. How do I do this today:


  1.  Change the values in Consul - easy, but not in line with our single-point-of-truth anymore.
  2.  Know each component that relies on those values - hidden knowledge.
  3.  Restart those components to make sure they reload the configuration.

What I propose is: Configuration through Environment solely. The example would then be:


  1.  Change the values in the Ansible configuration.
  2.  Redeploy through the usual commands - Ansible only updates/restarts the components with
changed configuration automatically (might need some extra tweaking as I think our scripts
currently force a restart every time and on every component, but you get the idea)

I believe that's much simpler to handle, more in line with how Ansible etc. are designed to
work and it streamlines configuration management even more. As a bonus, we lose the deploy
time dependency on Consul, making the deployment simpler in general.

Ideas/Thoughts/Objections/Tomatoes?

Cheers
Markus


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message