On Friday, June 20, 2014 at 2:21 PM, Torben Knerr wrote:
>No. chef-client gets a static list of cookbook versions and its run list from a data bag. The server does not apply any dependency constraints whatsoever, and the client never calls any API that looks at any environment. To minimize confusion while the feature is experimental, chef-client will refuse to run if you have an environment configured and enable the policyfile mode (but note that this doesn’t imply any decision has been made on how it will work in the end). See: https://github.com/opscode/chef/blob/master/lib/chef/policy_builder/policyfile.rb
> On Fri, Jun 20, 2014 at 6:18 PM, Daniel DeLeo < "> (mailto: "> )> wrote:
> > > >
> > > > 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" ...`)?
> > In the current “compatibility mode” implementation, you cannot use environments and Policyfiles at the same time. You must identify your policies with a single string, so you’d name them as $functional_role-$deployment_stage. This decision was forced by the requirement to use existing data bags as the storage mechanism and won’t necessarily be what we do in the final implementation.
>
>
> Guess that means that you are using environments via `berks apply` for locking a Policy's dependency graph under the hood?
>
>
> > >
> > > 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 understand the use case. Again, we haven’t made a decision here, but the things we’re thinking about are:
> >
> > * Environments are global, so any change to them immediately affects all nodes in an environment. Is this a good thing?
>
> IMO yes. If something in the environment changes (e.g. ntp server) it affects all nodes in that environment. That should also be the criteria when deciding whether to put something into an environments vs. into a wrapper cookbook (which requires re-releasing the cookbook for changing attributes).
The flip side of this is that there’s no way to make certain changes without impacting every single node at once. Suppose you now have two NTP servers so you change the attribute from a string to an array of strings. All your chef-client runs fail. We could, instead, bake environmental attributes into the policyfile with some switching mechanism in the client. The more you bake in when the policyfile is compiled, the more certainty you can have that it’ll work when you promote it to production.
And if you really do need globally mutable config data, you can use data bag items.
Just to be clear, I’m explaining the sort of tradeoffs we’ve got in the back of our minds that we’ll consider when the time comes to make a decision. We want to learn from real-world usage where the rough edges and pick the best set of tradeoffs based on experience.
>
> > * How exactly do policies get promoted from stage to stage? Are they completely static or can they be customized as they’re promoted?
>
> From my understanding the Policy should is the static part which describes the functional role as a coherent whole, but not any environmental stuff surrounding it. They should be self-contained and independent of the environmentals IMO.
>
>
> > * Reducing the number of ways you can set attributes would make Chef easier to understand and debug.
> > * Can we do something other than environments that provides flexibility for use cases that require it? For example, some users need to customize data or behavior by both deployment stage and data center. If you make environments that are the conjunction of both (e.g., production-us-east), that causes a lot of the same problems that you have with “micro environments” (duplicated data, etc.).
>
>
> For me environments (for environmental stuff affecting all nodes in the env) and policies (functional roles with a locked dep graph) are two completely separate an orthogonal concepts. We should keep them selective and not mix them up, then they will be composable.
>
> One way to prevent "micro environments" would be to allow for a single node to be in multiple environments (e.g. `--environments prod,us-east,foo`), i.e. extending the current 1:1 relation to 1:N.
>
> That would btw also let you use environments as the underlying mechanism for locking the dependency graph (think `berks apply`) while still providing the ability to express "deployment groups" like "prod" and "us-east" via the environment mechanism.
>
> Making nodes:environments a 1:N relation and deprecating `cookbook_versions` and `cookbook` from environments (combined with Policyfile for sure) would probably be the most minimal change that would solve all the problems and use cases we discussed here and on github.
>
> What do you think?
We do want to do something that has the same end result as that. Personally, I’d like to use a more abstract name than environments, since people have conflicting ideas of what makes an environment (and a cluster-id or datacenter don’t really fit that definition anyway). And again, we will look very hard at the tradeoffs associated with how changes propagate to nodes once we’re in a position to try things in real world scenarios.
Archive powered by MHonArc 2.6.16.