Use encrypted Data Bags about chef-stackstorm HOT 3 OPEN

My vision is that or we use it everywhere as possible, or not use at all. Something in between is less acceptable.
Thereby, tagging it as refactor.

from chef-stackstorm.

Also, we should be really careful here when considering migration, see this comment by Seth Vargo:

I'd also like to suggest/plea. Please don't force the use of a data bag in a public cookbook. This is a mistake that we've learned from in the past. Instead of forcing people to use a certain schema, I recommend using a hybrid model, like described in the new Jenkins cookbook.

Requiring a certain data bag structure forces people to manage their infrastructure in a certain manner. This is a violation of one of the guiding principles of Chef: you know your infrastructure best. The users cookbook is a big culprit here. It forces users to conform to a certain data structure, which rarely meets the ever-changing and unique demands of an organization.

Alternatively, I recommend using attribute-driven cookbooks and then encourage users to populate those attributes how they see fit. In the case of the users cookbook, users could chose to populate an attribute by specifying it manually, loading it from a data bag, or using a third-party service (like LDAP).

Might be useful for future consideration. TBH, I don't know how to approach this, need to check other public cookbooks/research more how it's usually done and what's preferred, so this Issue is open for discussions.

from chef-stackstorm.

I don't know how to approach this

Most cookbooks allow both attribute (for dev) and encrypted data bags (for prod)

from chef-stackstorm.