Comment 4 for bug 1019895

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
>