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.ro...@gmail.com
<mailto:mathieu.ro...@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.parta...@gmail.com <mailto:lari.parta...@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@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________ OpenStack-dev
mailing list OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




_______________________________________________ OpenStack-dev
mailing list OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to