disable nova-manage network + related cmds if using Quantum v2

One advantage of modifying the network manager directly is that it would also notify people who mistakenly run nova-network when quantum v2 is being used.

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?

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

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 subscri...

I've implemented the changes in the network manager, but it unfortunately misses nova-manage network-list and nova-manage network-modify, which operate directly on the DB.
So, some dirty hacks are still required.

Fix proposed to branch: master
Review: https://review.openstack.org/9754

I don't think this ever merged. Untargeting for folsom.

It didn't merge but it's quite critical to fix this before release, I think.

It's terribly easy to call nova-manage network create:

- because the internet has a long memory and there are plenty of docs telling you to do exactly that
- because, even in Folsom, at least some of the time, it is in fact the *correct* thing to be doing (non-Quantum installations).

So, you call nova-manage, you get a network ID, and nothing will accept it. It's not at all obvious at this point that you've done anything wrong, let alone what the problem is.

Yes, I agree this is important, so i'm targeting it for RC1. Please try to make these changes as quickly as possible, as we don't control core dev resources within nova, so the longer we wait, the harder it will be to get this bug merged.

I think we may even want to expand the scope of this a bit more to making sure any 'nova-manage' + 'nova' commands issue errors if quantum does not support the operation. For example, nova has commands for using floating-ips, but with quantum floating ips should be created/destroyed/associated/disassociated via quantum.

We want to make sure that the user gets a message like: "It looks like you have nova configured to use Quantum. If so, doing operation X should be done via the 'quantum' utility"

Salvatore, are you still working on this bug? Otherwise we should un-assign it and try to find someone else from the community who can work on it. Thanks.

I noticed it was re-prooritized on Friday.
With the current approach (modifying the base network manager) we can have it working only with some hacks (see code on gerrit).

Yes, I am still working on this bug. I think the best approach is to do as many checks as possible in the network manager, but also in nova-manage directly for those operation which only interact with the db, without contacting the network manager.

If you're going to use the hack in the patch, I suggest you do it by adding a 'supports_db_network_mgmt()' function to the manager class, rather than just throwing an error on the init. It gives you a clear reason why you'd do the import - as opposed to 'I shall import this, despite never using it, because I know it will throw an error'.

Ian,

I am going to remove the hack from the patch. What I did was just ugly and error-prone.
I believe it might be better two tweak nova-manage directly at this stage. It will result in a shorter, straightforward patch.

Yeah. Implementing it on the network managers is the Right Thing To Do, but nova-manage doesn't generally seem to do the right thing...

Any movement on this bug? If no one is working on it, we should un-assign from RC1.

Reviewers's comments have been addressed. A new patch is up for review, and in need of some love: https://review.openstack.org/#/c/9754/

Thanks!

Is this bug still valid?
There is a blueprint (marked as essential) to depreciate nova-network in Havana:
https://blueprints.launchpad.net/nova/+spec/deprecate-nova-network

Fix proposed to branch: master
Review: https://review.openstack.org/87103

Reviewed: https://review.openstack.org/87103
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=a581823ecee286c5c6329c9c373f0fea0b6b729f
Submitter: Jenkins
Branch: master

commit a581823ecee286c5c6329c9c373f0fea0b6b729f
Author: Mohammed Naser <email address hidden>
Date: Sun Apr 13 01:58:21 2014 +0000

    Disable nova-manage network commands with Neutron V2

    When using nova-manage with neutron v2 API, all CRUD operations
    should be done directly against the neutron API, rather than
    using nova-manage.

    Change-Id: I663bd06eb50872f16fc9889dde917277739fefce
    Closes-Bug: #1019895

Fix proposed to branch: master
Review: https://review.openstack.org/88626