openwhisk-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dragos Dascalita Haut <>
Subject Re: Configuration through environment vs. Consul KV
Date Thu, 02 Feb 2017 00:25:19 GMT
+1 for using environment variables.

Aren't the unit tests currently dependent on a `` file as well ?

From: Felix Meschberger <>
Sent: Monday, January 30, 2017 4:49:11 AM
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

Plus: We support the „no surprises“ approach


Am 23.01.2017 um 15:52 schrieb Markus Thömmes <<>>:

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 (arbitrary step, which is not necessary for the
  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.



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