On 06/07/2011 03:03 PM, Andy Smith wrote: > > > On Tue, Jun 7, 2011 at 12:59 PM, Monty Taylor <mord...@inaugust.com > <mailto:mord...@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@lists.launchpad.net > <mailto:openstack@lists.launchpad.net> > > <mailto:openstack@lists.launchpad.net > <mailto:openst...@lists..launchpad.net>> > > Unsubscribe : https://launchpad.net/~openstack > > More help : https://help.launchpad.net/ListHelp > > > > > > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
