openstack team mailing list archive
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
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
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!