Open Stack

Hello everyone,

I am working on implementing fixed IP reservation for tenants. My goal is
to be able to reserve fixed IPs for a tenant and avoid as much as possible
the "ephemeral" state of an IP.

A basic workflow would be like this:

Tenant or admin reserves one or more fixed IPs. He will than be able to use
one or more of those reserved IPs on his instances (assign them to ports,
support multiple IPs per port).
If no/not enough fixed IPs are reserved, use the current IPAM
implementation otherwise allow the tenant to select from his reserved IPs
and then go through the current IPAM.

I am using fixed routable and non-routable IPs for public and private
networks (provider network , no NAT and no tagging). I will also use
floating IPs for LB, DNS a.s.o.

I have a few questions regarding the development of this since the
documentation is still being worked on and I have to dig through the code a
lot to understand a few things:

1. nova reserve-fixed-ip, this belongs to nova-network now obsolete right ?
2. I though of creating a new model (mainly a db table) to hold the IPs and
the tenant IDs in order to keep the association. I've done this for the
openvswitch plugin in ovs_models_v2 by adding a new model. I can probably
do this globally in /db directly right (especially if I plan on supporting
multiple plugins) ?
3. I was planning on adding to Neutron the api calls nova has for fixed IPs
(ex: fixed-ip-get, reserve, unreserve) Does this seem right ? I am asking
because I believe there is some work towards a new IPAM implementation and
I would like to get some thoughts. I am also asking because to me it seems
a little bit confusing that nova can also manage IPs and I am not sure
if/what functions are
obsolete there.
4. This should go as an extension first (as far as I understand for the
docs). Add the extension to extend the Neutron API and modify the current
IPAM right ?


-- 
Regards,
Cristian Tomoiaga
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130715/56fb0486/attachment.html>