|
I'll jsut focus on this part, the main problem being the lifecycle of your databag, it is not coupled with the cookbook, you'll have somewhere a bad time if you update the databag in qualification and a patch is needed in prod, you'll have to bump you cookbook (at least you should tag each version) and merge back to previous version the patch...
I feel unclear reading myself so I'll try with an example:
Apps A and B in the same cookbook:
A v1.0 and B v1.0 => cookbooks v 1.0 All is ok
A v2.0 goes to Qualification, B is unchanged => cookbook v 1.1 All is ok
Here's the dragon, B should be patched but A v2.0 didn't pass the qualification, you have to make a cookbook v1.2 with A in version 1.0 and B in version 1.1
B v2.0 goes to qualification => cookbook v 1.3 but with wich version of A (first drawback)
A v2.0 is qualified and should go to prod, taking the cookbook in v 1.1 there's 2 traps:
- The cookbook version should go from 1.1 to 1.4
- You have to remind to update B version to 1.1
With this simple one example, it already show some problems, now extend it to 10/12 patches/corrections between the envs and you'll have an idea of where you'll bang your head on the wall.
With the databag the case will be close as in your version control system, your tags will cross and you'll have to merge changes from different unrelated branches. Somewhere in the future there will be a change in your databag wich is unrelated to the app (maybe the hostname, or something else) which will get you in trouble with this pattern.
If it can be, it will be one day :)
That's my point of view on why it's a bad idea and why you should keep your databag as a separate project. If you think it's really unlikely to happen or that the burden to have them separated is higher than the burden I just described, you're right keeping the databag in the cookbook, at the end of the day, choose the path you feel more comfortable with.
|
Archive powered by MHonArc 2.6.16.