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

[Daniel DeLeo < >]

On Thursday, July 23, 2015 at 11:02 AM, Christine Draper wrote:

> Dan,
>  
> I guess 'chef provision' is more like 'chef policy provision' than a 
> general interface for people wanting a simpler on-ramp to provisioning in 
> general?
>  
> The way I currently pass in arguments to chef provisioning is using the 
> chef-client -j option, i.e. I treat them as node attributes on the 
> provisioning node. I guess the --no-policy option would let me specify them 
> on the command line and access them through the opts object without storing 
> them as node attributes, which could be useful.
Yep, that’s the intention of the “no policy” mode. `-j` is probably fine in 
some cases, but if you’re changing the values a lot it’s probably not the 
best experience.

>  
> I'm still struggling to get a mental picture of using policyfiles with 
> provisioning, even for simple multi-node systems. Say something as simple 
> as an appserver and a dbserver that I want to provision multiple times when 
> a tester needs them. They need different runlists and attributes, but they 
> should be using the same set of cookbook versions.
Where does this constraint of  "same set of cookbook versions” come from? I 
know that in a non-policyfile world, having this constraint makes a lot of 
sense, because environments can only have one set of cookbook constraints, 
therefore to have to versions of a cookbook in production at the same time, 
you have to get “creative” (e.g., environment cookbook pattern in berkshelf 
or other solutions). Policyfiles make it easy and safe to have mutliple 
versions in a given lifecycle stage at the same time, because each kind of 
machine gets the versioning information that’s baked in to the policy, and 
that never changes without you explicitly asking for that to happen.

That said, allowing multiple versions can be a double edged sword, because 
one app or team may get stuck on an older version for a long time (I call 
this “sandbagging”), creating a high level of tech debt that has to be paid 
all at once when some circumstance forces an upgrade (and that can be at a 
really inconvenient time, such as when trying to apply a security patch to 
the underlying software). Chef Delivery doesn’t allow you to sandbag for 
precisely this reason.

At this time, Policyfiles don’t have a general mechanism to enforce a “use 
the same versions throughout an environment” policy. If you’re using a 
monolithic repo, you can set `default_source :chef_repo, “path/to/cookbooks”` 
in your Policyfile.rb(s) and then run `chef update` against all your policies 
to force them to those versions. Once you bring community cookbooks into the 
mix, though, you could have different version constraints in your metadata 
that pull in different cookbooks from supermarket, though.

Side note, all of the policyfile commands take a path to a ruby policyfile, 
so you can have a policies/ directory in your monolithic repo and then have 
policies/database.rb policies/application.rb, etc.

  
> I want to bring up the dbserver first so I can configure the appserver with 
> its IP address. My natural inclination is to write a provisioning recipe 
> that brings up the machines and sets their attributes/runlists and 
> environment (to control cookbook versions). What would the policyfile 
> version of this scenario be?

As Chef Provisioning doesn’t have any policyfile stuff yet, you’d first get 
your Policyfile.lock.json(s) into the correct state with `chef update` 
commands, then do a `chef push POLICY_GROUP` to upload the cookbooks. If you 
have a standardized place where these things live, you can automate that with 
`execute` resources.

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). At the moment, "use_policyfile true” is also required 
to turn on policyfile mode in chef-client. Aside from that, you can just use 
Chef Provisioning as you would otherwise, and run `chef provision` in the no 
policy mode.

Any feedback on how that process works for you, how you’re using it, etc. 
would be helpful to help define the future of the feature.
  
>  
> Regards,
> Christine


--  
Daniel DeLeo