Open Stack

Looks like it falls into two parts: Fuel & Neutron requirements.

Use case, as far as I understand, is following: user doesn't have one large
range of publicly routable IP addresses for environment, and has multiple
L3 ranges instead.

So for Fuel it means:

   1. We should not waste public IPs for compute nodes nodes if we don't
   need them there (Neutron doesn't need it, only required for nova-network in
   multi-host mode). I think it should be covered by
   https://blueprints.launchpad.net/fuel/+spec/advanced-networking
   2. If we use public network then only for OpenStack REST API services,
   we should be fine with one single IP range, do we?
   3. Floating network, which is external in Neutron terms, can be large
   waste of IPs for VMs. So it's impossible that in large clusters there is
   gonna be single L3 which would cover it. That means, Fuel should allow to
   have multiple L3 external networks per OpenStack environment, in theory
   they can be even in different L2.

I had a short discussion with Maru & Mark in IRC, it looks like we need in
Neutron:

   1. It should be possible to have multiple L3 subnets for external network
   2. It is unlikely that we will need to have more than one subnet serving
   by single Neutron server, but we might in theory..

Alexander, please take a look if I treated your initial blueprint in a
right way.

Thanks,


On Tue, Apr 8, 2014 at 7:53 PM, Salvatore Orlando <sorlando at nicira.com>wrote:

> Hi Mike,
>
> For all neutron-related fuel developments please feel free to reach to to
> the neutron team for any help you might need either by using the ML or
> pinging people in #openstack-neutron.
> Regarding the fuel blueprints you linked in your first post, I am looking
> in particular at
> https://blueprints.launchpad.net/fuel/+spec/separate-public-floating
>
> I am not entirely sure of what are the semantics of 'public' and
> 'floating' here, but I was wondering if this would be achievable at all
> with the current neutron API, since within a subnet CIDR there's no
> 'qualitative' distinction of allocations pools; so it would not be possible
> to have a 'public' IP pool and a 'floating' IP pool in the same L3 segment.
>
> Also, regarding nova gaps, it might be worth noting that Mark McClain
> (markmcclain) and Brent Eagles (beagles) are keeping track of current
> feature/testing/quality gaps and also covering progress for the relevant
> work items.
>
> Regards,
> Salvatore
>
>
> On 8 April 2014 14:46, Mike Scherbakov <mscherbakov at mirantis.com> wrote:
>
>> Great, thanks Assaf.
>>
>> I will keep following it. I've added a link to this bp on this page:
>> https://wiki.openstack.org/wiki/NovaNeutronGapHighlights#Multi-Host,
>> might help people to get the status.
>>
>>
>> On Mon, Apr 7, 2014 at 11:37 AM, Assaf Muller <amuller at redhat.com> wrote:
>>
>>>
>>>
>>> ----- Original Message -----
>>> > Hi all,
>>> > we had a number of discussions last week in Moscow, with participation
>>> of
>>> > guys from Russia, Ukraine and Poland.
>>> > That was a great time!! Thanks everyone who participated.
>>> >
>>> > Special thanks to Przemek for great preparations, including the
>>> following:
>>> >
>>> https://docs.google.com/a/mirantis.com/presentation/d/115vCujjWoQ0cLKgVclV59_y1sLDhn2zwjxEDmLYsTzI/edit#slide=id.p
>>> >
>>> > I've searched over blueprints which require update after meetings:
>>> > https://blueprints.launchpad.net/fuel/+spec/multiple-cluster-networks
>>> > https://blueprints.launchpad.net/fuel/+spec/fuel-multiple-l3-agents
>>> > https://blueprints.launchpad.net/fuel/+spec/fuel-storage-networks
>>> > https://blueprints.launchpad.net/fuel/+spec/separate-public-floating
>>> > https://blueprints.launchpad.net/fuel/+spec/advanced-networking
>>> >
>>> > We will need to create one for UI.
>>> >
>>> > Neutron blueprints which are in the interest of large and thus complex
>>> > deployments, with the requirements of scalability and high
>>> availability:
>>> > https://blueprints.launchpad.net/neutron/+spec/l3-high-availability
>>> > https://blueprints.launchpad.net/neutron/+spec/quantum-multihost
>>> >
>>> > The last one was rejected... there is might be another way of
>>> achieving same
>>> > use cases? Use case, I think, was explained in great details here:
>>> > https://wiki.openstack.org/wiki/NovaNeutronGapHighlights
>>> > Any thoughts on this?
>>> >
>>>
>>> https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
>>> This is the up the date blueprint, called "Distributed virtual
>>> router", or DVR. It's in early implementation reviews and is
>>> targeted for the Juno release.
>>>
>>> > Thanks,
>>> > --
>>> > Mike Scherbakov
>>> > #mihgen
>>> >
>>> > _______________________________________________
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev at lists.openstack.org
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>>
>> --
>> Mike Scherbakov
>> #mihgen
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Mike Scherbakov
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140409/0cb396c3/attachment.html>