<br><br><div class="gmail_quote">On Tue, Jun 7, 2011 at 1:29 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I'd like to propose that you two agree that you've agreed to agree on agreeing.<br>
<br>
All in agreement?<br></blockquote><div><br></div><div>NO.</div><div><br></div><div>P.S. Maybe?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
-jay<br>
</font><div><div></div><div class="h5"><br>
On Tue, Jun 7, 2011 at 4:11 PM, Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>> wrote:<br>
><br>
><br>
> On 06/07/2011 03:03 PM, Andy Smith wrote:<br>
>><br>
>><br>
>> On Tue, Jun 7, 2011 at 12:59 PM, Monty Taylor <<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a><br>
>> <mailto:<a href="mailto:mordred@inaugust.com">mordred@inaugust.com</a>>> wrote:<br>
>><br>
>> On 06/07/2011 02:38 PM, Andy Smith wrote:<br>
>> > Thanks for the update Monty :)<br>
>><br>
>> My pleasure as always. :)<br>
>><br>
>> > That's just testing API in a VM though, and doesn't get us to<br>
>> testing<br>
>> > actual bare-metal deployment or integration testing. At<br>
>> Rackspace, we<br>
>> > have some machines set aside at the moment, and have had<br>
>> others offer<br>
>> > chunks of machines to test various combinations of things. At<br>
>> its heart,<br>
>> > the abstract version of this looks fairly identical to the<br>
>> smoketests<br>
>> > job - pxe boot machines, shove version to be tested on them,<br>
>> run tests.<br>
>> > However, there are several moving bits on the best way to<br>
>> actually do<br>
>> > the how. At the moment, the fine folks at rPath have a Jenkins<br>
>> > installing and testing rPath OpenStack images, so Mihai and I<br>
>> are going<br>
>> > to look at getting that setup ported to our Jenkins. However,<br>
>> although<br>
>> > that will be an excellent test of code, as our main target<br>
>> platform is<br>
>> > Ubuntu, we're also looking at doing a straight-up cobbler<br>
>> install using<br>
>> > generated .debs.<br>
>> ><br>
>> ><br>
>> > Jesse and I had already gotten quite far along using chef to do the<br>
>> > provisioning of baremetal boxes once we'd pxe booted them into ubuntu,<br>
>> > it seems like chef or puppet (our current preference is chef)<br>
>> should be<br>
>> > used there as well instead of generated .debs.<br>
>><br>
>> I have every intention of moving the current work that is running to be<br>
>> based on the chef work you did... but I do not view chef and .debs to be<br>
>> mutually exclusive options. The goal here is to be able to use chef to<br>
>> install and configure the official debs. If this is not possible, then<br>
>> there are fundamental flaws that must be fixed.<br>
>><br>
>> > At the moment the two closest things to being "official" installations<br>
>> > for us (me? are the chef recipes and the nova.sh script (the nova.sh<br>
>> > script obviously being only targeted at testing and dev though), those<br>
>> > are what we use to verify that the system is functional and I<br>
>> think we'd<br>
>> > like to use chef or puppet for baremetal deployments as well.<br>
>> ><br>
>> > TL;DR: Can we focus on the chef recipes instead of on .debs?<br>
>><br>
>> nova.sh is great for devs, but isn't really something I'd imagine would<br>
>> be used as the basis of a production deployment (which is kind of the<br>
>> point of doing post-install smoke testing)<br>
>><br>
>><br>
>> (I'm pretty sure that is what I said above)<br>
><br>
> Yup. I think I was obtusely just agreeing with you there.<br>
><br>
>> And again, chef can happily<br>
>> install the software from the produced debs.<br>
>><br>
>><br>
>> Agreed, I think, maybe we're just talking past each other, it sounded<br>
>> form your email that you would be generating additional debs to handle<br>
>> the install rather than continuing to use the existing debs (and related<br>
>> deb generation process). If that is not the case and you instead to use<br>
>> the packages mostly as they exist today then I think we're already agreeing.<br>
><br>
> AH Yes. Definitely talking past each other. Definitely using existing<br>
> debs. We agree with each other. That's much better!<br>
><br>
>> It's not really just about debs - for the rPath based testing backend,<br>
>> we'll obviously be testing RPMs. But in general, testing the packaged<br>
>> software that we ship is kind of important.<br>
>><br>
>> To sum up: yes to using the chef recipes, no to "instead of".<br>
>><br>
>> Monty<br>
>><br>
>> > In any case, this is the bit which is still in the<br>
>> > planning and discussion phase, but so far all of the<br>
>> conversations I've<br>
>> > had with folks have been great - and I'd love to get more<br>
>> folks involved<br>
>> > in that (thus this email)<br>
>> ><br>
>> > However- latent goal here is that whatever mechanism we're having<br>
>> > Jenkins use to deploy OpenStack onto real hardware should be<br>
>> consumable<br>
>> > and one that actual people might actually use - otherwise what<br>
>> the heck<br>
>> > are we testing?<br>
>> ><br>
>> > Additionally, as you may have surmised, it is also a goal to<br>
>> run as much<br>
>> > of this as possible from the OpenStack Jenkins, because that<br>
>> way we can<br>
>> > as a project choose to incorporate as much of the<br>
>> feedback/results of<br>
>> > various forms of testing directly in to branch<br>
>> testing/approval as we<br>
>> > want. For some things (spinning up 20 node OpenStack clusters)<br>
>> doing it<br>
>> > on every merge proposal or giving all devs the ability to<br>
>> click a button<br>
>> > and have it run on their branch will likely be overkill - but<br>
>> if it<br>
>> > turns out not to be, it would be great to have the ability to<br>
>> do it.<br>
>> ><br>
>> > End goal is to have:<br>
>> > - publicly accessible and usable system for testing and build<br>
>> > automation<br>
>> > - resources that it uses to spin up clouds in order to test<br>
>> them are<br>
>> > themselves usable by people to spin up clouds<br>
>> > - tooling around this is done in a manner that makes us of and<br>
>> > contributes back to existing projects (jenkins plugins,<br>
>> patches back to<br>
>> > cobbler/orchestra/whatever)<br>
>> ><br>
>> > If you didn't read my _other_ long email from a few moments<br>
>> ago, actual<br>
>> > discussion of getting this done - and figuring out other people's<br>
>> > needs/tools and how to integrate them - is hopefully happening<br>
>> next week<br>
>> > right before the regular openstack-meeting. In the mean time,<br>
>> please<br>
>> > either flame on right here in list, or ping me back personally.<br>
>> ><br>
>> > Thanks everyone!<br>
>> > Monty<br>
>> ><br>
>> > _______________________________________________<br>
>> > Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>> > Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
>> <mailto:<a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a>><br>
>> > <mailto:<a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
>> <mailto:<a href="mailto:openstack@lists.">openstack@lists.</a>.<a href="http://launchpad.net" target="_blank">launchpad.net</a>>><br>
>> > Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
>> > More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
>> ><br>
>> ><br>
>><br>
>><br>
><br>
> _______________________________________________<br>
> Mailing list: <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
> Post to : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
> Unsubscribe : <a href="https://launchpad.net/~openstack" target="_blank">https://launchpad.net/~openstack</a><br>
> More help : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
><br>
</div></div></blockquote></div><br>