Comment 3 for bug 1019895

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

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
~~~~~~~~~~~~~~~~~~~~~~~~~~~