On Thu, Apr 23, 2015 at 1:31 PM, Fox, Kevin M <kevin....@pnnl.gov> wrote:
> Yeah. In the end, its what git repo the source for a given rpm you > install comes from. Ops will not care that neutron-openvswitch-agent comes > from repo foo.git instead of bar.git. > > That's really the tl;dr of the proposed split. Thanks, Kyle > Thanks, > Kevin > ------------------------------ > *From:* Armando M. [arma...@gmail.com] > *Sent:* Thursday, April 23, 2015 9:10 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [Neutron] A big tent home for Neutron > backend code > > >>> I agree with henry here. >> Armando, If we use your analogy with nova that doesn't build and >> deliver KVM, we can say that Neutron doesn't build or deliver OVS. It >> builds a driver and an agent which manage OVS, just like nova which >> provides a driver to manage libvirt/KVM. >> Moreover, external SDN controllers are much more complex than Neutron >> with its reference drivers. I feel like forcing the cloud admin to deploy >> and maintain an external SDN controller would be a terrible experience for >> him if he just needs a simple way manage connectivity between VMs. >> At the end of the day, it might be detrimental for the neutron project. >> >> > > I don't think that anyone is saying that cloud admins are going to be > forced to deploy and maintain an external SDN controller. There are plenty > of deployment examples where people are just happy with network > virtualization the way Neutron has been providing for years and we should > not regress on that. To me it's mostly a matter of responsibilities of who > develops what, and what that what is :) > > The consumption model is totally a different matter. > > > __________________________________________________________________________ > 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 > >
__________________________________________________________________________ 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