Mark, Ian, than you for your answers.

> Have you considered altering the allocation range of a subnet?  You can still 
> create ports with IPs that are within the subnet, but> outside of the 
> allocation range.  You can then control which instances get the "reserved" 
> IPs from the block that is outside of the> allocation range.  If this does 
> not work, I'd hold off making changes to the IPAM setup as this will be 
> changing in early H3.

> mark


I went ahead and implemented an extension for Neutron to satisfy my needs.
Mark, I see you are currently working on a new IPAM implementation, that
should work with my extension. Mainly I just need an IP from IPAM when I
request one.

I need to track the IP address usage, not sure if this is done anywhere. I
need this to be able to reduce the ability of a tenant to switch IPs at
will. (eg: spammer switches IPs). Tracking will allow for IP allocation
from the already used (by the same tenant) IPs. This will prevent a tenant
from getting a random IP each time he requests one and will "lock" him to
the same IPs he is or was using.
I need to allow a tenant to allocate a public IP directly to a port on a
VM. Much of the functionality is similar with floating IPs. Tenant sees a
list of reserved IPs, he can than allocate one or more of those IPs to a VM
(a port on that VM). Also no NATing.

> It's already possible to port-create with an IP address-and-subnet
> specified, which seems like an effective way of allocating an address
> and setting it aside for later.  Doesn't this satisfy your needs?

> --
> Ian.

Ian,
indeed, I'm able to allocate a specific IP. Currently I go through my
extension to check for old IPs used by a tenant. If I find one, I will use
the functionality you mentioned. If not, I go through the default IPAM to
request an IP and through my extension to "reserve" IT for the tenant.


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

Reply via email to