Open Stack

I'd like to propose that you two agree that you've agreed to agree on agreeing.

All in agreement?

-jay

On Tue, Jun 7, 2011 at 4:11 PM, Monty Taylor <mordred at inaugust.com> wrote:
>
>
> On 06/07/2011 03:03 PM, Andy Smith wrote:
>>
>>
>> On Tue, Jun 7, 2011 at 12:59 PM, Monty Taylor <mordred at inaugust.com
>> <mailto:mordred at inaugust.com>> 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 at lists.launchpad.net
>>     <mailto:openstack at lists.launchpad.net>
>>     >     <mailto:openstack at lists.launchpad.net
>>     <mailto: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
>