Open Stack

Actually, the implementation for that method in our case will just simple
return an empty value (if that is possible) because I can't tale which IP
address the DHCP will assign.
I could tell the DHCP server which IP assign to the specific MAC but I could
not have that kind of functionality.
After the booting process, I could have a post configuration process being
trigger to get the IP address from the DHCP but not sure about that
approach..

Anyway, Armando point is very interesting.
I think some BPs on IP allocation already cover alternative solutions.

Edgar

From:  Armando Migliaccio <amigliaccio at nicira.com>
Reply-To:  OpenStack List <openstack-dev at lists.openstack.org>
Date:  Friday, June 28, 2013 2:50 PM
To:  OpenStack List <openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [Networking] Allocation of IPs

I guess the other question is: is this the right approach?

I think your use case may be beneficial to other plugins, so in my view
having a plugin-specific override is not the best fit.

On Fri, Jun 28, 2013 at 2:42 PM, Edgar Magana <emagana at plumgrid.com> wrote:
> Got it!!!  I knew it could be possible..
> 
> Thanks,
> 
> Edgar
> 
> From:  Aaron Rosen <arosen at nicira.com>
> Reply-To:  OpenStack List <openstack-dev at lists.openstack.org>
> Date:  Friday, June 28, 2013 2:19 PM
> 
> To:  OpenStack List <openstack-dev at lists.openstack.org>
> Subject:  Re: [openstack-dev] [Networking] Allocation of IPs
> 
> Gotcha, The part that was confusing was:
> 
>> >Could it be possible to add a flag to disable the allocation for the IP?
>> >If the "no allocation" flag is enabled, all ports will have an empty value
>> for IPs.
> 
> So what you are looking to do is to provide the IP address from the plugin and
> not the db_base class it seems?  In this case all you need to do is implement:
> 
> _allocate_ips_for_port() in your plugin and then that method will be called
> instead of the base class one.
> 
> Aaron
> 
> 
> 
> On Fri, Jun 28, 2013 at 12:48 PM, Edgar Magana <emagana at plumgrid.com> wrote:
>> Aaron,
>> 
>> You are totally right, the point is that I don't want to loose the IPAM info
>> in Neutron because that is the moment when the backend plugin deploys a new
>> DHCP server into the Virtual Networking Infrastruture. So, every time that a
>> user creates a subnet and enables DHCP our plugin deploys a new DHCP service.
>> 
>> I am sure that is me the one missing something!!!   :-)
>> 
>> Thanks,
>> 
>> Edgar
>> 
>> From:  Aaron Rosen <arosen at nicira.com>
>> Reply-To:  OpenStack List <openstack-dev at lists.openstack.org>
>> Date:  Friday, June 28, 2013 12:07 PM
>> 
>> To:  OpenStack List <openstack-dev at lists.openstack.org>
>> Subject:  Re: [openstack-dev] [Networking] Allocation of IPs
>> 
>> Hi Edgar, 
>> 
>> I'm still not following. In your original question you asked how to you
>> create a port and not allocate an ip address to it at all so that you can
>> leverage a real dhcp server to do that. In order to do that you can create a
>> network without a subnet but then you loose the ipam info in quantum. Or
>> write a script that notifies your dhcp server the mac-ip bindings each
>> instance should have.  Am i missing something here?
>> 
>> Thanks,
>> 
>> Aaron
>> 
>> 
>> On Thu, Jun 27, 2013 at 11:00 PM, Edgar Magana <emagana at plumgrid.com> wrote:
>>> Aaron,
>>> 
>>> Because the create create_subnet API is the one that enables/disables the
>>> DHCP:
>>> quantum subnet-create <network>  <CIDR> --enable_dhcp False
>>> 
>>> 
>>> 
>>> Besides, the CIDR is actually the information that is sent to the DHCP to
>>> locate IP Addresses.
>>> 
>>> 
>>> 
>>> Thanks,
>>> 
>>> 
>>> 
>>> Edgar
>>> 
>>> 
>>> From:  Aaron Rosen <arosen at nicira.com>
>>> Reply-To:  OpenStack List <openstack-dev at lists.openstack.org>
>>> Date:  Thursday, June 27, 2013 8:59 AM
>>> 
>>> To:  OpenStack List <openstack-dev at lists.openstack.org>
>>> Subject:  Re: [openstack-dev] [Networking] Allocation of IPs
>>> 
>>> Hi Edgar, 
>>> 
>>> In this case if you don't associate a subnet with a network you should
>>> achieve that. Why doesn't that work?
>>> 
>>> Thanks, 
>>> 
>>> Aaron
>>> 
>>> 
>>> 
>>> 
>>> On Thu, Jun 20, 2013 at 1:51 PM, Edgar Magana <emagana at plumgrid.com> wrote:
>>>> Could it be possible to add a flag to disable the allocation for the IP?
>>>> If the "no allocation" flag is enabled, all ports will have an empty value
>>>> for IPs.
>>>>  It will increase the config parameters in quantum, should we try it?
>>>> 
>>>> Edgar
>>>> 
>>>> From:  Mark McClain <mark.mcclain at dreamhost.com>
>>>> Reply-To:  OpenStack List <openstack-dev at lists.openstack.org>
>>>> Date:  Thursday, June 20, 2013 1:13 PM
>>>> To:  OpenStack List <openstack-dev at lists.openstack.org>
>>>> Subject:  Re: [openstack-dev] [Networking] Allocation of IPs
>>>> 
>>>> There's work under way to make IP allocation pluggable. One of the options
>>>> will include not having an allocator for a subnet.
>>>> 
>>>> mark
>>>> 
>>>> On Jun 20, 2013, at 2:36 PM, Edgar Magana <emagana at plumgrid.com> wrote:
>>>> 
>>>>> Developers,
>>>>> 
>>>>> So far in Networking (formerly Quantum) IPs are pre-allocated when a new
>>>>> port is created by the following def:
>>>>> _allocate_ips_for_port(self, context, network, port):
>>>>> 
>>>>> If we are using a real DHCP (not the dnsmasq process) that does not accept
>>>>> static IP allocation because it only allocates IPs based on its own
>>>>> algorithm, how can we tell Networking to not allocate an IP at all?
>>>>> I don¹t think that is possible based on the code but I would like to know
>>>>> if somebody has gone through the same problem and have a workaround
>>>>> solution.
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Edgar
>>>>> 
>>>>> _______________________________________________
>>>>> 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.orghttp://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.orghttp://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.orghttp://lists.openstack.org/cgi-bin/mailman/l
>> istinfo/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.orghttp://lists.openstack.org/cgi-bin/mailman/li
> stinfo/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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130628/9c2fab8f/attachment.html>