Mailing-List: contact dev-help@openwhisk.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@openwhisk.apache.org
From: Dragos Dascalita Haut <ddascal@adobe.com>
To: "dev@openwhisk.apache.org" <dev@openwhisk.apache.org>
Subject: Re: Configuration through environment vs. Consul KV
Thread-Topic: Configuration through environment vs. Consul KV
Thread-Index: AQHSdYhoM+naXVs3bUKOTkdPxjO+haFRA3CAgAVuMW0=
Date: Fri, 3 Feb 2017 00:20:49 +0000
Message-ID: <CY1PR0201MB17855DCB3A74A408C07CA1CCA44C0@CY1PR0201MB1785.namprd02.prod.outlook.com>
References: <c5d601fc-69e0-44e1-b13c-285ecf0b07a4@me.com>,<4DE0E39F-FC55-4AEA-85BA-0F4C57BF8E6A@adobe.com>
In-Reply-To: <4DE0E39F-FC55-4AEA-85BA-0F4C57BF8E6A@adobe.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: adobe.com does not designate
 permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_CY1PR0201MB17855DCB3A74A408C07CA1CCA44C0CY1PR0201MB1785_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2017 00:20:49.1315
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: fa7b1b5a-7b34-4387-94ae-d2c178decee1
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0201MB1785
archived-at: Fri, 03 Feb 2017 00:21:22 -0000

--_000_CY1PR0201MB17855DCB3A74A408C07CA1CCA44C0CY1PR0201MB1785_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

This thread about simplifying the configuration got me thinking if we can d=
o 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 wh=
isk.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, exten=
ding the CouchDB one, and when it starts initially it checks for the DB, th=
e 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/wipeTrans=
ientDBs.sh
[2] - https://github.com/openwhisk/openwhisk/blob/master/tools/db/loadTrans=
ientDBViews.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 thinki=
ngs around =B5service deployments.

Plus: We support the =84no surprises=93 approach

Regards
Felix

Am 23.01.2017 um 15:52 schrieb Markus Th=F6mmes <markusthoemmes@me.com<mail=
to:markusthoemmes@me.com>>:

Hi all,

I've got a cleanup idea in my mind, which I'd like to pass by you all to ga=
ther 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 t=
hose 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 a=
nd 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 poin=
t and I haven't found a reason why we're using Consul for configuration sto=
rage at all. It also defeats ansible's purpose of keeping track of configur=
ation changes.

An example: Say I want to change the database of a running OpenWhisk deploy=
ment 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-p=
oint-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 wo=
uld then be:


  1.  Change the values in the Ansible configuration.
  2.  Redeploy through the usual commands - Ansible only updates/restarts t=
he components with changed configuration automatically (might need some ext=
ra 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 depl=
oyment simpler in general.

Ideas/Thoughts/Objections/Tomatoes?

Cheers
Markus


--_000_CY1PR0201MB17855DCB3A74A408C07CA1CCA44C0CY1PR0201MB1785_--