openstack team mailing list archive

[Monty Taylor <mordred@xxxxxxxxxxxx>]

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
>