On Tue, Jun 7, 2011 at 1:29 PM, Jay Pipes <[email protected]> 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 <[email protected]> wrote: > > > > > > On 06/07/2011 03:03 PM, Andy Smith wrote: > >> > >> > >> On Tue, Jun 7, 2011 at 12:59 PM, Monty Taylor <[email protected] > >> <mailto:[email protected]>> 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 : [email protected] > >> <mailto:[email protected]> > >> > <mailto:[email protected] > >> <mailto:[email protected]>> > >> > Unsubscribe : https://launchpad.net/~openstack > >> > More help : https://help.launchpad.net/ListHelp > >> > > >> > > >> > >> > > > > _______________________________________________ > > Mailing list: https://launchpad.net/~openstack > > Post to : [email protected] > > Unsubscribe : https://launchpad.net/~openstack > > More help : https://help.launchpad.net/ListHelp > > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
