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-requ...@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-requ...@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-requ...@lists.openstack.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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
