Open Stack

Hi Assaf, Kevin, I know we talked about this on IRC, but just want to close
this question on the thread, for rest of the community.

Yes, Assaf is correct.

Either via DHCP or Config Drive, we will make sure that different
VMs/baremetal nodes get different gateway addresses.




On Fri, Jun 12, 2015 at 2:34 PM, Assaf Muller <amuller at redhat.com> wrote:

> I think Shraddha was talking about the gateway IP the DHCP server will
> respond
> with. Different VMs will get different gateways.
>
> ----- Original Message -----
> > That logic is contained in the virtual machine. We have no control over
> that.
> >
> > On Thu, Jun 11, 2015 at 3:34 PM, Shraddha Pandhe <
> > spandhe.openstack at gmail.com > wrote:
> >
> >
> >
> > The idea is to round-robin between gateways by using some sort of mod
> > operation
> >
> > So logically it can look something like:
> >
> > idx = len(gateways) % ip
> > gateway = gateways[idx]
> >
> >
> > This is just one idea. I am open to more ideas.
> >
> >
> >
> >
> > On Thu, Jun 11, 2015 at 3:10 PM, Kevin Benton < blak111 at gmail.com >
> wrote:
> >
> >
> >
> >
> > What gateway address do you give to regular clients via dhcp when you
> have
> > multiple?
> >
> >
> > On Jun 11, 2015 12:29 PM, "Shraddha Pandhe" <
> spandhe.openstack at gmail.com >
> > wrote:
> > >
> > > Hi,
> > > Currently, the Subnets in Neutron and Nova-Network only support one
> > > gateway. For provider networks in large data centers, quite often, the
> > > architecture is such a way that multiple gateways are configured per
> > > subnet. These multiple gateways are typically spread across backplanes
> so
> > > that the production traffic can be load-balanced between backplanes.
> > > This is just my use case for supporting multiple gateways, but other
> folks
> > > might have more use cases as well and also want to take the community's
> > > opinion about this feature. Is this something that's going to help a
> lot
> > > of users?
> > > I want to open up a discussion on this topic and figure out the best
> way to
> > > handle this.
> > > 1. Should this be done in a same way as dns-nameserver, with a separate
> > > table with two columns: gateway_ip, subnet_id.
> > > 2. Should Gateway field be converted to a List instead of String?
> > > I have also opened a bug for Neutron here:
> > > https://bugs.launchpad.net/neutron/+bug/1464361
> > >
> > >
> > >
> __________________________________________________________________________
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > Kevin Benton
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150615/fb6b4a34/attachment.html>