openstack team mailing list archive

[Dan Wendlandt <dan@xxxxxxxxxx>]

On Fri, Apr 13, 2012 at 5:34 AM, Vaze, Mandar <Mandar.Vaze@xxxxxxxxxxx>wrote:

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

Yes, as documented Quantum Manager in Essex does not support multi-host.
 This is why the nova-manage limitation is workable, albiet somewhat
inconvenient.

In Folsom, we will support a model that provides the same HA benefits of
multi-host, though the implementation will be different, as the L3
forwarding + DHCP functions will be handled by Quantum, not by Nova.

Dan


> ****
>
> ** **
>
> ** **
>
> Thanks !!****
>
> -Mandar****
>
> ** **
>
> ** **
>
> *From:* Dan Wendlandt [mailto:dan@xxxxxxxxxx]
> *Sent:* Thursday, April 12, 2012 9:44 PM
> *To:* Vaze, Mandar
> *Cc:* openstack@xxxxxxxxxxxxxxxxxxx; netstack@xxxxxxxxxxxxxxxxxxx
> *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@xxxxxxxxxxx>
> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~netstack
> More help   : https://help.launchpad.net/ListHelp****
>
>
>
> ****
>
> ** **
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt ****
>
> Nicira, Inc: 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
>



-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~