On 06/21/2012 12:27 PM, Salvatore Orlando wrote:
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.

Yes, that is correct.
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}>",
}

This entails that a port will have had to be created prior. I like the fact that with the port creation one or more ip's can be allocated or configured.

I think that having an additional step for IP configuration could be cumbersome for the user. Is there any option of say adding the table that you have suggested for read only purposes?

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

Reply via email to