[chef] Re: conflict between using environments to manage cookbook releases and to manage application environments

[Adam Jacob < >]

On Tue, May 1, 2012 at 1:47 AM, Bryan Berry 
<
 >
 wrote:
> I would love to treat chef_environments like application_environments but
> that would completely break my workflow. How are others dealing w/ the
> issues I have brought up here?

Why would it break your workflow?

You have a single policy, "stable", which needs to get set in each of
your "stable" environments. What is driving change in the chef server?
Is it all manual, or are you doing something like using Jenkins to
update Chef?

That said, there would be nothing wrong with treating the Chef
environments exactly as you do now, and just having a small alteration
to how you deal with application_enviornments: rather than a single
data bag with many keys, I would do something like:

apps_esb: { <-- data bag
  "pr": { .. }, # <-- data bag items
  "qa": { ... },
}

Even this I think is actually less than ideal for application
environment modeling. One step further:

app_versions: {
  "foo": { "pr": "12345",
             "qa": "123456"},
  "bar": { "pr: "12345",
             "qa": "123456"}
}

app_foo: {
  "12345": {
     # everything related to this release of app_foo, data wise
   },
  "12346": {
  }
}

I would take it a step further and say you should have app_versions
moved out of a data bag an in to a top level chef environment, with
it's cookbook policy being basically identical, and the versions for
every app set as environment attributes. Keep the application-release
specific values local to the application data itself.

Best,
Adam

-- 
Opscode, Inc.
Adam Jacob, Chief Customer Officer
T: (206) 619-7151 E: