Opinionated / sensible / recommended default tools for charms

[Kapil Thangavelu]

Excerpts from Mark Shuttleworth's message of Thu Nov 10 02:43:42 -0500 2011:
> On 09/11/11 12:53, Michael Nelson wrote:
> > Yeah, in the example I gave of using the puppet master, it's only as a
> > distribution mechanism for private configuration details
> 
> As I recall, we did set a goal to be able to deploy services with Juju
> and colocate a puppet endpoint, so that one could deliver some
> hard-required config change to, say, all the nodes with units of a
> particular service, in Puppet. What's the status of that?
> 
> Mark
> 

The initial use case for puppet integration for co-location was out of band 
management of the container that the service unit was being deployed on. 

There seem to be a few different use cases arrising from the discussion of what 
puppet usage on a unit might entail.

  1. puppet used in standalone fashion by a charm to effect changes on a single 
     service unit. this is absent any co-location of a puppet agent. it does
     entail dependence of the charm on a puppet install, and may have 
     compatibility problems with the items below.

  2. a puppet agent in the container alongside the unit to enable out of band 
     (non service) related management of a container. this is a goal of 
     co-location.

  3. a puppet agent in the container used to manage/maintain the changes of a 
     service unit. this is a possible use of co-location.


Its this last point that has some contention. Afaics, it boils down to awareness 
of the puppet master of the use and state of the service unit container. That 
could be had via either an external node classifier [1] and more specifically of the 
data driving changes being made by the service unit onto the container.

The tension is that puppet is a centrally managed system assuming all knowledge 
config knowledge is available from the central system. While juju is more an 
orchestration model at almost a p2p level with emergent configuration 
properties. The benefit of the latter beyond orchestration is encapsulation, 
and as Gustavo points out, once we have a central system managing the emergent 
configuration we get possible breakdowns of encapsulation. Their very different
models, imo.

I think the inspection of what the service unit agent is doing can be had by 
allowing inspection of the service config and relations of a service unit, by 
its co-located puppet unit via some additional juju unit cli api. That would 
keep the encapsulation of the service unit charm, but allow the puppet agent 
ability to define custom facts against the juju data. This would push any 
violation of encapsulation directly onto the puppet master configuration which 
is the desired place in a puppet installation to manage it. 

Its the mapping of the juju service to the puppet classes that is a bit unclear. 
Its not clear if something like an external node classifier can only select 
from known class vocabulary of the puppet master. Assuming that limitation,
It requires some class pre definition for a service within the puppet master. 
Possibly these could be encapsulated or auto generated from a juju charm and 
pulled into a puppet master when available, upon establishment of the 
co-location relation. This usage could apply to other co-located services, 
possibly with charm definition/preference for a particular configuration 
management expressed within the charm, and transfered at relation establishment 
time via new cli hooks. Again the notion of automatically modifying the puppet 
master configuration is very much out of spirit of puppet afaik.

The co-location spec should be on the list today or tomorrow for discussion. 

cheers,

Kapil

[1] https://www.puppetlabs.com/guides/external_nodes.html