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 <[email protected]> Reply-To: OpenStack List <[email protected]> Date: Friday, June 28, 2013 2:50 PM To: OpenStack List <[email protected]> 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 <[email protected]> wrote: > Got it!!! I knew it could be possible.. > > Thanks, > > Edgar > > From: Aaron Rosen <[email protected]> > Reply-To: OpenStack List <[email protected]> > Date: Friday, June 28, 2013 2:19 PM > > To: OpenStack List <[email protected]> > 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 <[email protected]> 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 <[email protected]> >> Reply-To: OpenStack List <[email protected]> >> Date: Friday, June 28, 2013 12:07 PM >> >> To: OpenStack List <[email protected]> >> 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 <[email protected]> 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 <[email protected]> >>> Reply-To: OpenStack List <[email protected]> >>> Date: Thursday, June 27, 2013 8:59 AM >>> >>> To: OpenStack List <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> >>>> Reply-To: OpenStack List <[email protected]> >>>> Date: Thursday, June 20, 2013 1:13 PM >>>> To: OpenStack List <[email protected]> >>>> 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 <[email protected]> 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 >>>>> [email protected] >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> _______________________________________________ OpenStack-dev mailing list >>>> [email protected]http://lists.openstack.org/cgi-bin/mailman >>>> /listinfo/openstack-dev >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>> _______________________________________________ OpenStack-dev mailing list >>> [email protected]http://lists.openstack.org/cgi-bin/mailman/ >>> listinfo/openstack-dev >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> _______________________________________________ OpenStack-dev mailing list >> [email protected]http://lists.openstack.org/cgi-bin/mailman/l >> istinfo/openstack-dev >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > _______________________________________________ OpenStack-dev mailing list > [email protected]http://lists.openstack.org/cgi-bin/mailman/li > stinfo/openstack-dev > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
