Dan,
On similar lines - Currently if nova-network processes are running on two nodes, only way to set specific network on specific nova-network node is to execute "nova-manage network create" on respective nova-network node. Is that correct ?
How is the above setup related to "multi-host" ? I found a code comment that "Quantum Manager doesn't support multi-host"
I'm copying Vish, as he seems to be expert on multi-host - Reading http://docs.openstack.org/trunk/openstack-compute/admin/content/existing-ha-networking-options.html , it looks like above is Option 2/Multi-Nic, but not really sure) If yes, how is multi-nic supported by Quantum ?
Additionally - in the above document Vish suggested that each nova-compute must run nova-network - Is that why with QuantumManager - nova-manage executes networking commands like iptables, dnsmasq locally ?
Thanks !!
-Mandar
From: Dan Wendlandt [mailto:dan@nicira.com]
Sent: Thursday, April 12, 2012 9:44 PM
To: Vaze, Mandar
Cc: openstack@lists.launchpad.net; netstack@lists.launchpad.net
Subject: Re: [Netstack] Role of "nova-manage network" commands when using QuantumManager
Hi Mandar,
Thanks for bringing this up. For Essex, nova-manage commands to create/delete Quantum networks must be run on the nova-network node. For Folsom this will all change, as all networks will be created directly against the Quantum API, rather than using nova-manage. I'll add a note to the administrator guide, as this is not called there. Thanks!
Dan
On Thu, Apr 12, 2012 at 1:38 AM, Vaze, Mandar <Mandar.Vaze@nttdata.com<mailto:Mandar.Vaze@nttdata.com>> wrote:
It is my understanding that in multi-node setup :
* nova-manage can be executed from any machine which may not be running nova-network process. (Or should nova-manage always be run on nova-network node ?)
* nova-manage does DB operations and delegates the actual networking calls to nova-network process ?
Is this understanding correct ?
I traced "nova-manage network create" and nova-manage network delete" using FlatDHCPManager (default for devstack/stack.sh)
Both these calls seem to be doing only DB operations.
BTW, nova-network process was shutdown during both "network create" and "network delete" - Still both operations were successful.
But when using QuantumManager as network manager - nova-manage seems to be doing networking operations like "iptables-save" (during network create) and "kill_dhcp" (during network delete)
(via linux-net L3 driver)
Since nova-manage command may be executed on a host which isn't running nova-network - network commands like "iptables" and "kill -9 <pid of dnsmasq>" on host running nova-manage seems incorrect.
For the first scenario (iptables-save during "network create" - there is already a defect in LP : https://bugs.launchpad.net/nova/+bug/977738
and review : https://review.openstack.org/6451
I would like your comments and opinions which would help me understand "What nova-manage should and should NOT do"
Thanks,
-Mandar
______________________________________________________________________
Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding
--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com<http://www.nicira.com>
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
______________________________________________________________________
Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding
On similar lines - Currently if nova-network processes are running on two nodes, only way to set specific network on specific nova-network node is to execute "nova-manage network create" on respective nova-network node. Is that correct ?
How is the above setup related to "multi-host" ? I found a code comment that "Quantum Manager doesn't support multi-host"
I'm copying Vish, as he seems to be expert on multi-host - Reading http://docs.openstack.org/trunk/openstack-compute/admin/content/existing-ha-networking-options.html , it looks like above is Option 2/Multi-Nic, but not really sure) If yes, how is multi-nic supported by Quantum ?
Additionally - in the above document Vish suggested that each nova-compute must run nova-network - Is that why with QuantumManager - nova-manage executes networking commands like iptables, dnsmasq locally ?
Thanks !!
-Mandar
From: Dan Wendlandt [mailto:dan@nicira.com]
Sent: Thursday, April 12, 2012 9:44 PM
To: Vaze, Mandar
Cc: openstack@lists.launchpad.net; netstack@lists.launchpad.net
Subject: Re: [Netstack] Role of "nova-manage network" commands when using QuantumManager
Hi Mandar,
Thanks for bringing this up. For Essex, nova-manage commands to create/delete Quantum networks must be run on the nova-network node. For Folsom this will all change, as all networks will be created directly against the Quantum API, rather than using nova-manage. I'll add a note to the administrator guide, as this is not called there. Thanks!
Dan
On Thu, Apr 12, 2012 at 1:38 AM, Vaze, Mandar <Mandar.Vaze@nttdata.com<mailto:Mandar.Vaze@nttdata.com>> wrote:
It is my understanding that in multi-node setup :
* nova-manage can be executed from any machine which may not be running nova-network process. (Or should nova-manage always be run on nova-network node ?)
* nova-manage does DB operations and delegates the actual networking calls to nova-network process ?
Is this understanding correct ?
I traced "nova-manage network create" and nova-manage network delete" using FlatDHCPManager (default for devstack/stack.sh)
Both these calls seem to be doing only DB operations.
BTW, nova-network process was shutdown during both "network create" and "network delete" - Still both operations were successful.
But when using QuantumManager as network manager - nova-manage seems to be doing networking operations like "iptables-save" (during network create) and "kill_dhcp" (during network delete)
(via linux-net L3 driver)
Since nova-manage command may be executed on a host which isn't running nova-network - network commands like "iptables" and "kill -9 <pid of dnsmasq>" on host running nova-manage seems incorrect.
For the first scenario (iptables-save during "network create" - there is already a defect in LP : https://bugs.launchpad.net/nova/+bug/977738
and review : https://review.openstack.org/6451
I would like your comments and opinions which would help me understand "What nova-manage should and should NOT do"
Thanks,
-Mandar
______________________________________________________________________
Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding
--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net<mailto:netstack@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com<http://www.nicira.com>
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
______________________________________________________________________
Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding