openstack team mailing list archive

[Andy Smith <andyster@xxxxxxxxx>]

On Tue, Jun 7, 2011 at 1:29 PM, Jay Pipes <jaypipes@xxxxxxxxx> wrote:

> I'd like to propose that you two agree that you've agreed to agree on
> agreeing.
>
> All in agreement?
>

NO.

P.S. Maybe?


>
> -jay
>
> On Tue, Jun 7, 2011 at 4:11 PM, Monty Taylor <mordred@xxxxxxxxxxxx> wrote:
> >
> >
> > 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
> >>     >
> >>     >
> >>
> >>
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
> >
>