On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes <jaypi...@gmail.com> wrote:
>> 2) Is the action of creating a subnet from a pool better realized as a
>> different way of creating a subnet, or should there be some sort of
>> "pool action"? Eg.:
>>
>> POST /subnet_pools/my_pool_id/subnet
>> {'prefix_len': 24}
>>
>> which would return a subnet response like this (note prefix_len might
>> not be needed in this case)
>>
>> {'id': 'meh',
>> 'cidr': '192.168.0.0/24 <http://192.168.0.0/24>',
>> 'gateway_ip': '192.168.0.1',
>> 'pool_id': 'my_pool_id'}
>>
>> I am generally not a big fan of RESTful actions. But in this case the
>> semantics of the API operation are that of a subnet creation from within
>> a pool, so that might be ok.
>
>
> +1 to using resource subcollection semantics here.
The issue I see here is that there is a window of time between
requesting the subnet allocation and creating the subnet when the
subnet could be taken by someone else. We need to acknowledge the
window and address it somehow.
Does IPAM hold a reservation or something on the subnet to lock out
others? Or, does the client just retry on failure? If there are
multiple clients requesting subnet allocations, it seems that IPAM
should keep some state (e.g. a reservation) to avoid giving out the
same one more than once to difference clients at least.
I think that the first operation should result in full allocation of
the subnet to the tenant. In this case, I think that the allocation
should have an id and be a first class object (it is not currently).
The tenant will need to manage these allocations like anything else.
The tenant will also be required to delete unused allocations. This
might be the way to go long-term.
If allocations have an id. I think I'd have the client pass in the
allocation id instead of the pool id to the subnet create to
differentiate between asking for a new allocation and using an
existing allocation.
Carl
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
