openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

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