<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 3, 2016 at 12:51 PM, James Slagle <span dir="ltr"><<a href="mailto:jslagle@redhat.com" target="_blank">jslagle@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">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 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 proposed<br> > upstream [2] after being "incubated" and fleshed out.<br> <br> </span>tripleo-quickstart was proposed to upstream TripleO as a replacement for the<br> virtual environment setup done by instack-virt-setup. 3rd party CI would be<br> used to gate tripleo-quickstart so that we'd be sure the virt setup was always<br> working. That was the extent of the CI scope defined in the spec. That 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 project<br> that is competing in scope with tripleo-ci itself.<br></blockquote><div><br></div><div>IMHO you are correct here. There has been quite a bit of discussion about removing the parts</div><div>of oooq that are outside of the original blueprint to replace instack-virt-setup w/ oooq. As usual there are many different opinions here. I think there are a lot of RDO guys that would prefer a lot of the native oooq roles stay where they are, I think that is short sighted imho. I agree that anything outside of the blueprint be removed from oooq. This would hopefully allow the upstream to be more comfortable with oooq and allow us to really start consolidating tools.</div><div><br></div><div>Luckily for the users that still want to use oooq as a full end-to-end solution the 3rd party roles can be used even after tearing out these native roles.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> I'm all for consolidation of these types of tools *if* there is interest.<br></blockquote><div><br></div><div>Roll call.. is there interest? +1 from me.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> However, IMO, incubating these things downstream and then trying to get them<br> upstream or get upstream to adopt them is not ideal or a good example. The same<br> topic came up and was pushed several times with khaleesi, and it just never<br> happened, it was continually DOA upstream.<br></blockquote><div><br></div><div>True, however that could be a result of the downstream perceiving barriers ( real or not ) in incubating projects in upstream openstack. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> I think it would be fairly difficult to get tripleo-ci to wholesale adopt<br> tripleo-quickstart at this stage. The separate irc channel from #tripleo is not<br> conducive to consolidation on tooling and direction imo.<br></blockquote><div><br></div><div>The irc channel is easily addressed. We do seem to generate an awful amount of chatter though :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> The scope of quickstart is actually not fully understood by myself. I've also<br> heard from some in the upstream TripleO community as well who are confused by<br> its direction and are facing similar difficulties using its generated bash<br> scripts that they'd be facing if they were just using TripleO documentation<br> instead.<br></blockquote><div><br></div><div>The point of the generated bash scripts is to create rst documentation and reusable scripts for the end user. Since the documentation and the generated scripts are equivalent I would expect the same errors, problems and issues. I see this as a good thing really. We *want* the CI to hit the same issues as those who are following the doc. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <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 wants and<br> needs to automate something in a different way. And imo, none of these tools<br> are building end-user or operator facing interfaces, so they're not fully<br> focused on building something that "just works for everyone". Those interfaces<br> should be developed in TripleO user facing tooling anyway<br> (tripleoclient/openstackclient/etc).<br> <br> So, I actually think it's ok in some degree that things have been automated<br> differently in different tools. Anecdotally, I suspect many users of 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 either.<br></blockquote><div><br></div><div>This is true.. without a tool in the upstream that addresses ci, dev, test use cases across the development cycle this will continue to be the case. I suspect even with a perfect tool, it won't ever be perfect for everyone.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> However, if there is a desire to focus resources on consolidated tooling and<br> someone to drive it forward, then I definitely agree that the effort needs to<br> start upstream with a singular plan for tripleo-ci. From what I gather, that<br> would be some sort of alignment and reuse of tripleo-quickstart, and then we<br> could build from there.<br></blockquote><div><br></div><div>+1</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> That could start as a discussion and plan within that community with 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 be<br> continually driven to resolution via specs, the tripleo meeting, email or irc<br> discussion until a plan is formed.<br></blockquote><div><br></div><div>+1, I think the first step is to complete the original blueprint and move on from there.</div><div>I think there has also been interest in having an in person meeting at summit.</div><div><br></div><div>Thanks!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> --<br> -- James Slagle<br> --<br> <div class="HOEnZb"><div class="h5"><br> _______________________________________________<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/mailman/listinfo/rdo-list</a><br> <br> To unsubscribe: <a href="mailto:rdo-list-unsubscribe@redhat.com">rdo-list-unsubscribe@redhat.com</a><br> </div></div></blockquote></div><br></div></div>