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
Archive powered by MHonArc 2.6.16.