<div dir="ltr">Steven/<span style="font-size:12.8px;white-space:nowrap">Emilien</span><span style="font-size:12.8px;white-space:nowrap">,</span><div><span style="font-size:12.8px;white-space:nowrap"><br></span></div><div><span style="font-size:12.8px;white-space:nowrap">PLUMgrid will be happy to collaborate in the effort. A much needed effort for healthy integration of vendors with TripleO. </span></div><div><br></div><div><span style="font-size:12.8px">W</span><span style="font-size:12.8px">hat level of commitment would be expected from our side for this effort? </span><span style="font-size:12.8px">As Steve mentioned each vendor will have some requirements like customizing the overcloud images so lets list them down to scope the effort.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Let me know if you want to discuss this in any TripleO meeting.</span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 25, 2016 at 6:20 PM, Steven Hardy <span dir="ltr"><<a href="mailto:shardy@redhat.com" target="_blank">shardy@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 class="HOEnZb"><div class="h5">On Wed, Aug 24, 2016 at 03:11:38PM -0400, Emilien Macchi wrote:<br>
> TripleO does support multiple vendors for different type of backends.<br>
> Here are some examples:<br>
> Neutron networking: Cisco, Nuage, Opencontrail, Midonet, Plumgrid, 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>
</div></div>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 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>
<span class=""><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>
</span>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>
<div class="HOEnZb"><div class="h5"><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.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Regards,<div>Qasim Sarfraz</div></div></div>
</div>