As far as deploying with Chef goes, I've been focusing my efforts on making cookbooks for stable releases that support a variety of options, both on bare metal and from previously installed OSs. I'm definitely looking forward to Dell's open sourcing of their Crowbar bare-metal installer, but in the meantime we're using a scaled-back tool that does bare-metal to OpenStack installs, all managed with Chef (pxe_dust cookbook). I've been meaning to write it up, feel free to email me if you have questions.
Thanks, Matt Ray Senior Technical Evangelist | Opscode Inc. m...@opscode.com | (512) 731-2218 Twitter, IRC, GitHub: mattray On Tue, Jun 7, 2011 at 3:45 PM, <gregory_alth...@dell.com> wrote: > Matt Ray and I have extended/modified some of the Anso-based chef scripts to > configure the debs on systems. I think Matt’s focused on getting a systems > built from bare metal using his spiceweasel tool and mine are focused on > inclusion in crowbar that includes the pxe/install environment for bare > metal and virtual environments. > > > > I think Dan Prince had some chef scripts that included the ability to pull a > branch to use as the nova base on top of the debs. > > > > All three trees are up on github now. > > > > Thanks, > > Greg Althaus > > > > From: openstack-bounces+gregory_althaus=dell....@lists.launchpad.net > [mailto:openstack-bounces+gregory_althaus=dell....@lists.launchpad.net] On > Behalf Of Devin Carlen > Sent: Tuesday, June 07, 2011 2:50 PM > To: Andy Smith > Cc: Peter J. Pouliot; Mihai Ibanescu; openstack@lists.launchpad.net > Subject: Re: [Openstack] Overview of CI/Testing > > > > +1 for chef over debs! > > > > > > On Jun 7, 2011, at 12:38 PM, Andy Smith wrote: > > Thanks for the update Monty :) > > > > That's just testing API in a VM though, and doesn't get us to testing > actual bare-metal deployment or integration testing. At Rackspace, we > have some machines set aside at the moment, and have had others offer > chunks of machines to test various combinations of things. At its heart, > the abstract version of this looks fairly identical to the smoketests > job - pxe boot machines, shove version to be tested on them, run tests. > However, there are several moving bits on the best way to actually do > the how. At the moment, the fine folks at rPath have a Jenkins > installing and testing rPath OpenStack images, so Mihai and I are going > to look at getting that setup ported to our Jenkins. However, although > that will be an excellent test of code, as our main target platform is > Ubuntu, we're also looking at doing a straight-up cobbler install using > generated .debs. > > > > Jesse and I had already gotten quite far along using chef to do the > provisioning of baremetal boxes once we'd pxe booted them into ubuntu, it > seems like chef or puppet (our current preference is chef) should be used > there as well instead of generated .debs. > > > > At the moment the two closest things to being "official" installations for > us (me? are the chef recipes and the nova.sh script (the nova.sh script > obviously being only targeted at testing and dev though), those are what we > use to verify that the system is functional and I think we'd like to use > chef or puppet for baremetal deployments as well. > > > > TL;DR: Can we focus on the chef recipes instead of on .debs? > > > > > > In any case, this is the bit which is still in the > planning and discussion phase, but so far all of the conversations I've > had with folks have been great - and I'd love to get more folks involved > in that (thus this email) > > However- latent goal here is that whatever mechanism we're having > Jenkins use to deploy OpenStack onto real hardware should be consumable > and one that actual people might actually use - otherwise what the heck > are we testing? > > Additionally, as you may have surmised, it is also a goal to run as much > of this as possible from the OpenStack Jenkins, because that way we can > as a project choose to incorporate as much of the feedback/results of > various forms of testing directly in to branch testing/approval as we > want. For some things (spinning up 20 node OpenStack clusters) doing it > on every merge proposal or giving all devs the ability to click a button > and have it run on their branch will likely be overkill - but if it > turns out not to be, it would be great to have the ability to do it. > > End goal is to have: > - publicly accessible and usable system for testing and build automation > - resources that it uses to spin up clouds in order to test them are > themselves usable by people to spin up clouds > - tooling around this is done in a manner that makes us of and > contributes back to existing projects (jenkins plugins, patches back to > cobbler/orchestra/whatever) > > If you didn't read my _other_ long email from a few moments ago, actual > discussion of getting this done - and figuring out other people's > needs/tools and how to integrate them - is hopefully happening next week > right before the regular openstack-meeting. In the mean time, please > either flame on right here in list, or ping me back personally. > > Thanks everyone! > Monty > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
