[Openstack] [CHEF] Aligning Cookbook Efforts
Jay Pipes
jaypipes at gmail.com
Wed Feb 8 04:32:48 UTC 2012
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!
-jay
More information about the Openstack
mailing list