Opinionated / sensible / recommended default tools for charms

[Marc Cluet]

On 10 Nov 2011, at 23:54, Clint Byrum wrote:

> Excerpts from Kapil Thangavelu's message of Thu Nov 10 11:15:42 -0800 2011:
>> Excerpts from Adam Gandelman's message of Tue Nov 08 14:37:33 -0500 2011:
>>> On 11/08/2011 08:29 AM, Michael Nelson wrote:
>>>> On Tue, Nov 1, 2011 at 5:29 PM, Michael Nelson
>>>> <michael.nelson at canonical.com>  wrote:
>>>>> Just for anyone interested, here's part 1 of my juju+puppet experiment
>>>>> (with a 2min demo):
>>>>> 
>>>>> http://micknelson.wordpress.com/2011/11/08/experimenting-with-juju-and-puppet/
>>>>> 
>>>>> It's mostly pretty obvious - I just use the install/config-changed
>>>>> hooks to defer to puppet... but it helped me learn much more about
>>>>> puppet itself and how I can use it together with juju, as well as
>>>>> start thinking how I could provide an *optional* puppet-master (given
>>>>> that this will be nearly always private).
>>>>> 
>>>>> -Michael
>>>>> 
>>> 
>>> * WARNING: this ended up much longer than I had anticipated.   *
>>> 
>>> Michael-
>>> 
>>> Cool!  I'm glad there are other people scratching their heads about this 
>>> one.  I've played around with a few different ways of doing this (mostly 
>>> exactly like yours) and ran into a couple of concerns.
>>> 
>>> 1. Stuffing puppet manifests into charms and calling them in hooks via 
>>> 'puppet apply' loses the ability to maintain and share puppet types and 
>>> resources.  Unless you've set a constraint to only depend on puppet 
>>> primitives built into puppet-core, you cannot make use of Puppet's 
>>> shared name space for modules, types and resources(one of the features 
>>> that makes Puppet so powerful)  For example, lets say I've put together 
>>> a Puppet class that incorporates other custom types, providers and 
>>> modules.  When instantiated with a couple of parameters, it propagates a 
>>> huge chunk of system configuration that would otherwise be a nightmare 
>>> to deploy using shell scripts.   Now I want to make use of that class 
>>> from manifests contained within a Juju charm.  There is no way to do 
>>> that unless I also ship the custom module and all of its custom 
>>> dependencies within that charm alongside the manifests that called via 
>>> 'puppet apply'  If I want to use this in multiple juju charms, I need to 
>>> include the module and its dependencies in every Juju charm that uses 
>>> it.  This quickly becomes a nightmare to maintain and impossible to 
>>> avoid divergence.
>>> 
>>> 2. Calling 'puppet apply' at hook execution only enforces that 
>>> configuration when the relation's state changes. Ie, I've deployed our 
>>> massive application stack on a Friday and gone on vacation for 2 weeks. 
>>> On Monday  Jr. SysAdmin deleted the wrong config file on our web 
>>> server.  With a puppetmaster in place, his mistake is corrected in ~30 
>>> minutes (or the next time the agent checks into the puppet master).  
>>> Without, I'd have to remove and re-add Juju relations to resync system 
>>> configuration with the Juju's view of the world.
>> 
>> I think the juju world view (ie. service level) would be the machine is 
>> transient, if the service on the unit isn't functional anymore, spin up a new 
>> unit. That sort of presupposes a monitoring co-location charm and 
>> notification/event processing trigger against the juju api to allow for 
>> dynamically responding to the outage event, but that's the road we want to march 
>> down.
>> 
> 
> Thats nice if all data stores are self-healing and auto-scaling. But
> reality will show us that not everybody will be able to achieve that
> level of modern scalability in all aspects of their applications. Whats
> probably more likely is that people will be able to have disposable
> *compute* units, but that they'll have a db server and some object storage
> servers that, while "highly available", are very expensive to replace in
> this manner. Taking care of long-lived units needs to be a priority of
> juju. I think periodically re-asserting all of the relationships would
> achieve this (or at least giving users a command that can do this)
> 
> Also I don't think whats being suggested is that the unit is
> non-functional, but rather that the unit's configuration is not in sync
> with the desired configuration. For instance, maybe the amount of RAM
> memcached consumsumes has been adjusted manually by the admin. It
> is improving performance, but will be lost when configuration is
> re-asserted. In the puppet and chef world, this is relatively constant,
> whereas in the juju world, this would only happen when somebody causes
> a juju-aware state change, so Jr. Admin who broke things is probably
> off the clock and three sheets to the wind before another user makes
> a change and the problem regresses.

I'd even say that the ideal setup scenario for puppet is to have a masterless puppet scenario where the charm is capable of feeding an individual puppet client with the modules necessary directly or indirectly to perform its function.
Puppet in our case can be a great complement for juju formulas, although this is solved partially by collocation a puppet module can easily complement the parts of a charm that are either too cumbersome or too heavy to transition to the new paradigm, it can work both as an inbetweener and as a copilot to the juju charm.

Also as we discussed during UDS puppet gives a quite interesting approach to maintain the de facto status of some parts of your service that otherwise juju won't touch between charm runs.

> 
>>> b. Units also get a custom fact that describes their service-unit, to be 
>>> used for node classification.
>>> c. The charm (or, possibly, a colocated puppet-agent charm), 
>>> authenticates the agent with a central puppet master and runs the puppet 
>>> agent in a typical polling configuration.
>> 
>> better is the colo puppet-agent charm, else we have charms assuming a puppet 
>> master.
>> 
> 
> +1, I eagerly await the time when users can pull in all of the puppet
> system policy along side a charm's magic powers.

My concerns about a puppetmaster sitting next to juju is that if the sysadmin is not very very clear about the boundaries between both realms we can end up with a split brain situation, where puppetmaster has one set of metadata and parameters and juju has another.