Scoping data bag items to environments

#1

Howdy –

Is there any support, either in code or by convention, for scoping data bag
items to environments?

Presuming that no explicit support exists (which is my current working
understanding), I’ve been thinking about appending the current environment
to the bag name for any data bags which are environment-specific. This would
seem like an advantage over putting the target environment in the bag item
name or in the JSON object’s contents, by preventing the need for Chef code
to consider and explicitly exclude items not local to the active
environment.

Have others given thought to this subject?

Thanks!

#2

Hello!

On Tue, Aug 16, 2011 at 5:46 PM, Charles Duffy charles@dyfis.net wrote:

Is there any support, either in code or by convention, for scoping data bag
items to environments?

Convention. For example in an application deployment, we might want to
have a specific version listed in a data bag item by environment.

{
“id”: “my_app”,
“repository”: "git@github.com:my_company/my_app.git",
"repository: {
“production”: “1.0.0”,
“staging”: “1.2.0”,
“development”: “master”
}
}

We use this pattern in Opscode’s public “application” cookbook.

–
Opscode, Inc
Joshua Timberman, Director of Training and Services
IRC, Skype, Twitter, Github: jtimberman

#3

…so you have a single instance of the item, with its data referencing the
different environments?

That’s really not ideal for my use case, and I’ll probably want to select a
different convention. I have an application which creates new data bag items
when users specify new objects. I don’t want a bug in the development
version of the application (running in a “testing” environment) to
potentially corrupt the content pushed to Chef by the live, production
instance.

On Tue, Aug 16, 2011 at 8:15 PM, Joshua Timberman joshua@opscode.comwrote:

Hello!

On Tue, Aug 16, 2011 at 5:46 PM, Charles Duffy charles@dyfis.net wrote:

Is there any support, either in code or by convention, for scoping data
bag
items to environments?

Convention. For example in an application deployment, we might want to
have a specific version listed in a data bag item by environment.

{
“id”: “my_app”,
“repository”: "git@github.com:my_company/my_app.git",
"repository: {
“production”: “1.0.0”,
“staging”: “1.2.0”,
“development”: “master”
}
}

We use this pattern in Opscode’s public “application” cookbook.

–
Opscode, Inc
Joshua Timberman, Director of Training and Services
IRC, Skype, Twitter, Github: jtimberman

#4

our hack has been to use a lookup for environment (this was pre chef-environments) and chefs DeepMerge to basically get us environment bag items that could be merged into a default bag item:

bags = data_bag( :jboss )
conf = data_bag_item( :jboss, node.jboss.cluster )[‘jboss’]
if bags.include?( cluster_env )
conf = Chef::Mixin::DeepMerge.merge( conf, data_bag_item( :jboss, cluster_env )[‘jboss’] )
end

so in jboss bag we have cluster1 and cluster1-dev which will override cluster1 default bag item.

This has served us well.

On Aug 16, 2011, at 4:46 PM, Charles Duffy wrote:

Howdy –

Is there any support, either in code or by convention, for scoping data bag items to environments?

Presuming that no explicit support exists (which is my current working understanding), I’ve been thinking about appending the current environment to the bag name for any data bags which are environment-specific. This would seem like an advantage over putting the target environment in the bag item name or in the JSON object’s contents, by preventing the need for Chef code to consider and explicitly exclude items not local to the active environment.

Have others given thought to this subject?

Thanks!

#5

We’ve been favoring attributes lately. Much easier to override per
environment or node. Nice thing about data bags is they are global. Bad
thing about data bags…

–Brian