Open Stack

On 11/18/2013 05:32 AM, Salvatore Orlando wrote:
> Oh no, not another *aas!
>
> Seriously, I don't think IP address management should be a service
> of its own independent from Neutron and/or nova-network. Neutron
> currently has an IPAM logic which is entirely coded in
> db_base_plugin_v2.py, and is more or less loosely coupled with the
> DHCP agent. We already have in place blueprints for allowing
> different IPAM drivers, which might or might not be part of the
> neutron code base, and which might or might not leverage the DHCP
> agent. There has been slow progress on these blueprints, and it
> would be awesome if somebody could jump in and help us deliver them.
>
> In my opinion, I don't think this calls for a new service plugin,
> IPAM is and should always be part of the 'core' Neutron API.

++

> It should be possible to abstract an interface for
> allocation/dellocating IP addresses for ports, and then have
> 'drivers' implementing this interface, with the current IPAM logic
> becoming the default drivers to be executed in gate jobs.

Yes, true. However, I will point out that IPAM isn't rocket science... 
it's not like there's more to it than just checking some existing data 
store to reserve/free some IP address for a particular thing. I'm not 
sure that there are going to be a whole lot of "drivers" for that other 
than swapping out the backend data store. Perhaps tying in to some 
pre-existing IPAM solution, I suppose...but those are typically 
custom/proprietary and not going to find their way into the upstream 
codebase.

> As different IPAM drivers might have totally different DB schemas,
> the final design should also provide a solution for addressing
> database migrations, and, if possible, data model conversion when
> switching from one driver to another (though I am not sure if this
> should be a requirement)

I believe the drivers (IPAM or otherwise) should only need to provide a 
schema migration path/utility for themselves. I do not think that 
drivers should need to be able to migrate to any and all other drivers; 
it just gets way to messy and how often is this really going to happen?

> Another interesting, and perhaps orthogonal aspect is whether we
> want to expose IP addresses as a first-level resource in the Neutron
> API, but this is probably the subject for another thread.

Yes, another thread :)

Best,
-jay

> Regards, Salvatore
>
>
>
> On 18 November 2013 10:08, Mathieu Rohon <mathieu.rohon at gmail.com
> <mailto:mathieu.rohon at gmail.com>> wrote:
>
> Hi,
>
> As I understood Juniper/contrail developers have also troubles with
> IPAM. The Hooks you are talking about in Nova, is handled with
> service plugin in Neutron. May be there is a place to implement an
> IPAMaaS service, or DHCPaaS?
>
>
>
> On Thu, Nov 14, 2013 at 6:32 AM, Lari Partanen
> <lari.partanen at gmail.com <mailto:lari.partanen at gmail.com>> wrote:
>> Thanks! So _generate_ip @ neutron.db.db_base_plugin_v2.py
> <http://neutron.db.db_base_plugin_v2.py> is one of the
>> methods I need to modify. Is there something like this
>> http://docs.openstack.org/developer/nova/devref/hooks.html in
> Neutron for
>> extending its methods or do I need to make a patch if I wish to
>> distribute my changes?
>>
>> Regards, Lari
>>
>> Hi,
>>
>> You can take a look at the patches in this blueprint:
>>
> https://blueprints.launchpad.net/neutron/+spec/configurable-ip-allocation
>
>
>
>
>> There was also a bp created earlier to talk to an external IPAM:
>> https://blueprints.launchpad.net/neutron/+spec/neutron-ipam
>>
>> Thanks, ~Sumit.
>>
>>
>> On Wed, Nov 13, 2013 at 7:22 PM, Lari Partanen <lari.partanen at
>> gmail.com <http://gmail.com>>wrote:
>>
>>> Hi,
>>>
>>> our company is using an IPAM solution that we would like to
> integrate with
>>> OpenStack. The idea would be that when instances request IP
> addresses they
>>> would get a free IP address from our IPAM which would be then
> allocated to
>>> them and when instances are deleted the IP addresses are
> released from the
>>> IPAM.
>>>
>>> I've gone through the source code but I'm having hard time
> figuring out
>>> how should I proceed with the integration. I would be grateful on
>>> information about what methods I should be looking for in the
> source code
>>> and how to extend them properly.
>>>
>>> Thanks! _______________________________________________
>>> OpenStack-dev mailing list OpenStack-dev at lists.openstack.org
>>> <http://lists.openstack.org>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>>>
>>>
>>
>>
>>
>>
>> _______________________________________________ OpenStack-dev
>> mailing list OpenStack-dev at lists.openstack.org
> <mailto: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
> <mailto: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
>