On Nov 16, 2013, at 9:43 AM, Dean Troyer <dtro...@gmail.com> wrote: > On Sat, Nov 16, 2013 at 11:15 AM, Harshad Nakil <hna...@contrailsystems.com> > wrote: > Sean, > We have diff in three repositories. > Nova, Neutron and devstack. Each review is requiring other to happen first. > Do you have recommendation how do we deal with these dependencies? > > First off, if you rebase on to a current DevStack you will find a new plugin > mechanism specifically designed to address this sort of problem.
Dean, Does it address the catch-22 problem that a Neutron reviewer asks for the plugin to be accepted upstream into devstack as pre-condition for acceptance whether a devstack reviewer as for the plugin to be upstreamed into Neutron first ? > You've already worked out the plugin bits for Neutron, the parts for > stack.sh are similar, located in extras.d. http://devstack.org/plugins.html > describes how it works. > > Also, DevStack does not install support services that are not packaged in the > underlying distro. Look at Docker's split between the support service(s) > that start before stack.sh runs and the parts that specifically configure > Nova. Can you please elaborate as to what are "support services" in this context ? > > The patches to Neutron and Nova should be handled by setting the *_BRANCH and > *_REPO variables to point to your repo and branch. DevStack will check them > out for you when it installs the project source. That would mean forking Neutron and Nova; the code in question is a plugin. It actually show not need to be a diff other than for the fact that the Nova network plugins have so far been done via "if ... else" statements in nova/virt/libvirt/vif.py. The patches that are being applied by the script have been submitted for review. Using a patch approach is helpful in attempting to demonstrate that the resulting code works against the master branch of Nova/Neutron. > > You should be able to re-arrange things to support this architecture. Also, > expect to break the remaining DevStack changes into digestible bits. As it > stands, your branch is unmergable, even if it was based on a semi-current > commit. Can you please suggest a sequence of steps... ? I understand that it makes sense to follow the plugin documentation specified above. That would be the first step. But it is not clear to me how to break it down further while having something that is still functional. > > FWIW, the opencontrail.org website appears to be off the air making it harder > to understand what it is you are trying to integrate here. It must have been a transient error. The web site is working at the moment. OpenContrail is a network virtualization solution that provides a service model comparable to AWS VPC without the need for L2 support for the underlying switching infrastructure. It implements distributed router functionality so that traffic that crosses different Neutron networks doesn't have to traverse a router appliance (virtual or otherwise). Thank you, Pedro. > > dt > > -- > > Dean Troyer > dtro...@gmail.com > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
