On 2 July 2012 16:46, dan wendlandt <email address hidden> wrote:

> On Mon, Jul 2, 2012 at 10:57 AM, Salvatore Orlando <
> <email address hidden>> wrote:
>
> > I agree that the change in the network manager sounds more reasonable for
> > the reason Dan pointed out in his comment.
> > Adding an explicit check for the value of network_api_class will
> > definitely work, even if this is probably not the best architectural
> > patterns, as we might want to keep the network manager completely
> > independent of Quantum.
> >
> > I recall there was a plan to deprecate and possibly get rid of nova-
> > manager during Folsom. Is that still going to happen?
> >
>
> Well, we can't get rid of the network manager stuff entirely in Folsom, as
> it will be needed for backward compatibility with VlanManager, FlatManager,
> etc.  However, based on the email thread, I think there's consensus for
> removing v1 quantum support, which would allow us to get rid of all
> Quantum-specific network-manager code (which is actually a fairly big chunk
> of code).  See:
> https://blueprints.launchpad.net/quantum/+spec/remove-v1-related-code
>
>
My bad - I was actually thinking of "nova-manage" not "nova network
manager".

One way of  implement this bug fix would be to have every network manager
raise when they are initialized if we are using Quantum v2.






> Dan
>
>
> >
> > --
> > You received this bug notification because you are a member of Netstack
> > Core Developers, which is subscribed to quantum.
> > https://bugs.launchpad.net/bugs/1019895
> >
> > Title:
> >   disable nova-manage network actions if using Quantum v2
> >
> > Status in OpenStack Compute (Nova):
> >   New
> > Status in OpenStack Quantum (virtual network service):
> >   Confirmed
> >
> > Bug description:
> >   When using nova with quantum v2 API, all CRUD operations should be
> >   done directly against the quantum API, rather than using nova-manage.
> >
> >   However, even when no nova-network is running (as is the case with
> >   Quantum v2), nova-manage calls to do things like create networks will
> >   still succeed, as nova-manage will simply load the default network
> >   manager, and make the calls, which will result in writing to the nova
> >   database.  These calls will appear to succeed, even though the
> >   networks, floating ips, fixed ips, etc. are irrelevant to the quantum
> >   deployment.
> >
> >   We should add checks to nova (nova-manage?) to prevent this from
> >   happening.
> >
> >   One option would be for the base NetworkManager class to check and
> >   make sure that a network manager will actually be used (i.e., check
> >   that the network_api_class is not set to
> >   "nova.network.quantumv2.api.API").
> >
> >   Other options would be to modify nova-manage, but that seems less
> >   robust.
> >
> > To manage notifications about this bug go to:
> > https://bugs.launchpad.net/nova/+bug/1019895/+subscriptions
> >
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> --
> You received this bug notification because you are a member of Netstack
> Core Developers, which is subscribed to quantum.
> https://bugs.launchpad.net/bugs/1019895
>
> Title:
>   disable nova-manage network actions if using Quantum v2
>
> Status in OpenStack Compute (Nova):
>   New
> Status in OpenStack Quantum (virtual network service):
>   Confirmed
>
> Bug description:
>   When using nova with quantum v2 API, all CRUD operations should be
>   done directly against the quantum API, rather than using nova-manage.
>
>   However, even when no nova-network is running (as is the case with
>   Quantum v2), nova-manage calls to do things like create networks will
>   still succeed, as nova-manage will simply load the default network
>   manager, and make the calls, which will result in writing to the nova
>   database.  These calls will appear to succeed, even though the
>   networks, floating ips, fixed ips, etc. are irrelevant to the quantum
>   deployment.
>
>   We should add checks to nova (nova-manage?) to prevent this from
>   happening.
>
>   One option would be for the base NetworkManager class to check and
>   make sure that a network manager will actually be used (i.e., check
>   that the network_api_class is not set to
>   "nova.network.quantumv2.api.API").
>
>   Other options would be to modify nova-manage, but that seems less
>   robust.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/nova/+bug/1019895/+subscriptions
>