← Back to team overview

openstack team mailing list archive

Re: [CHEF] Aligning Cookbook Efforts


Thanks for the update, Matt. Comments inline...

On 02/07/2012 10:16 PM, Matt Ray wrote:
I think Jay did a good job outlining the lineages and scope of the
assorted cookbook efforts so far. My Anso-based fork at
github.com/mattray/openstack-cookbooks was the basis for a few public
and private forks and strictly focused on multi-node deployments of
stable releases. A lot of this went into Dell's efforts with Crowbar
and they've continued to develop for Diablo and future releases while
working with Rackspace Cloud Builders. While I've been working with
them primarily since the Diablo release, I've also done work with
folks who do not want to use Crowbar, and pulling those cookbooks out
of the barclamps hasn't always been straightforward.

From what I gather, the reason it's not always straightforward is because the cookbooks in the Crowbar barclamps are quite opinionated and make a number of assumptions about the underlying hardware or environment.

I will begin researching how to pull work that's been done in the Crowbar barclamp cookbooks into the upstream chef repo -- and in the process come up with some documentation on how to create the cookbooks in a way that is flexible enough to service multiple environments by using roles, attributes and databags. Chef is still new to me, though, so I will likely lean on you heavily for advice on best practices. I'll put the documentation directly into the upstream Chef repos unless folks think the wiki or some other place on openstack.org would be a better choice?

After discussing the state of Chef cookbooks out there with Jay and
folks at Dell, I plan on forking off of
github.com/openstack/openstack-chef/tree/stable/diablo once it's there
and getting it synced up with the efforts in the Crowbar cookbooks.
I'll be pushing into Opscode's repo and hopefully sending patches
upstream to both efforts.

Well, in my original email I proposed using the NTT PF Lab branch point for the stable/diablo branch of the upstream chef repos. If we can get a casual consensus from folks that this is OK, I will go ahead and push that to Gerrit. Please +1 if you are cool with that. This will allow us to have a branch of the upstream cookbooks that aligns with the core projects.

My repo will probably not be a good candidate for an upstream provider
since updates may be sporadic since I don't only work on OpenStack. I
won't follow trunk and I'll continue to strictly focus on deploying
the current stable release.

Understood. There are plenty of others who are interested in following trunk and ensuring that additions to trunk make their way into the stable branches. Generally, the way that OpenStack projects work is that changes are first proposed to the development trunk and then a separate set of stable maintainers will cherry-pick relevant hotfixes into the stable branch they are maintaining -- resolving any merge conflicts that may arise during that operation. I think all that would be needed from you to keep the deployment wheels greased would be a short email notification to the mailing list when you add or change something substantial in your downstream repos that you feel would benefit the broader community. Then the maintainers of the upstream stable cookbooks repo can simply check your repo out, determine if and how those commits can be applied to the development branch and work with the development branch contributors to get the aforementioned development -> stable cherry-pick process going.

> It's likely at some point my repo will
pull in support for multiple implementations of the Swift API (Ceph,
Gluster, etc.) and hopefully additional hypervisors and databases and
RHEL support; it's driven by whoever I'm currently working with. I
also plan on unforking the many non-OpenStack cookbooks from the repo
and pushing any changes upstream to help keep things simple.

Excellent. I think this is definitely something that the broader community would be eager to use and contribute to.

While the Cactus documentation I wrote is stale
(http://bit.ly/OSChef), I'll update it going forward and try to keep
my repo well-documented as far as what all the pieces are and usage.
On Jay's suggestion I'll keep the content synced between the Opscode
wiki and the README.md. My current #1 priority is getting
knife-openstack fixed, then I'll get working on this again.

Rock on. Thanks Matt!


Follow ups