Open Stack

not to stir disagreement, rather to reinforce it (since I just realized that
I  a previous email just to monty, and not to the list..)

chef and debs are not actually at odds.

we're using debs + chef + crowbar to do automated testing of our full
solution. The breakup is more or less:
- crowbar - automates pxe boot and basically all provisioning steps,
including the steps that follow below
- debs - install and configure services on a single machine (i.e. register
services)
- chef - based cookbooks and on configuration created by crowbar hooks up
multi machine deployment into working clusters.

the driver behind this setup is that debs are not that suited to configure a
multi node deployment or react to machines added to a cluster.
We have this setup executing on both kvm and actual physical hw.

So, totally +1 with Monty -- we're talking past each other a bit....





On Wed, Jun 8, 2011 at 9:33 AM, Matt Ray <matt at opscode.com> wrote:

> 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 at opscode.com | (512) 731-2218
> Twitter, IRC, GitHub: mattray
>
>
>
> On Tue, Jun 7, 2011 at 3:45 PM,  <Gregory_Althaus at 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.com at lists.launchpad.net
> > [mailto:openstack-bounces+gregory_althaus=dell.com at 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 at 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 at lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack at lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> >
> >
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack at lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> >
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110608/2ad2c7dd/attachment.html>