openstack team mailing list archive

[Monty Taylor <mordred@xxxxxxxxxxxx>]

On 06/07/2011 03:03 PM, Andy Smith wrote:
> 
> 
> On Tue, Jun 7, 2011 at 12:59 PM, Monty Taylor <mordred@xxxxxxxxxxxx
> <mailto:mordred@xxxxxxxxxxxx>> wrote:
> 
>     On 06/07/2011 02:38 PM, Andy Smith wrote:
>     > Thanks for the update Monty :)
> 
>     My pleasure as always. :)
> 
>     >      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.
> 
>     I have every intention of moving the current work that is running to be
>     based on the chef work you did... but I do not view chef and .debs to be
>     mutually exclusive options. The goal here is to be able to use chef to
>     install and configure the official debs. If this is not possible, then
>     there are fundamental flaws that must be fixed.
> 
>     > 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?
> 
>     nova.sh is great for devs, but isn't really something I'd imagine would
>     be used as the basis of a production deployment (which is kind of the
>     point of doing post-install smoke testing)
> 
> 
> (I'm pretty sure that is what I said above)

Yup. I think I was obtusely just agreeing with you there.

>     And again, chef can happily
>     install the software from the produced debs.
> 
> 
> Agreed, I think, maybe we're just talking past each other, it sounded
> form your email that you would be generating additional debs to handle
> the install rather than continuing to use the existing debs (and related
> deb generation process). If that is not the case and you instead to use
> the packages mostly as they exist today then I think we're already agreeing.

AH Yes. Definitely talking past each other. Definitely using existing
debs. We agree with each other. That's much better!

>     It's not really just about debs - for the rPath based testing backend,
>     we'll obviously be testing RPMs. But in general, testing the packaged
>     software that we ship is kind of important.
> 
>     To sum up: yes to using the chef recipes, no to "instead of".
> 
>     Monty
> 
>     >     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
>     <mailto:openstack@xxxxxxxxxxxxxxxxxxx>
>     >     <mailto:openstack@xxxxxxxxxxxxxxxxxxx
>     <mailto:openstack@xxxxxxxxxxxxxxxxxxxx>>
>     >     Unsubscribe : https://launchpad.net/~openstack
>     >     More help   : https://help.launchpad.net/ListHelp
>     >
>     >
> 
>