On Fri, Mar 20, 2015 at 1:48 PM, Jay Pipes <jaypi...@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 __________________________________________________________________________ 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
