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