On 03/20/2015 03:02 PM, Carl Baldwin wrote:
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.
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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
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
