<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 4, 2016 at 2:55 PM, Wesley Hayutin <span dir="ltr"><<a href="mailto:whayutin@redhat.com" target="_blank">whayutin@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><br><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 4, 2016 at 9:43 AM, Wesley Hayutin <span dir="ltr"><<a href="mailto:whayutin@redhat.com" target="_blank">whayutin@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Wed, Aug 3, 2016 at 8:45 PM, Emilien Macchi <span dir="ltr"><<a href="mailto:emilien@redhat.com" target="_blank">emilien@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>On Wed, Aug 3, 2016 at 7:38 PM, Wesley Hayutin <<a href="mailto:whayutin@redhat.com" target="_blank">whayutin@redhat.com</a>> wrote:<br>
><br>
><br>
> On Wed, Aug 3, 2016 at 6:19 PM, Emilien Macchi <<a href="mailto:emilien@redhat.com" target="_blank">emilien@redhat.com</a>> wrote:<br>
>><br>
>> On Wed, Aug 3, 2016 at 1:33 PM, Wesley Hayutin <<a href="mailto:whayutin@redhat.com" target="_blank">whayutin@redhat.com</a>><br>
>> wrote:<br>
>> ><br>
>> ><br>
>> > On Wed, Aug 3, 2016 at 12:51 PM, James Slagle <<a href="mailto:jslagle@redhat.com" target="_blank">jslagle@redhat.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> On Wed, Aug 03, 2016 at 11:36:57AM -0400, David Moreau Simard wrote:<br>
>> >> > Please hear me out.<br>
>> >> > TL;DR, Let's work upstream and make it awesome so that downstream can<br>
>> >> > be awesome.<br>
>> >> ><br>
>> >> > I've said this before but I'm going to re-iterate that I do not<br>
>> >> > understand why there is so much effort spent around testing TripleO<br>
>> >> > downstream.<br>
>> >> > By downstream, I mean anything that isn't in TripleO or TripleO-CI<br>
>> >> > proper.<br>
>> >> ><br>
>> >> > All this work should be done upstream to make TripleO and it's CI<br>
>> >> > super awesome and this would trickle down for free downstream.<br>
>> >> ><br>
>> >> > The RDO Trunk testing pipeline is composed of two tools, today.<br>
>> >> > The TripleO-Quickstart project [1] is a good example of an initiative<br>
>> >> > that started downstream but always had the intention of being<br>
>> >> > proposed<br>
>> >> > upstream [2] after being "incubated" and fleshed out.<br>
>> >><br>
>> >> tripleo-quickstart was proposed to upstream TripleO as a replacement<br>
>> >> for<br>
>> >> the<br>
>> >> virtual environment setup done by instack-virt-setup. 3rd party CI<br>
>> >> would<br>
>> >> be<br>
>> >> used to gate tripleo-quickstart so that we'd be sure the virt setup was<br>
>> >> always<br>
>> >> working. That was the extent of the CI scope defined in the spec. That<br>
>> >> work is<br>
>> >> not yet completed (see work items in the spec).<br>
>> >><br>
>> >> Now it seems it is a much more all encompassing CI/automation/testing<br>
>> >> project<br>
>> >> that is competing in scope with tripleo-ci itself.<br>
>> ><br>
>> ><br>
>> > IMHO you are correct here.  There has been quite a bit of discussion<br>
>> > about<br>
>> > removing the parts<br>
>> > of oooq that are outside of the original blueprint to replace<br>
>> > instack-virt-setup w/ oooq.   As usual there are many different opinions<br>
>> > here.  I think there are a lot of RDO guys that would prefer a lot of<br>
>> > the<br>
>> > native oooq roles stay where they are,  I think that is short sighted<br>
>> > imho.<br>
>> > I agree that anything outside of the blueprint be removed from oooq.<br>
>> > This<br>
>> > would hopefully allow the upstream to be more comfortable with oooq and<br>
>> > allow us to really start consolidating tools.<br>
>> ><br>
>> > Luckily for the users that still want to use oooq as a full end-to-end<br>
>> > solution the 3rd party roles can be used even after tearing out these<br>
>> > native<br>
>> > roles.<br>
>> ><br>
>> >><br>
>> >><br>
>> >> I'm all for consolidation of these types of tools *if* there is<br>
>> >> interest.<br>
>> ><br>
>> ><br>
>> > Roll call.. is there interest?   +1 from me.<br>
>> ><br>
>> >><br>
>> >><br>
>> >> However, IMO, incubating these things downstream and then trying to get<br>
>> >> them<br>
>> >> upstream or get upstream to adopt them is not ideal or a good example.<br>
>> >> The<br>
>> >> same<br>
>> >> topic came up and was pushed several times with khaleesi, and it just<br>
>> >> never<br>
>> >> happened, it was continually DOA upstream.<br>
>> ><br>
>> ><br>
>> > True, however that could be a result of the downstream perceiving<br>
>> > barriers (<br>
>> > real or not ) in incubating projects in upstream openstack.<br>
>> ><br>
>> >><br>
>> >><br>
>> >> I think it would be fairly difficult to get tripleo-ci to wholesale<br>
>> >> adopt<br>
>> >> tripleo-quickstart at this stage. The separate irc channel from<br>
>> >> #tripleo<br>
>> >> is not<br>
>> >> conducive to consolidation on tooling and direction imo.<br>
>> ><br>
>> ><br>
>> > The irc channel is easily addressed.  We do seem to generate an awful<br>
>> > amount<br>
>> > of chatter though :)<br>
>> ><br>
>> >><br>
>> >><br>
>> >> The scope of quickstart is actually not fully understood by myself.<br>
>> >> I've<br>
>> >> also<br>
>> >> heard from some in the upstream TripleO community as well who are<br>
>> >> confused<br>
>> >> by<br>
>> >> its direction and are facing similar difficulties using its generated<br>
>> >> bash<br>
>> >> scripts that they'd be facing if they were just using TripleO<br>
>> >> documentation<br>
>> >> instead.<br>
>> ><br>
>> ><br>
>> > The point of the generated bash scripts is to create rst documentation<br>
>> > and<br>
>> > reusable scripts for the end user.  Since the documentation and the<br>
>> > generated scripts are equivalent I would expect the same errors,<br>
>> > problems<br>
>> > and issues.  I see this as a good thing really.  We *want* the CI to hit<br>
>> > the<br>
>> > same issues as those who are following the doc.<br>
>> ><br>
>> >><br>
>> >><br>
>> >> I do think that this sort of problem lends itself easily to one off<br>
>> >> implementations as is quite evidenced in this thread. Everyone/group<br>
>> >> wants<br>
>> >> and<br>
>> >> needs to automate something in a different way. And imo, none of these<br>
>> >> tools<br>
>> >> are building end-user or operator facing interfaces, so they're not<br>
>> >> fully<br>
>> >> focused on building something that "just works for everyone". Those<br>
>> >> interfaces<br>
>> >> should be developed in TripleO user facing tooling anyway<br>
>> >> (tripleoclient/openstackclient<wbr>/etc).<br>
>> >><br>
>> >> So, I actually think it's ok in some degree that things have been<br>
>> >> automated<br>
>> >> differently in different tools. Anecdotally, I suspect many users of<br>
>> >> TripleO in<br>
>> >> production have their own automation tools as well. And none of the<br>
>> >> implementations mentioned in this thread would likely meet their needs<br>
>> >> either.<br>
>> ><br>
>> ><br>
>> > This is true..  without a tool in the upstream that addresses ci, dev,<br>
>> > test<br>
>> > use cases across the development cycle this will continue to be the<br>
>> > case.  I<br>
>> > suspect even with a perfect tool, it won't ever be perfect for everyone.<br>
>> ><br>
>> >><br>
>> >><br>
>> >> However, if there is a desire to focus resources on consolidated<br>
>> >> tooling<br>
>> >> and<br>
>> >> someone to drive it forward, then I definitely agree that the effort<br>
>> >> needs<br>
>> >> to<br>
>> >> start upstream with a singular plan for tripleo-ci. From what I gather,<br>
>> >> that<br>
>> >> would be some sort of alignment and reuse of tripleo-quickstart, and<br>
>> >> then<br>
>> >> we<br>
>> >> could build from there.<br>
>> ><br>
>> ><br>
>> > +1<br>
>> ><br>
>> >><br>
>> >><br>
>> >> That could start as a discussion and plan within that community with<br>
>> >> some<br>
>> >> agreed on concensus around that plan. There was an initial thread on<br>
>> >> openstack-dev related to this topic but it is stalled a bit. It could<br>
>> >> be<br>
>> >> continually driven to resolution via specs, the tripleo meeting, email<br>
>> >> or<br>
>> >> irc<br>
>> >> discussion until a plan is formed.<br>
>> ><br>
>> ><br>
>> > +1,  I think the first step is to complete the original blueprint and<br>
>> > move<br>
>> > on from there.<br>
>> > I think there has also been interest in having an in person meeting at<br>
>> > summit.<br>
>> ><br>
>> > Thanks!<br>
>> ><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> -- James Slagle<br>
>> >> --<br>
>> >><br>
>> >> ______________________________<wbr>_________________<br>
>> >> rdo-list mailing list<br>
>> >> <a href="mailto:rdo-list@redhat.com" target="_blank">rdo-list@redhat.com</a><br>
>> >> <a href="https://www.redhat.com/mailman/listinfo/rdo-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/rdo-list</a><br>
>> >><br>
>> >> To unsubscribe: <a href="mailto:rdo-list-unsubscribe@redhat.com" target="_blank">rdo-list-unsubscribe@redhat.co<wbr>m</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > ______________________________<wbr>_________________<br>
>> > rdo-list mailing list<br>
>> > <a href="mailto:rdo-list@redhat.com" target="_blank">rdo-list@redhat.com</a><br>
>> > <a href="https://www.redhat.com/mailman/listinfo/rdo-list" rel="noreferrer" target="_blank">https://www.redhat.com/mailman<wbr>/listinfo/rdo-list</a><br>
>> ><br>
>> > To unsubscribe: <a href="mailto:rdo-list-unsubscribe@redhat.com" target="_blank">rdo-list-unsubscribe@redhat.co<wbr>m</a><br>
>><br>
>> I like how the discussion goes though I have some personal (and<br>
>> probably shared) feeling that I would like to share here, more or less<br>
>> related.<br>
>><br>
>> As a TripleO core developer, I have some frustration to see that a lot<br>
>> of people are involved in making TripleO Quickstart better, while we<br>
>> have a few people actually working on tripleo-ci tool and try to<br>
>> maintain upstream CI stable.<br>
>> As a reminder, tripleo-ci tool is currently the ONLY ONE thing that<br>
>> actually gates TripleO, even if we don't like the tool. It is right<br>
>> now, testing TripleO upstream, everything that is not tested in there<br>
>> will probably break one day downstream CIs.<br>
>> Yes we have this tooling discussion here and that's awesome, but words<br>
>> are words. I would like to see some real engagement to help TripleO CI<br>
>> to converge into something better and not only everyone working on<br>
>> their side.<br>
><br>
><br>
> You have a valid point and reason to be frustrated.<br>
> Is the point here that everyone downstream should use tripleo.sh or that<br>
> everyone should be focused on ci and testing at the tripleo level?<br>
<br>
</div></div>Not everyone should use tripleo.sh. My point is that we should move<br>
forward with a common tool, and stop enlarging the gap between tools.<br>
We have created (and are still doing) a technical dept where we have<br>
multiple tools with a ton of overlap, the more we wait, more difficult<br>
it will be to clean this up.<br></blockquote><div><br></div></div></div><div>+1  </div><div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
>><br>
>><br>
>> Some examples:<br>
>> - TripleO Quickstart (downstream) CI has coverage for undercloud &<br>
>> overcloud upgrades while TripleO CI freshly has a undercloud upgrade<br>
>> job and used to have a overcloud (minor) upgrade job (disabled now,<br>
>> for some reasons related to our capacity to run jobs and also some<br>
>> blockers into code itself).<br>
>> - TripleO CI has some TripleO Heat templates that could also be re-use<br>
>> by TripleO Quickstart (I'm working on moving them from tripleo-ci to<br>
>> THT, WIP here: <a href="https://review.openstack.org/350775" rel="noreferrer" target="_blank">https://review.openstack.org/3<wbr>50775</a>).<br>
>> - TripleO CI deploys Ceph Jewel repository, TripleO Quickstart doesn't.<br>
>> - (...)<br>
><br>
><br>
> As others have mentioned, there are at least 5-10 tools in development that<br>
> are used to deploy tripleo in some CI fashion.  Calling out<br>
> tripleo-quickstart alone is not quite right imho.   There are a number of<br>
> tripleo devs that burn cycles on their own ci tools and maybe that is fine<br>
> thing to do.<br>
<br>
</span>I called quickstart because that's the one I see everyday but my<br>
frustration is about all our tools in general.<br>
I'm actually a OOOQ user and I like this tool, really.<br>
But as you can see, I'm also working on tripleo-ci right now because I<br>
want TripleO CI better and I haven't seen until now some interest to<br>
converge.<br>
James started something cool by trying to deploy an undercloud using<br>
OOOQ from tripleo-ci. That's a start ! We need things like this,<br>
prototyping convergence, and see what we can do.<br></blockquote><div><br></div></div></div><div>+1 working in multiple ci systems is painful, I know your pain!</div><div>I've been playing around w/ Jame's patch [1] to see if I can help.</div><div>I like Jame's approach, I think I may be missing some setup steps that </div><div>nodepool provides.</div><div><br></div><div>[1] <a href="https://review.openstack.org/#/c/348530/" target="_blank">https://review.openstack.o<wbr>rg/#/c/348530/</a></div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
> TripleO-Quickstart is meant to replace instack-virt-setup which it does<br>
> quite well.   The only group that was actually running instack-virt-setup<br>
> was the RDO CI team, upstream had taken it out of the ci system.  I think<br>
> it's not unfair to say gaps have been left for other teams to fill.<br>
<br>
</span>Gotcha. It was just some examples.<br>
<span><br>
>><br>
>><br>
>> We have been having this discussion for a while now but we're still<br>
>> not making much progress here, I feel like we're in statu quo.<br>
>> James mentioned a blueprint, I like it. We need to engage some<br>
>> upstream discussion about this major CI refactor, like we need with<br>
>> specs and then we'll decide if whether or not we need to change the<br>
>> tool, and how.<br>
><br>
><br>
> Well, this would take some leadership imho.  We need some people that are<br>
> familiar with the upstream, midstream and downstream requirements of CI.<br>
> This was addressed at the production chain meetings initially but then<br>
> pretty much ignored.   The leaders responsible at the various stages of a<br>
> build (upstream -> downstream ) failed to take this issue on.  Here we are<br>
> today.<br>
><br>
> Would it be acceptable by anyone.. IF<br>
><br>
> tripleo-quickstart  replaced instack-virt-setup [1] and walked through the<br>
> undercloud install, then handed off to tripleo.sh to deploy, upgrade,<br>
> update, scale, validate etc???<br>
<br>
</span>That's something we can try.<br>
<span><br>
> That these two tools *would* in fact be the the official CI tools of tripleo<br>
> at the upstream, RDO, and at least parts of the downstream?<br>
<br>
</span>My opinion on this is that upstream and downstream CI should only differ on:<br>
* the packages (OSP vs RDO)<br>
* the scenarios (downstream could have customer-specific things)<br>
And that's it. Tools should remain the same IMHO.<br>
<span><br>
> Would that help to ease the current frustration around CI? Emilien what do<br>
> you think?<br>
<br>
</span>I spent the last months working on composable roles and I have now<br>
more time to work on CI; $topic is definitely something where I would<br>
like to help.<br></blockquote><div><br></div></div></div><div>woot, I'm excited that you are freeing up and can be more involved!</div><div>Thanks as usual Emilien!</div><span><font color="#888888"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><font color="#888888">--<br>
Emilien Macchi<br>
</font></span></blockquote></font></span></div><br></div></div>
</blockquote></div><br></div></div></div><div class="gmail_extra">I would add one thing.. If there are folks out there that rely on CI or CI tools and need to be part of this process than please speak up!<br></div><div class="gmail_extra">If you have tools, ideas, requirements now's a pretty good time to be verbose about it.  Some of you already have, some have not.</div></div></blockquote><div><br></div><div>After the quickstart fiasco and the uncertainty around infrared, what I really want to see is a simple, adjustable/configurable and useful replacement for instack-virt (which is the only working dpeloyment tool I currently have). I have several issues with instack-virt, but none of them are critical enough to care much, since my setups tend to be very short lived, and I prefer a faster deployment to features atm.</div><div><br></div><div> </div><div>Any script that will do what instack-virt does, but also will allow me to adjust the parameters of the deployed VMs (disk/s; cpu; ram; NICs), and be able to predict the VMs' IP addresses without a cumbersome framework around it will be perfect. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks</div><div class="gmail_extra"><br></div></div>
<br>______________________________<wbr>_________________<br>
rdo-list mailing list<br>
<a href="mailto:rdo-list@redhat.com">rdo-list@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/rdo-list" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/rdo-list</a><br>
<br>
To unsubscribe: <a href="mailto:rdo-list-unsubscribe@redhat.com">rdo-list-unsubscribe@redhat.<wbr>com</a><br></blockquote></div><br></div></div>