Hi Cliff,
Is it strictly necessary for you to use databags for your environment specific data? If you want versioning and the other benefits of bundling structured data with your cookbook, you should almost definitely be describing that data on cookbook attributes.
For dispatching on environments within attribute data, there are a few models. The simplest is to define defaults and override them in all non conformant environments.
That can be taxing when there are a few internally consistent modes in which the cookbook can operate (for example, "production" mode vs "testing" mode), and in those cases you may want to set attribute values with a recipe which looks at a controlling attribute and chooses what to do.
I would strongly advise keeping your databags in your VCS, but keeping them separate from cookbook data.
They are flat, organization-wide information that must be loosely coupled with cookbook versions.
Arranging them in a directory tree look like tightly coupled data is deceptive and will probably lead to confusion the line.
Cheers,
Stephen
Hello,
I apologize if this has already been discussed on the list.
We are throwing around the idea of storing databags within the cookbook (that needs a particular settings). We would have one databag per cookbook and one databag item per environment. This seems like a good idea because the data that a said cookbook needs would be versioned within the cookbook and when it changes would require it to go through the SDLC. Without this, someone could change data without using SDLC.
Whether it is a Library or an app cookbooks, it would follow this same model.
What are some thoughts of this? And how are people solving this today?
Thanks,
Cliff
Archive powered by MHonArc 2.6.16.