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 <[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
