Looking through the Policyfiles README, it seems that the way Policyfiles get applied on existing nodes is to manipulate the client.rb manually for each server depending on the Policyfile getting applied. Is that correct? There’s no knife commands for putting a policy on a node?
In the guided tour there’s a lot of chef provision usage, is that the primary method envisioned by Chef? Unfortunately chef provision not possible for me since we don’t have the keys to provision servers ourselves.
Also, another quick question, am I correct in understanding that Policyfiles are a one policy to many node mapping? In which case, in our current multi-repo cookbook approach, I’m not sure how we’d have a Policyfile per cookbook since we also apply a global base recipe per node. We could include the base recipe in every Policyfile, which seems overkill. And in getting rid of our wrapper cookbooks, I wouldn’t want to have one repo with just a Policyfile in it. It seems like the monolithic repo with all the Policyfiles makes more sense?
At the time that blog post was written, Node objects did not yet have top level keys for policy_name and policy_group. That feature has since been added (requires Chef Server 12.3), and it is indeed possible to turn on Policyfile mode via knife bootstrap, or the JSON file you pass to chef-client with the -j option. It should be possible to convert nodes to policyfile mode via knife node edit, but there is bug preventing you from doing this: knife node edit does not save policy_name and policy_group · Issue #4364 · chef/chef · GitHub We are working on a fix for that now and it should be fixed in Chef 12.7 (don't know of a release timeline for that). If you're up for it, it should be possible to work around this with a knife exec script.
You should have a Policyfile for each type of machine you have in your infrastructure. For a standard 3-tier web app, you'd have a policyfile for each DB, app server, and LB. If you're using Test Kitchen, you probably will also have a Policyfile in each cookbook repo that represents the throwaway VM(s) that you create with TK, but that's kind of a special case.
In any case, Policyfiles are designed to be flexible in terms of how you organize them on disk. In particular, you don't need to name them Policyfile.rb, all the commands take an optional argument for the policyfile filename. I know of several folks who keep them all together in a policies/ directory. If you're using application cookbooks and want to put them there, you might do the same thing, except that you just have the policies relevant to that application there (e.g., if you have 2 different 3-tier web apps and each has a separate application cookbook, you might have a policies dir in each cookbook with policies for lb/app/db).
Thanks for the reply @kallistec, I haven’t had a chance to try this out yet. I was hoping setting policies was something done through a knife command though, is that something in the works or is that a mismatch for the way Policyfiles are suppose to be used?
If it’s not getting added as a knife command, maybe it can make it’s way into the chef-client cookbook and thus able to be managed as a node attribute.
Anyway, I’ll give it a whirl and try to report back. Thanks again!
policy_name and policy_group are like any other non-attribute node property, such as environment. You probably want to set these during your bootstrap process most of the time, but sometimes you need to change them. If you have a small enough infrastructure that using knife makes sense, then you should be able to use knife to modify them. Right now, bootstrapping (with knife bootstrap or other method) works like it should, but modifying nodes with knife node edit doesn't work, but that's only because of a bug (again, knife node edit does not save policy_name and policy_group · Issue #4364 · chef/chef · GitHub). That bug is fixed in master, so the fix will go out with Chef Client 12.7.
As for setting the revision of a particular policy that is applied for a policy group, that is only done by chef push.