On 4 September 2012 22:16, Trey Morris <trey.mor...@rackspace.com> wrote:
> The transition is going to be difficult either way when you consider data > migrations.. This is one huge aspect. The other concerns deployment, as Quantum interacts with nova-compute in a quite different way and roll out Quantum to replace nova-network is going to be tricky, and the Quantum community should probably start thinking about strategies and best practices for this migration. I don't see however being in a state where nova-network is going to be deprecated and removed anytime soon; partly because of some gaps still existing, and partly because of use cases, especially flat networks, where quantum adds little to no benefit in terms of feature. > Gary, I've scheduled a talk about the future of nova networking. I hope it > to be an open forum of ideas. > Trey, I hope you are allocating a fair amount of time in your session to discuss migration as well. > Also, for what it's worth, I'd like to keep quantum code and nova code as > separate as possible even if ovs is added to nova's network capabilities. > Totally agree. > > -tr3buchet > > On Tue, Sep 4, 2012 at 1:15 AM, Gary Kotton <gkot...@redhat.com> wrote: > >> On 09/03/2012 08:47 PM, rob_hirschf...@dell.com wrote: >> >>> Dan, >>> >>> The challenge here is how to wean off one code base (Nova Net) and into >>> another (Quantum). >>> >>> My thinking was that we'd be able to have more shared components and >>> possibly shared code. This could ease the transition by having operators >>> gain experience with Open vSwitch. Unfortunately, it is likely to also >>> slow the transition because it would be investing more development effort >>> in Nova Networking. >>> >> >> At the moment Quantum supports a number of different technologies, one of >> them is Open vSwitch. I think that if the focus is taken to integrate OVS >> directly into nova networking this would hinder both Nova Networking and >> Quantum. If the resources can be focused on Quantum then we can have one >> solution that supports a variety of networking technologies. >> >> I think that if we focus our resources then hopefully by G-1 we can have >> Quantum replacing the traditional nova networking. I am not sure if a >> session is planned for the summit around this but it would be very good to >> discuss. >> >> >> >>> Note: I'm sorry about the delay in replying. I off so I could include >>> some perspective from investigation. It showed that some of the simplest >>> Nova networking modes could use vSwitch but the popular ones would require >>> duplicating/porting Quantum code back to Nova. >>> >> >> You can do this if you want to very basic bridging. But when you want to >> expose OpenFlow and other technologies you will most probably take a >> approach similar to that of Quantum. >> >> That is my two cents. >> Thanks >> Gary >> >> >>> Once of the things that I believe could help migration is getting >>> Quantum API integrates into abstractions like Fog. In fact, I've proposed >>> a Summit topic about exactly that. >>> >> >> This sounds interesting. It seems that there is also some overlapping - >> for example the address management and DHCP handing by Quantum and FOG >> >> >>> Thanks, >>> >>> Rob >>> >>> -----Original Message----- >>> From: Dan Wendlandt [mailto:d...@nicira.com] >>> Sent: Monday, August 27, 2012 12:57 PM >>> To: Hirschfeld, Rob >>> Cc: openstack@lists.launchpad.net; >>> openstack-dev@lists.openstack.**org<openstack-...@lists.openstack.org> >>> Subject: Re: [Openstack] Quantum vs. Nova-network in Folsom >>> >>> On Sun, Aug 26, 2012 at 12:39 PM,<rob_hirschf...@dell.com> wrote: >>> >>>> Stackers, >>>> >>>> I think this is a reasonable approach and appreciate the clarification >>>> of use-cases. >>>> >>>> We've been discussing using Open vSwitch as the basis for non-Quantum >>>> Nova Networking deployments in Folsom. While not Quantum, it feels like >>>> we're bringing Nova Networking a step closer to some of the core >>>> technologies that Quantum uses. >>>> >>>> I'm interested in hearing what other's in the community think about >>>> this approach. >>>> >>> One of the main reasons we introduced Quantum was to support alternative >>> switching technologies like Open vSwitch. I'd like to hear more about your >>> thoughts, but at first glance, I'm not sure there's a good way to leverage >>> Open vSwitch in a meaningful way with existing nova-network managers, since >>> those network managers are so tightly tied to using the basic linux bridge >>> + vlans. >>> >>> Dan >>> >>> Rob >>>> >>>> -----Original Message----- >>>> From: >>>> openstack-bounces+rob_**hirschfeld=dell.com@lists.**launchpad.net<dell....@lists.launchpad.net> >>>> [mailto:openstack-bounces+rob_**hirschfeld<openstack-bounces%2Brob_hirschfeld> >>>> =dell.com@lists.**launchpad.net <dell....@lists.launchpad.net>] >>>> On Behalf Of Dan Wendlandt >>>> Sent: Friday, August 24, 2012 5:39 PM >>>> To: openstack@lists.launchpad.net; OpenStack Development Mailing List >>>> Subject: [Openstack] Quantum vs. Nova-network in Folsom >>>> >>>> tl;dr both Quantum and nova-network will be core and fully supported >>>> in Folsom. >>>> >>>> Hi folks, >>>> >>>> Thierry, Vish and I have been spending some talking about OpenStack >>>> networking in Folsom, and in particular the availability of nova-network >>>> now that Quantum is a core project. We wanted to share our current >>>> thinking with the community to avoid confusion. >>>> >>>> With a project like OpenStack, there's a fundamental trade-off between >>>> the rate of introducing new capabilities and the desire for stability and >>>> backward compatibility. We agreed that OpenStack is a point in its growth >>>> cycle where the cost of disruptive changes is high. As a result, we've >>>> decided that even with Quantum being core in Folsom, we will also continue >>>> to support nova-network as it currently exists in Folsom. There is, of >>>> couse, overhead to this approach, but we think it is worth it. >>>> >>>> With this in mind, a key question becomes: how do we "direct" users to >>>> the networking option that is right for them. We have the following >>>> guidelines: >>>> >>>> 1) For users who require only very basic networking (e.g., nova-network >>>> Flat, FlatDHCP) there's little difference between Quantum and nova-network >>>> is such basic use cases, so using nova's built-in networking for these >>>> basic use cases makes sense. >>>> >>>> 2) There are many use cases (e.g., tenant API for defined topologies >>>> and addresses) and advanced network technologies (e.g., tunneling rather >>>> than VLANs) that Quantum enables that are simply not possible with >>>> nova-network, so if these advanced capabilities are important to someone >>>> deploying OpenStack, they clearly need to use Quantum. >>>> >>>> 3) There are a few things that are possible in nova-network, but not in >>>> Quantum. Multi-host is the most significant one, but there are bound to be >>>> other gaps, some of which we will uncover only when people try their >>>> particular use case with Quantum. For these, users will have to use >>>> nova-network, with the gaps being covered in Quantum during Grizzly. >>>> >>>> As a result, we plan to structure the docs so that you can do a basic >>>> functionality Nova setup with flat networking without requiring Quantum. >>>> For anything beyond that, we will have an "advanced networking" section, >>>> which describes the different advanced use of OpenStack networking with >>>> Quantum, and also highlight reasons that a user may still want to use >>>> nova-networking over Quantum. >>>> >>>> Moving beyond Folsom, we expect to fully freeze the addition of new >>>> functionality to nova-network, and likely deprecate at least some portions >>>> of the existing nova-network functionality. Likely this will leave the >>>> basic flat and flat + dhcp nova networking intact, but reduce complexity in >>>> the nova codebase by removing more advanced networking scenarios that can >>>> also be achieved via Quantum. This means that even those using >>>> nova-network in Folsom should still be evaluating Quantum if they >>>> networking needs beyond flat networking, such that this feedback can be >>>> incorporated into the Grizzly deliverable of Quantum. >>>> >>>> Thanks, >>>> >>>> Dan >>>> >>>> >>>> -- >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> Dan Wendlandt >>>> Nicira, Inc: www.nicira.com >>>> twitter: danwendlandt >>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> >>>> ______________________________**_________________ >>>> Mailing list: >>>> https://launchpad.net/~**openstack<https://launchpad.net/~openstack> >>>> Post to : openstack@lists.launchpad.net >>>> Unsubscribe : >>>> https://launchpad.net/~**openstack<https://launchpad.net/~openstack> >>>> More help : >>>> https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp> >>>> >>> >>> >>> -- >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> Dan Wendlandt >>> Nicira, Inc: www.nicira.com >>> twitter: danwendlandt >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> ______________________________**_________________ >>> Mailing list: >>> https://launchpad.net/~**openstack<https://launchpad.net/~openstack> >>> Post to : openstack@lists.launchpad.net >>> Unsubscribe : >>> https://launchpad.net/~**openstack<https://launchpad.net/~openstack> >>> More help : >>> https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp> >>> >> >> >> ______________________________**_________________ >> Mailing list: >> https://launchpad.net/~**openstack<https://launchpad.net/~openstack> >> Post to : openstack@lists.launchpad.net >> Unsubscribe : >> https://launchpad.net/~**openstack<https://launchpad.net/~openstack> >> More help : >> https://help.launchpad.net/**ListHelp<https://help.launchpad.net/ListHelp> >> > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp