[chef] Re: Re: Where to store data bags

[Cliff Pracht < >]

Thanks for the feedback.  So I think we all agree that:

Storing “private” configuration data in attributes make sense I think.

Storing “public” configuration data where we want to expose config data to other nodes probably makes sense to use attributes as well.  However if the configuration is not node specific(like VIP/ELB endpoints), then using databags to store it probably makes sense.    It’s almost like we are creating a service registry at this point.   I’m just having a hard time seeing the downside of storing the databag within the cookbook for these type of endpoints. 

As an example I have an app cookbook called my_app, which would publish the following endpoint and have a databag like so:

my_app/DEV.json (data bag item)

{

      “example_service" = "http://somevipenpoint.example.com/Example/ExampleService.asmx"

 }

Where DEV is the environment name in this case. 

We would upload the cookbook along with the databag (btw which is currently not supported by Berkshelf) http://github.com/berkshelf/berkshelf/issues/1222

And as a consumer of the example_service, I would load the my_app databag and key off of the environment(DEV) data bag item to get the appropriate endpoint.    

I’m trying to understand exactly why having a databag tightly coupled with the app is a bad idea in this case.   Can you provide more insight into this?

Thanks,

Cliff

From: Stephen Rosen
Reply-To: " "> "
Date: Thursday, September 24, 2015 at 10:24 AM
To: " "> "
Subject: [chef] Re: Where to store data bags

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

On Thu, Sep 24, 2015, 09:02 Cliff Pracht < "> > wrote:

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