Hi,
I am not entirely sure I've got this thread right - so I apologize in
advance for any non sense.
It seems it started with Gary asking whether we could restructure the
request format for POST /v2/ports, but then it seems the discussion is
now focused on how we should search for IPs.
I understand the two things are quite related, and from what I gather
the key point here is to understand how to treat IPs.
At the moment I have only a 100,000 feet view, but Jason's proposal
about ips as first class resources makes sense to me.
We already have networks and ports as first class resources, it seems
natural structuring subnets and ips in the same way.
However, I would probably use a slightly different syntax for associating IPs:
POST /v2.0/ips
{
"subnet_id": "<some_uuid>",
"port_id": "<some_other_uuid>",
"ip": "<{ipv4 | ipv6}>",
}
Where subnet_id would be the only mandatory parameter, apparently.
The Querystrings suggested by Jason would be great for searching for
IPs associated with a given subnet or port.
If for some reason we believe that instead ips should not be a first
level resource, then we should probably threat them as second-level
resources, as it was for ports in the API v1
So for instance, we could have operations like:
POST /v2.0/subnets/<subnet_uuid>/ips, with a list of (port, [ips])
pairs in the request body
This however becomes somewhat complex if you want to update ips
associated with a given port, as you'll probably need to it this way
PUT /v2.0/subnets/<subnet_uuid>/ips/<port-id>, which does not make a
lot of sense to me.
And, again, it would also be inconsistent with what networks and ports
are approached.
Some more comments inline.
Have a good day,
Salvatore
On 20 June 2012 21:09, Jason Kölker <jkoel...@rackspace.com> wrote:
>
> On Wed, 2012-06-20 at 12:02 -0700, Dan Wendlandt wrote:
> >
> > For example, if port was just:
> >
> >
> > { 'id' : XYZ,
> > 'network_id': "ABC"
> > 'fixed_ips': [ "10.0.0.2" ]
> > }
> >
> >
> > We could do a query that specified filter network_id=ABC, but it was
> > already a bit wonky to do something like fixed_ips=10.0.0.2 because
> > fixed_ip was really a list, not a string. Were you envisioning a
> > model where a filter on a list was implicitly converted to a ORed
> > comparison against each list item?
>
> I would compare it to the 'in' test in python. And I'm going to go back
> on my previous email and say it should be:
>
> GET /ports?fixed_ip=10.0.0.2
>
> To be explicit that you are searching for match of an element in the
> collection.
How does your example explicit that we are searching for a match of an
element in a collection?
This kind of reminds me of the problem we had in API v1 filters when
searching for ports in networks.
We just did: GET v1.1/networks?port=<port_uuid> which is probably not
quite right as I understand Dan's comment on fixed_ip not being really
a scalar but a list.
What if we prepended "has_" to query parameter looking for elements in
collections (or second-level resources)?
>
> > If thats the case, then the same trick could still be used, if we have
> > a way of referring to nested keys. One option would be to do
> > something like:
> >
> >
> > { 'id' : XYZ,
> > 'network_id': "ABC"
> > 'fixed_ips': [ { "address": "10.0.0.2", "subnet_id": "DEF"} ]
> > }
> >
> >
> > and allow filters like fixed_ips.address=10.0.0.2 . Essentially,
> > nested keys are joined by some delimiter, like ".".
>
> Right, we'd have to invent and document a "SQL over HTTP" system for
> filtering inside a collection of resources.
Is this a different kind of problem, like fixed_ip not only being a
list, but being a structured entity too?
>
>
> > Another option would be to just define a filter key that does not
> > directly map to a top-level attribute (e.g.
> > fixed_ip_address=10.0.0.2).
>
> We could, I'm +/-0 on just inventing our own query semantics just so we
> can get something working. My original goal was to have it as straight
> forward as possible for the API consumer. "I want to filter for a
> fixed_ip, so that's what I'd pass in". Not "I want to filter for
> fixed_ip, let me look up in the document what the semantics are for
> reaching into that collection of resources, ok in this case its
> fixed_ip_address".
>
Agreed. We should aim at having an API so simple the user does not
even have to read the docs to start using it.
> > On the plus side, I think the idea of passing in the subnet-id handles
> > the other issue you mentioned previously, in that it gives us a clean
> > way to add an IP to a port even if the user wants that IP to be
> > allocated from a pool, since the user can add an entry to the fixed
> > ips list, but only specify the subnet.
> >
> >
> > any other ideas on this front?
>
> POST /ips?subnet_id=<UUID>&port_id=<UUID>
>
> For allocate out of the pool and
>
> POST /ips?subnet_id<UUID>&port_id=<UUID>&address=10.0.0.3
>
> For a specific address. (swap out the query string for a body if it
> seems particularly nasty, but either should be supported in my opinion)
>
Why does this seem nasty to you?
> I see the query string as the selector to determine the parameters of
> the operation.
>
> Happy Hacking!
>
> 7-11
>
>
>
> --
> Mailing list: https://launchpad.net/~netstack
> Post to : netstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~netstack
> More help : https://help.launchpad.net/ListHelp
--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp
