Open Stack

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.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
>
> _______________________________________________
> 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/e72a2f55/attachment-0001.html>