[chef] Re: Re: Re: Re: Re: Re: Re: Re: Re: Policyfiles and chef provision

[Daniel DeLeo < >]

On Friday, July 24, 2015 at 11:29 AM, Chris Sibbitt wrote:
> Thank you very much Christine and Daniel for your helpful discussion. I 
> think this line is really what answers my question:  
>  
> > So, for the policyfile focused stuff, I opted to make it work more like 
> > `knife bootstrap` and `knife cloud create`  
>  
> That means you specifically were looking at the case where a provisioning 
> recipe handles just one machine. I don't think I will bother with the "chef 
> provision" tool in that case, since I don't want to have to enforce that 
> "one machine per recipe" rule in our code, and the allure of 
> chef-provisioning for us is being able to use it to bring up whole "Stacks" 
> of related machines (what Christine called 'topologies' I think).
>  
> > I did think about clustering scenarios when I was writing `chef 
> > provision`, but it turns out that it can be complicated depending on what 
> > the exact use case is. Do you want a “throwaway” cluster to 
> > integration-test your cookbooks as a whole? How do you keep different 
> > developers’ throwaway clusters from conflicting with each other?
>  
> So far my solution to this (though we haven't worked with it for long 
> enough to say if it's a good one long term) is to require 
> ENV['DEPLOYMENTID'] exist and use it in the name of every chef_provisioning 
> resource. That way, each deployment of a stack has it's own machine names 
> and can be managed as a distinct entity of related machines.
I should have been a bit more clear on this. I definitely do want `chef 
provision --no-policy` to be the best way to run Chef Provisioning in the “I 
know what I’m doing, just let me do it” case, including when you’re creating 
full stacks/clusters/etc. Despite the name (which I’m now thinking is a bit 
misleading), you can definitely use `chef provision` this way to create 
machines that will be managed via policyfiles.

The part that I punted on was stitching one or more policyfile operations 
together with use cases where you would expect the tool to have some concept 
of “ephemeral clusters.” For example, if you have updates to the policy for 
both your HTTP application servers and your database servers, and you want to 
spin up a test cluster which you’ll later tear down. In that case, you might 
need an ephemeral policy group for the cluster, a cluster ID so you can have 
unique machine names, you’d have to push multiple policies to the ephemeral 
policy group, and you should have an easy way to clean everything up when 
you’re done (and in the ideal case, the tool should be robust to changes in 
your provisioning code so you don’t accidentally orphan resources that you’re 
paying for by the hour).

I’d really like to add such a feature in the future, but I think a lot of 
design is needed to make the experience delightful, so I opted to skip it in 
order to get the basic part of the feature shipped. Just to be clear about 
expectations, this advanced clustering isn’t a priority right now so it might 
not happen at all unless there’s a “pull” for it from a customer or the 
community.
  
>  
>  
> The workflow I've settled on is similar to how Daniel describes it:
>  
> 1. Set up the policyfile
> 2. Install/Update/Push the policyfile
> 3. Write chef-provisioning code to set up machines to use a named policyfile
> 4. Run the provisioning recipes with something like `chef-client -z -o 
> my-provisioning::mystack`
>  
> This thread was about whether I should be using 'chef provision' in step #4 
> because running chef-zero or chef-solo on my provisioning node feels weird.
That’s exactly what `chef provision --no-policy` was designed to do, along 
with giving you more natural ways to pass input (like ENV['DEPLOYMENTID’] 
that you’re doing now) from the command line. For example, you can pass any 
arbitrary option to `chef provision` with `-o key=value`.
  
>  
> For step 3, I've done a more cookbook-heavy version of Daniel's suggestion:
>  
> > From there, you need to set the policy_group and policy_name on the nodes 
> > via the client.rb (not sure how well this is documented, but you can pass 
> > configuration as a string with { chef_config: “your client.rb content” } 
> > as convergence_options)
>  
> Here's what I do:  
>  
> default['my-provisioning']['node_attrs'] = {
> :chef_client => {
> :config => {
> :use_policyfile => true,
> :policy_document_native_api => true,
> :policy_group => 'mypolicygroup',
> :policy_name => 'mypolicy'
> } } }
>  
> machine "mymachine-#{ENV['DEPLOYMENTID']}" do
> run_list ['recipe[chef-client]', 'recipe[chef-client::config]']
> attributes node['my-provisioning']['node_attrs'].merge(
> :mycookbooks => {
> :config => {
> :stuff => 'values'
> } } )
> end
>  
>  
> This uses the chef-client cookbook to set up the policyfile mode for the 
> node. Actual control of the run_list is in the policyfile.
>  
> There are some downsides to this:
> * You need to run a second converge on the node in order to get it running 
> the right run_list; so that can either happen automatically via chef-client 
> service config, or you can add the second converge right in your 
> chef-provisioning recipe.
> * IIRC, subsequent executions of the the provisioning recipe don't actually 
> run the real run_list, they just ensure that it's still set up for the 
> right policy
> * You need to serve a version of the chef-client cookbook without the 
> benefit of policyfile locking

Using the `chef_config` option in provisioning should fix all of these.
  
> * Your run_list is separate from your machine definition, which is a bit 
> awkward, leaving all your machines with the same uninformative run_list 
> specification in your provisioning recipes

In the future, node objects will have fields for policy_name and 
policy_group, once that’s done then Chef Provisioning can learn to set those, 
which will solve this. That will also make the `chef_config` stuff redundant. 
This is towards the top of my backlog but I don’t have any ETA.
  
>  
> I think I will experiment with using 'chef_config: “your client.rb 
> content”' instead of the chef-client cookbook, it might cut down a bit on 
> complexity.
>  
> Thanks again, this is exactly what I was looking for from this thread. I 
> would be interested in hearing any additional thoughts about my workflow 
> and especially any insight to how you see the co-ordination between these 
> tools evolving in the next year or so.

HTH,

--  
Daniel DeLeo