<div dir="ltr">Hi Anita, <div><br></div><div>Thanks for the clarification. I will plan on attending the summit session on this topic (proposed by Kurt, I believe). </div><div>I have to admit that I have to always keep an eye out to ensure nothing is broken in our CI because of any upgrade of packages, etc. and act accordingly. If new unified framework can reduce/eliminate this effort, I would like to at least understand it and discuss with the participants - and, may join in. </div><div><br></div><div>Thanks for the good work. </div><div>-Sukhdev</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 21, 2015 at 11:25 AM, Anita Kuno <span dir="ltr"><<a href="mailto:anteaya@anteaya.info" target="_blank">anteaya@anteaya.info</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 04/20/2015 04:39 PM, Sukhdev Kapur wrote:<br>
> Hi Ramy,<br>
><br>
> While I agree, in principal, with this line of thinking and goal, my<br>
> concern will be how much extra work is it going to create for existing CI<br>
> owners?<br>
> Our Ci system has been stable for a long time, and we put in a good amount<br>
> of effort to get it to that point. Our CI is not based upon zuul framework.<br>
> Zuul was still under discussion at the time when we put together our CI. We<br>
> use Jenkins as front end, along with Gerrit triggers, and AWS for<br>
> posting/preserving results/log.  We have dedicated back-end servers for<br>
>  testing.<br>
><br>
> My paranoia at this point will be to learn a new framework, risk breaking<br>
> things and taking a huge effort to get things stabilized - without much<br>
> additional ROI.<br>
> Am I overreacting here or does my argument makes sense?<br>
><br>
> I wonder how many folks will be in that camp?<br>
><br>
> Sukhdev<br>
</span>Hi Sukhdev:<br>
<br>
What is being offered is an opportunity to pool efforts for those who<br>
wish to participate. There is no pressure to participate if you are<br>
concerned that you would compromise the integrity of a stable system.<br>
You and others that have put in so much work are to be lauded for your<br>
commitment to your goal, thank you. Ramy's efforts in no way are an<br>
attempt to degrade the stability you have created.<br>
<br>
Part of the exhaustion level folks feel in this space, at all points in<br>
the spectrum, is the cost of maintenance. In infra we are constantly<br>
dealing with problems from operators and it would reduce the burden on<br>
us, as well as reduce the tension on operators, if we had a solution<br>
that was easier to maintain. The more people running the same structure,<br>
the easier any one issue is to solve (hopefully).<br>
<br>
The goal is once the structure is in place that OpenStack's Infra would<br>
also consume it, enabling common bugs to be discovered and fixed upstream.<br>
<br>
Noone is forced to participate nor are they going to be forced to<br>
operate this structure. This is simply a chance to work together on a<br>
direction which infra would very much like to see in place.<br>
<br>
Thanks Sukhdev,<br>
Anita.<br>
<div class="HOEnZb"><div class="h5">><br>
><br>
><br>
><br>
> On Sun, Apr 19, 2015 at 10:17 PM, Asselin, Ramy <<a href="mailto:ramy.asselin@hp.com">ramy.asselin@hp.com</a>> wrote:<br>
><br>
>>  All Third-Party CI operators:<br>
>><br>
>><br>
>><br>
>> We’ve got 85 Third Party CI systems registered in the wiki[1], all of them<br>
>> running a variety of closed & open-source solutions.<br>
>><br>
>> Instead of individually maintaining all those similar solutions, let’s<br>
>> join together and collectively maintain a single solution.<br>
>><br>
>><br>
>><br>
>> If that sounds good to you, there’s an Infra-spec that’s been approved [2]<br>
>> to refactor much of what the Infrastructure team uses for the upstream<br>
>> “Jenkins” CI to be more easily reusable by many of us.<br>
>><br>
>><br>
>><br>
>> We’ve got stories defined [3], and a few patches submitted. We’re using<br>
>> the gerrit-topic “downstream-puppet” [4].<br>
>><br>
>><br>
>><br>
>> For example, we’ve got the first part under review for the “Log Server”,<br>
>> which creates your own version of <a href="http://logs.openstack.org/" target="_blank">http://logs.openstack.org/</a><br>
>><br>
>><br>
>><br>
>> If anyone is interested in migrating towards a common solution, reply, or<br>
>> ping me IRC (asselin) on Freenode #openstack-infra, or join some of the<br>
>> third party ci meetings [5].<br>
>><br>
>><br>
>><br>
>> Thanks!<br>
>><br>
>> Ramy<br>
>><br>
>><br>
>><br>
>> [1] <a href="https://wiki.openstack.org/wiki/ThirdPartySystems" target="_blank">https://wiki.openstack.org/wiki/ThirdPartySystems</a><br>
>><br>
>> [2]<br>
>> <a href="http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html" target="_blank">http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html</a><br>
>><br>
>> [3] <a href="https://storyboard.openstack.org/#!/story/2000101" target="_blank">https://storyboard.openstack.org/#!/story/2000101</a><br>
>><br>
>> [4] <a href="https://review.openstack.org/#/q/topic:downstream-puppet,n,z" target="_blank">https://review.openstack.org/#/q/topic:downstream-puppet,n,z</a><br>
>><br>
>> [5]<br>
>> <a href="https://wiki.openstack.org/wiki/Meetings/ThirdParty#Weekly_Third_Party_meetings" target="_blank">https://wiki.openstack.org/wiki/Meetings/ThirdParty#Weekly_Third_Party_meetings</a><br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>