<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Thanks Emilien. Response inline:</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span>
</span>Since Plumgrid is a proprietary software I'm not sure now how we could<br>
test it to be honest but you might have some idea to do it.<br>
If that's something we can download from the internet and install<br>
during a tripleo deployment, then we could use our current multinode<br>
jobs that run in OpenStack Infra.</blockquote><div> </div><div>PLUMgrid has a standard RPM based installation and we can provide these packages for downloading and installation in pipeline.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
It it require specific hardware or more resources than we can provide,<br>
we might consider third party CI using plumgrid servers if you're<br>
willing to it.<br>
<br></blockquote><div> </div><div>We don't require any specific hardware but we do have some minimum specification requirement for the servers.  <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Let's first see how we could install your software and from there<br>
investigate a first integration.<br></blockquote><div><br></div><div>I have added PLUMgrid specific details here [1]. We can discuss the TripleO CI solution around it. I am interested in how do we kickoff this effort. Which OpenStack release we are planning to target? </div><div><br></div><div>Also, Other vendors are welcome to add there details here [1] as well.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
Thanks for your collaboration!</blockquote><div><br></div><div>Your Welcome! </div><div><br></div><div>[1] - <a href="https://etherpad.openstack.org/p/tripleo-ci-vendor-collaboration">https://etherpad.openstack.org/p/tripleo-ci-vendor-collaboration</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div>
>> > Neutron networking: Cisco, Nuage, Opencontrail, Midonet, Plumgrid,<br>
>> > Biswitch<br>
>> > Cinder: Dell, Netapp, Ceph<br>
>> ><br>
>> > TripleO developers are struggling to maintain the environment files<br>
>> > that allow to deploy those backends because it's very hard to test<br>
>> > them:<br>
>> > - not enough hardware<br>
>> > - zero knowledge at how to deploy the actual backend system<br>
>> > - no time to test all backends<br>
>> ><br>
>> > Recently, we made some changes in TripleO CI that will help us to<br>
>> > scale the way we test TripleO in the future.<br>
>> > One of those changes is that we can now deploy TripleO using nodepool<br>
>> > instances like devstack jobs.<br>
>> ><br>
>> > I wrote a prototype of TripleO job scenario:<br>
>> > <a href="https://review.openstack.org/#/c/360039/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/360039/</a> that will allow us to have<br>
>> > more CI jobs with less services installed on each, so we can save<br>
>> > performances while increasing services coverage.<br>
>> > I would like to re-use those bits to test our vendors backends.<br>
>> ><br>
>> > Here's the proposal:<br>
>> > - for vendors backends that can be deployed using TripleO itself<br>
>> > (open-source backend systems like OpenContrail, Midonet, etc): we<br>
>> > could re-use the scenario approach by adding new scenarios for each<br>
>> > backend.<br>
>> > The jobs would only be triggered if we touch environment files related<br>
>> > on the backend in THT or the puppet profiles for the backend in<br>
>> > puppet-tripleo or the puppet backend class in puppet-neutron for the<br>
>> > backend (all thanks to Zuul magic).<br>
>><br>
>> This sounds good, my only concern is how we handle things breaking when<br>
>> something outside of tripleo changes (e.g triage of bugs related to the<br>
>> vendor backends).<br>
>><br>
>> If we can get some commitment folks will show up to help with that then<br>
>> definitely +1 on doing this.<br>
>><br>
>> There are some additional complexities around images we'll need to<br>
>> consider<br>
>> too, as some (all?) of these backends require customization of the<br>
>> overcloud images (e.g adding some additional pieces related to the enabled<br>
>> vendor backend).<br>
>><br>
>> > - for vendors backends that can't be deployed using TripleO itself<br>
>> > (not implemented in the services and / or not open-source):<br>
>> > Like most of you probably did for devstack jobs in neutron/cinder's<br>
>> > gates, work with us to implement CI jobs that would deploy TripleO<br>
>> > with your backend. I don't have the exact technical solution right<br>
>> > now, but at least I would like to know who would be interested by this<br>
>> > collaboration.<br>
>><br>
>> This also sounds good, but it's unclear to me atm if we have any folks<br>
>> willing to step up and do this work.  If people with bandwidth to do this<br>
>> can be identified then it would be good investigate.<br>
>><br>
>> Steve<br>
>><br>
>> ______________________________<wbr>______________________________<wbr>______________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Regards,<br>
> Qasim Sarfraz<br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
</div></div><span><font color="#888888">Emilien Macchi<br>
</font></span><div><div><br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div dir="ltr">Regards,<div>Qasim Sarfraz</div></div></div>
</div></div>