[openstack-dev] [Neutron] reservation of fixed ip

Carl Baldwin carl at ecbaldwin.net
Fri May 23 15:45:27 UTC 2014


+1 to merge the allocation pool update patch [3].   I've reviewed the
code and I think that it is good.  I haven't run the current patch
myself yet but I can do that soon.

I was also thinking in the context of shared or external networks.
The use case that Salvatore described is exactly the use case that I
had in mind.  If that were implemented then I would want those IPs to
be removed from rotation by the allocator.  The tenant would need to
explicitly request the reserved IP in a port, floating IP, or router
gateway creation.  The proposed changes [1][2] only allow an admin to
request a specific IP but with a reservation, an exception would be
made for when the admin has delegated the IP to the tenant.

If we can agree on this behavior then I can work this in to the
pluggable IPAM design.  We may implement some of the more basic IPAM
first but we can certainly design around this use case so that it can
be implemented in a later stage.

Carl

[1] https://review.openstack.org/#/c/70286/
[2] https://review.openstack.org/#/c/83664/
[3] https://review.openstack.org/#/c/62042/

On Fri, May 23, 2014 at 9:19 AM, Salvatore Orlando <sorlando at nicira.com> wrote:
>
>
>
> On 23 May 2014 16:02, marios at redhat.com <mandreou at redhat.com> wrote:
>>
>> On 23/05/14 05:41, Mohammad Banikazemi wrote:
>> >
>> > Well, for a use case we had in mind we were trying to figure out how to
>> > simply get an IP address on a subnet. We essentially want to use such an
>> > address internally by the controller and make sure it is not used for a
>> > port that gets created on a network with that subnet. In this use case,
>> > an
>> > interface to IPAM for removing an address from the pool of available
>> > addresses (and the interface to possibly return the address to the pool)
>> > would be sufficient.
>>
>> this and Carl's earlier response were my initial thought; this could
>> just be implemented through manipulation of allocation pools to make
>> sure the given address isn't handed out. Then the user can just manually
>> assign that address to the resource during creation/some existing update
>> mechanism (once pending reviews land and any others that were missed).
>>
>
> I agree, but I had the impression that in the initial posts there was a
> request to be able to give tenants specific IPs also on shared or external
> networks.
> For instance if your external network is 172.24.4.0/24, an admin should be
> able to say things like:
> 172.24.4.9 belongs to tenant Higuain
> 172.24.4.7 belongs to tenant Callejon
> 172.24.4.17 belong to tenant Hamsik
> and all the other address are then free to be used by any tenant including
> the ones listed above.
>
>> Slightly related in that it updates subnet allocation pools, I have a
>> review at [1] which adds PUT /subnets/subnet "allocation_pools: {}"
>
>
> It's perhaps time we look at the patch and merge it. PUT on allocation pools
> have been a #TODO for about 2 years now!
>
>>
>>
>> thanks! marios
>>
>> [1] https://review.openstack.org/#/c/62042/
>>
>> >
>> > Mohammad
>> >
>> >
>> >
>> > From: Carl Baldwin <carl at ecbaldwin.net>
>> > To:   "OpenStack Development Mailing List (not for usage questions)"
>> >             <openstack-dev at lists.openstack.org>,
>> > Date: 05/22/2014 06:19 PM
>> > Subject:      Re: [openstack-dev] [Neutron] reservation of fixed ip
>> >
>> >
>> >
>> > If an IP is reserved for a tenant, should the tenant need to
>> > explicitly ask for that specific IP to be allocated when creating a
>> > floating ip or port?  And it would pull from the regular pool if a
>> > specific IP is not requested.  Or, does the allocator just pull from
>> > the tenant's reserved pool whenever it needs an IP on a subnet?  If
>> > the latter, then I think Salvatore's concern still a valid one.
>> >
>> > I think if a tenant wants an IP address reserved then he probably has
>> > a specific purpose for that IP address in mind.  That leads me to
>> > think that he should be required to pass the specific address when
>> > creating the associated object in order to make use of it.  We can't
>> > do that yet with all types of allocations but there are reviews in
>> > progress [1][2].
>> >
>> > Carl
>> >
>> > [1] https://review.openstack.org/#/c/70286/
>> > [2] https://review.openstack.org/#/c/83664/
>> >
>> > On Thu, May 22, 2014 at 12:04 PM, Sławek Kapłoński <slawek at kaplonski.pl>
>> > wrote:
>> >> Hello
>> >>
>> >>
>> >> Dnia Wed, 21 May 2014 23:51:48 +0100
>> >> Salvatore Orlando <sorlando at nicira.com> napisał:
>> >>
>> >>> In principle there is nothing that should prevent us from
>> >>> implementing an IP reservation mechanism.
>> >>>
>> >>> As with anything, the first thing to check is literature or "related
>> >>> work"! If any other IaaS system is implementing such a mechanism, is
>> >>> it exposed through the API somehow?
>> >>> Also this feature is likely to be provided by IPAM systems. If yes,
>> >>> what constructs do they use?
>> >>> I do not have the answers to this questions, but I'll try to document
>> >>> myself; if you have them - please post them here.
>> >>>
>> >>> This new feature would probably be baked into neutron's IPAM logic.
>> >>> When allocating an IP, first check from within the IP reservation
>> >>> pool, and then if it's not found check from standard allocation pools
>> >>> (this has non negligible impact on availability ranges management, but
>> >>> these are implementation details).
>> >>> Aspects to consider, requirement-wise, are:
>> >>> 1) Should reservations also be classified by "qualification" of the
>> >>> port? For instance, is it important to specify that an IP should be
>> >>> used for the gateway port rather than for a floating IP port?
>> >>
>> >> IMHO it is not required when IP is reserved. User should have
>> >> possibility to reserve such IP for his tenant and later use it as he
>> >> want (floating ip, instance or whatever)
>> >>
>> >>> 2) Are reservations something that an admin could specify on a
>> >>> tenant-basis (hence an admin API extension), or an implicit mechanism
>> >>> that can be tuned using configuration variables (for instance create
>> >>> an IP reservation a for gateway port for a given tenant when a router
>> >>> gateway is set).
>> >>>
>> >>> I apologise if these questions are dumb. I'm just trying to frame this
>> >>> discussion into something which could then possibly lead to
>> >>> submitting a specification.
>> >>>
>> >>> Salvatore
>> >>>
>> >>>
>> >>> On 21 May 2014 21:37, Collins, Sean <Sean_Collins2 at cable.comcast.com>
>> >>> wrote:
>> >>>
>> >>>> (Edited the subject since a lot of people filter based on the
>> >>>> subject line)
>> >>>>
>> >>>> I would also be interested in reserved IPs - since we do not deploy
>> >>>> the layer 3 agent and use the provider networking extension and a
>> >>>> hardware router.
>> >>>>
>> >>>> On Wed, May 21, 2014 at 03:46:53PM EDT, Sławek Kapłoński wrote:
>> >>>>> Hello,
>> >>>>>
>> >>>>> Ok, I found that now there is probably no such feature to reserve
>> >>>>> fixed ip for tenant. So I was thinking about add such feature to
>> >>>>> neutron. I mean that it should have new table with reserved ips
>> >>>>> in neutron database and neutron will check this table every time
>> >>>>> when new port will be created (or updated) and IP should be
>> >>>>> associated with this port. If user has got reserved IP it should
>> >>>>> be then used for new port, if IP is reserver by other tenant - it
>> >>>>> shouldn't be used. What You are thinking about such possibility?
>> >>>>> Is it possible to add it in some future release of neutron?
>> >>>>>
>> >>>>> --
>> >>>>> Best regards
>> >>>>> Sławek Kapłoński
>> >>>>> slawek at kaplonski.pl
>> >>>>>
>> >>>>>
>> >>>>> Dnia Mon, 19 May 2014 20:07:43 +0200
>> >>>>> Sławek Kapłoński <slawek at kaplonski.pl> napisał:
>> >>>>>
>> >>>>>> Hello,
>> >>>>>>
>> >>>>>> I'm using openstack with neutron and ML2 plugin. Is there any
>> >>>>>> way to reserve fixed IP from shared external network for one
>> >>>>>> tenant? I know that there is possibility to create port with IP
>> >>>>>> and later connect VM to this port. This solution is almost ok
>> >>>>>> for me but problem is when user delete this instance - then
>> >>>>>> port is also deleted and it is not reserved still for the same
>> >>>>>> user and tenant. So maybe there is any solution to reserve it
>> >>>>>> "permanent"? I know also about floating IPs but I don't use L3
>> >>>>>> agents so this is probably not for me :)
>> >>>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> OpenStack-dev mailing list
>> >>>>> OpenStack-dev at lists.openstack.org
>> >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>>
>> >>>> --
>> >>>> Sean M. Collins
>> >>>> _______________________________________________
>> >>>> OpenStack-dev mailing list
>> >>>> OpenStack-dev at lists.openstack.org
>> >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >>>>
>> >>
>> >> --
>> >> Best regards
>> >> Sławek Kapłoński
>> >> slawek at kaplonski.pl
>> >>
>> >> _______________________________________________
>> >> 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
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



More information about the OpenStack-dev mailing list