On Wed, 2015-12-23 at 17:45 +0100, Filip Pytloun wrote: > Hello, > > some more fixes are here: > https://review.opencontrail.org/#/q/status:open+owner:Jakub,n,z > > Not all components are Openstack version-specific. > I think it's only python-neutronclient, contrail-neutron-plugin, > nova-vif-driver and contrail-heat.
Right. > The remaining (eg. contrail-controller) can be run even > without Openstack. That's probably true, but completely uninteresting for us. :-) AFAIU Juniper do consider different OpenContrail releases for different OpenStack releases. According to Pedro on 11th of October ( http://lists.opencontrail.org/pipermail/dev_lists.opencontrail.org/2015-October/002575.html ), it appears the main issue is the complexity of managing OpenStack deplyoments in the CI pipeline. I've heard that Kilo is to be considered for R3.0. I've also seen a bugfix for Kilo merge into R2.20. For any meaningful OpenStack use case of OpenContrail, I believe what matters is to be able to run it: a) stable (requires bugfixes), b) with a reasonable lag off OpenStack releases (usually minor changes release to release). There is currently no clear indication of upstream plans for Kilo, Liberty or Mitaka. Per Pedro's mail above, one can attempt to get fixes merged into master, but if the current OpenStack releases aren't being considered, it's potentially an effort with zero ROI. So we have the case of not only the inadequacy of the upstream packaging system, but also the OpenStack support, which forces users to DIY at home - which is a completely fine choice to make - but if there's no working structure of contributing back, it seems to me the cost of using OpenContrail goes up considerably. The only review I see on your and Jakub's patches for Liberty linked above, is from Sebastien Badia, and in one case Pramod Venkatesh. Some guidance from Juniper would probably go a long way of 'clearing the path' for more active contributions and reviews from the community IMHO. A first step could be at least policy wise OK on merging fixes for basically any newer OpenStack release into master, regardless of its CI IMO. In other words, gate tests against CI-pipeline covering only the commercially supported releases is still better than having to manage an ever-so-diverging fork. Regards, Martin > Filip > > On 2015/12/23 15:03, Martin Millnert wrote: > > Hi Filip, > > > > On Wed, 2015-12-23 at 12:33 +0100, Filip Pytloun wrote: > > > Hello Martin, > > > > > > we are currently running custom Opencontrail build with patches to > > > support both kilo and liberty. > > > > > > As far as I know these patches are not yet merged upstream. > > > > Is it these: > > https://review.opencontrail.org/#/q/status:open+owner:Filip,n,z > > > > Are there more, for example from colleagues of yours? > > > > > You can find our up-to-date opencontrail packages here: > > > https://launchpad.net/~tcpcloud/+archive/ubuntu/contrail-2.20 > > > > > > Some more packages (also not directly connected with opencontrail but > > > eg. python-neutronclient with contrail extensions) per openstack release > > > are here: > > > https://launchpad.net/~tcpcloud/+archive/ubuntu/kilo > > > https://launchpad.net/~tcpcloud/+archive/ubuntu/liberty > > > > > > Patched sources are available in our forked github repositories: > > > https://github.com/tcpcloud?utf8=%E2%9C%93&query=contrail > > > > I checked for example contrail-controller: > > https://github.com/Juniper/contrail-controller/compare/R2.20...tcpcloud:R2.20 > > https://github.com/Juniper/contrail-controller/compare/R2.21.x...tcpcloud:R2.21.x > > I couldn't find any more than those two commits (per branch). > > > > If those commits are all the positive delta there is in your fork, it > > looks like you don't support the use of SSL in your distribution. > > > > Do you keep the remaining patches outside contrail-controller? > > > > > If you are interested in these builds, you can also check our complete > > > Opencontrail + Openstack distribution with automated deployment using > > > SaltStack: http://www.opentcpcloud.org/ > > > > Thanks, but we're building our own packages from source on EL7, so it > > doesn't really help. > > > > My concern is first of all, i.e. the feasibility of a more clear release > > plan w.r.t. OpenStack support, so that users can begin submitting fixes > > properly, and run against an upstream branch that has a sort of > > stable:ish goal. > > > > I.e., I'd really like to see branches made with a pace that matches > > OpenStack releases, without unnecessary delay. There's no foul, IMO, in > > having a Mitaka branch open already. > > > > Regards, > > Martin > > > _______________________________________________ Dev mailing list [email protected] http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
