[chef] Re: Re: Environments vs. Metadata vs. Policyfile for locking cookbook dependencies

[Torben Knerr < >]

Hi Daniel,

thanks for all the explanation, that makes my picture about Policyfile much clearer.

Few comments inline...

On Mon, Jun 16, 2014 at 5:20 PM, Daniel DeLeo < " target="_blank"> > wrote:

>
> 3. How are the Policyfiles versioned, published and being referenced?
Policies won’t have versions (aside from what you do on your own in your version control system). The exact mechanism by which a node is assigned to a policy hasn’t been decided yet. We have some prototype code that uses data bags to store the policies, see:

https://github.com/opscode/chef/blob/master/lib/chef/policy_builder/policyfile.rb
https://github.com/opscode/chef/blob/master/spec/unit/policy_builder/policyfile_spec.rb
https://github.com/opscode/chef/blob/master/lib/chef/config.rb#L343-351

In the current prototype, you’d name your policies something like $functional_role-$deployment_group where $functional_role is something like appserver/load balancer/database/etc. and $deployment group could map to your environments, groups within environments (for example, if you deploy to production on a cluster-by-cluster basis, you could have prod-cluster-a, prod-cluster-b, etc.) or whatever makes sense to you. Whether or not the deployment group concept becomes a bit more first class when we implement the APIs is something we haven’t decided yet.

​Does that mean that when the policy is named "appserver-prod" it would automatically apply the "prod" environment to the node?

Or alternatively: will it be possible to bootstrap a node with a Policyfile AND a Chef environment (e.g. `knife bootstrap --policy "appservers" --environment "prod" ...`)?​

 

>
> 4. Can you reference a Policyfile from within an environment?
With policies, all the environment version specification stuff goes away. We may keep them around as a place to store attributes, and it’s possible that nodes will associate to policies by policyname plus environment. Contrarily, we might use a different name for policy containers, or design the system in such a way that the “containers” are implicit.

​So basically that means deprecating the `cookbook` and `cookbook_versions` from environments, right? 

I would still vote for keeping environments though, because they allow you to set common attributes across a set of arbitrary nodes which might have totally different policies.  ​

 

>
> I assume (even though not explicitly mentioned) that the new Policyfile mechanism would work for chef-solo as well, does it?
Exactly how it works with chef-solo is to be determined. Since chef-solo gets cookbooks from local disk, the question of supporting multiple versions with solo is pretty awkward.

​As a long time, happy Chef solo user​ I would hope that it would work in a similar way like with a Berksfile today: just as `berks install` collects all cookbook versions from `Berksfile.lock` and puts them into a separate directory so it can be used as the cookbook repo for Chef solo, I would expect that with `Policyfile` its working in a similar way.

My main use case is Chef solo with Vagrant plus the awesome vagrant-omnibus and vagrant-berkshelf plugins.

Btw: what's the role of Berkshelf with Policyfile? Will it still be used for resolving the dependency graph?

Cheers,

Torben