Open Stack

Steven/Emilien,

PLUMgrid will be happy to collaborate in the effort. A much needed effort
for healthy integration of vendors with TripleO.

What level of commitment would be expected from our side for this effort? As
Steve mentioned each vendor will have some requirements like
customizing the overcloud images so lets list them down to scope the effort.

Let me know if you want to discuss this in any TripleO meeting.


On Thu, Aug 25, 2016 at 6:20 PM, Steven Hardy <shardy at redhat.com> wrote:

> On Wed, Aug 24, 2016 at 03:11:38PM -0400, Emilien Macchi wrote:
> > TripleO does support multiple vendors for different type of backends.
> > Here are some examples:
> > Neutron networking: Cisco, Nuage, Opencontrail, Midonet, Plumgrid,
> Biswitch
> > Cinder: Dell, Netapp, Ceph
> >
> > TripleO developers are struggling to maintain the environment files
> > that allow to deploy those backends because it's very hard to test
> > them:
> > - not enough hardware
> > - zero knowledge at how to deploy the actual backend system
> > - no time to test all backends
> >
> > Recently, we made some changes in TripleO CI that will help us to
> > scale the way we test TripleO in the future.
> > One of those changes is that we can now deploy TripleO using nodepool
> > instances like devstack jobs.
> >
> > I wrote a prototype of TripleO job scenario:
> > https://review.openstack.org/#/c/360039/ that will allow us to have
> > more CI jobs with less services installed on each, so we can save
> > performances while increasing services coverage.
> > I would like to re-use those bits to test our vendors backends.
> >
> > Here's the proposal:
> > - for vendors backends that can be deployed using TripleO itself
> > (open-source backend systems like OpenContrail, Midonet, etc): we
> > could re-use the scenario approach by adding new scenarios for each
> > backend.
> > The jobs would only be triggered if we touch environment files related
> > on the backend in THT or the puppet profiles for the backend in
> > puppet-tripleo or the puppet backend class in puppet-neutron for the
> > backend (all thanks to Zuul magic).
>
> This sounds good, my only concern is how we handle things breaking when
> something outside of tripleo changes (e.g triage of bugs related to the
> vendor backends).
>
> If we can get some commitment folks will show up to help with that then
> definitely +1 on doing this.
>
> There are some additional complexities around images we'll need to consider
> too, as some (all?) of these backends require customization of the
> overcloud images (e.g adding some additional pieces related to the enabled
> vendor backend).
>
> > - for vendors backends that can't be deployed using TripleO itself
> > (not implemented in the services and / or not open-source):
> > Like most of you probably did for devstack jobs in neutron/cinder's
> > gates, work with us to implement CI jobs that would deploy TripleO
> > with your backend. I don't have the exact technical solution right
> > now, but at least I would like to know who would be interested by this
> > collaboration.
>
> This also sounds good, but it's unclear to me atm if we have any folks
> willing to step up and do this work.  If people with bandwidth to do this
> can be identified then it would be good investigate.
>
> Steve
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards,
Qasim Sarfraz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160826/ff73a5c5/attachment.html>