Open Stack

On 03/20/2015 03:02 PM, Carl Baldwin wrote:
> On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes <jaypipes at 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.

I actually don't think the API URI structure should acknowledge if there 
is or is not a window of time that is involved in some action. Instead, 
whether or not the API call returns a 202 Accepted or a 201 Created 
should be sufficient for communicating that information to the API user.

> 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.

Any API that returns 202 Accepted must return information in the HTTP 
headers (Location: <URI>) about where the client can get an update on 
the status of the resource that should be created:

https://github.com/openstack/api-wg/blob/master/guidelines/http.rst#2xx-success-codes

Whether or not this mechanism returns a reservation resource link 
(something like /reservations/{res_id}), or a link to the resource 
itself (/subnets/{subnet_id}) is entirely implementation-dependent.

I personally prefer the latter, but could go either way.

> 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.

In this case, you are suggesting to make the REST API operation 
synchronous, and should use 201 Created.

There's no reason you couldn't support both the top-level and the 
subcollection resource method of creating the subnet, though.

For instance, these two API calls would essentially be the same:

POST /subnets
{
   'pool_id': 'some_pool',
   'network_id': 'some_network',
   'cidr': '192.168.0.0./24'
}

POST /subnetpools/some_pool/subnets

{
   'network_id': 'some_network',
   'cidr': '192.168.0.0./24'
}

And the above is totally fine, IMO.

Best,
-jay

> 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>