Open Stack

On Fri, Mar 20, 2015 at 1:48 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> 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.

I actually wasn't even thinking of it in these terms.  By
acknowledged, I meant that the implementation must acknowledge the gap
and ensure that problems don't arise because of it.  But, your point
is good too.

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

Yes, I think so.

> 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'
> }

Ok, I see.  I'll keep that in mind.  The first one makes sense.  I'm
not sure that creating a subnet from the pools resource makes sense to
me though.  Let me think on it.

Carl