Open Stack

Thanks Emilien. Response inline:


> Since Plumgrid is a proprietary software I'm not sure now how we could
> test it to be honest but you might have some idea to do it.
> If that's something we can download from the internet and install
> during a tripleo deployment, then we could use our current multinode
> jobs that run in OpenStack Infra.


PLUMgrid has a standard RPM based installation and we can provide these
packages for downloading and installation in pipeline.


> It it require specific hardware or more resources than we can provide,
> we might consider third party CI using plumgrid servers if you're
> willing to it.
>
>
We don't require any specific hardware but we do have some minimum
specification requirement for the servers.

Let's first see how we could install your software and from there
> investigate a first integration.
>

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?

Also, Other vendors are welcome to add there details here [1] as well.

Thanks for your collaboration!


Your Welcome!

[1] - https://etherpad.openstack.org/p/tripleo-ci-vendor-collaboration


> >> > 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.op
> enstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > Regards,
> > Qasim Sarfraz
> >
> > ____________________________________________________________
> ______________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.op
> enstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Emilien Macchi
>
> __________________________________________________________________________
> 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/20160906/48e7c268/attachment.html>