openstack team mailing list archive

[Matt Ray <matt@xxxxxxxxxxx>]

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.
matt@xxxxxxxxxxx | (512) 731-2218
Twitter, IRC, GitHub: mattray



On Tue, Jun 7, 2011 at 3:45 PM,  <Gregory_Althaus@xxxxxxxx> 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.com@xxxxxxxxxxxxxxxxxxx
> [mailto:openstack-bounces+gregory_althaus=dell.com@xxxxxxxxxxxxxxxxxxx] On
> Behalf Of Devin Carlen
> Sent: Tuesday, June 07, 2011 2:50 PM
> To: Andy Smith
> Cc: Peter J. Pouliot; Mihai Ibanescu; openstack@xxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>