Build & Deploy time Service Configuration - meetup notes

[Daniel Silverstone]

Hi all,

Here is a brief writeup of the discussion we had at the meetup regarding the
configuration of services at build and deploy time.  They're fairly
brain-dumpy, so I apologise if they're not completely coherent.  I'm hoping
that initially others present at the talk might chime in and correct them and
that we can then discuss the value or otherwise of the approaches before
selecting one to implement.

The BoF was centred around the concept that we need to communicate some amount
of structured configuration data from the build phase of components of the
system into the configuration phase of the system.  We briefly outlined two
possible approaches to this, and then gave a basic example so that everyone at
the talk was able to consider the proposal and decide if they thought it
worthwhile to produce.  Finally we discussed possible follow-on work which
would arise from this, and possible technologies it could enable going forward.
All of this I shall attempt to reproduce in summary for below:

Approach 1:

Structured data in the definitions files themselves.  This data would be:
* Structured as YAML
* Not validatable by morph tooling (at least at first)
* Provided in some way to the configure, build and install phases of the
  component build process.
* Provided in some manner to the configuration phase, perhaps by widening
  the API of the configuration phase to include the fully resolved declaration
  of the top level components being configured.

Pros:

* Declarative approach matches our general ideals
* Structured data *could* later be subjected to validation of some kind
* Only need to read the definitions to understand the configuration data.

Cons:

* Not all configuration which might be good to manage in this way is easily
  and usefully represented as YAML
* Widened interface with configuration/build/installation of components and
  with the configuration phase extensions themselves increases the amount
  of documentation and complexity in replacing any given part.

Approach 2:

Structured data (if needed) installed into particular filesystem locations by
components as they are built, and processed during integration scripts or
configuration extensions.

* Structured in whatever way suits the data
* Not validatable by morph tooling (and unlikely to ever be easily validated)
* Provided by the component build process as part of the binary artifacts
* Accessible to later integration scripts as well as the configuration phase.

Pros:

* More flexible
* Accesible at integration time as well as configuration time, which might make
  for more usability (e.g. ensuring certain users or groups are present in the
  /etc/ files during builds for things which use getent rather than allowing
  configuration via flags or the environment).
* Does not increase the set of APIs needing to be defined by the build tooling.

Cons:

* Defers such API definition to the definitions repository internal structuring
  increasing potential for 'everyone does it differently'
* Harder to write formal validation for the data
* No possibility of standardised manner for overriding elements of the
  configuration of one component from another.

Example:

We came up with an example using a combination of users/groups (which are
getent databases) and sudoers (which is not)

The example we came up with was:

sudo.def:
...
groups:
  - name: sudo
    id: dynamic
...

httpd.def:
...
groups:
  - name: www-data
    id: 33

some webapp.def:

users:
  - name: mywebapp
    id: dynamic
    groups:
      - sudo
      - www-data

sudoers:
 - Cmnd_Alias WEBOPERATION = /usr/lib/mywebapp/magical-secured-rootly-helper
 - mywebapp ALL=(root) NOPASSWD:WEBOPERATION

Extensions:

At least two people present were interested in extending the configuration
phase in a way which allowed it to create partial data in the configured
file-system and then store configuration data for instantiation orchestration
at a later time.  (E.g. using privately calculated uids/gids for local test,
specific ones for a shared dev-env, different ones for shared-test, and
different again for production, all from the same binary artifacts generated by
the write phase of deployment).

Conclusions:

Everyone agreed that it was worthwhile producing this kind of configuration
data and the general consensus was that while the second approach was more
flexible overall, the first approach would likely be acceptable and we could
extend the availability of configuration data to the component in question and
all components build-depending on it.

Throwing it open to the list:

Firstly, if I have misremembered or forgotten anything from the BoF, could
others who were present please correct/augment the above.

Secondly, if this strikes anyone as interesting, comments, suggestions, etc
should be provided on this thread.

We propose to hold off on implementing this until we are ready to specify it as
part of version 1 of the new definitions format, (or perhaps even later than
that) -- see the thread about declarative definitions if you want to help
that happen sooner.

Many thanks for all those who attended that particular BoF, I found it very
interesting to hear about your ideas and I was gratified that noone at the
meetup decided to suggest this was unnecessary.

I look forward to seeing other writeups and to hearing from anyone on the above
points.

Regards,

Daniel.

-- 
Daniel Silverstone                           http://www.codethink.co.uk/
Software Engineer                 GPG 4096/R Key Id: 3CCE BABE 206C 3B69