On 02/07/2012 08:32 PM, Jay Pipes wrote: > 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.
Ping me when you want to do that... jeblair and I can handle getting the branch in once you have it. >> 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 > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp