On 06/22/2012 03:35 AM, Salvatore Orlando wrote:
Joining Dan in the late-night fun of doing emails :)
Replies inline.
Salvatore
On 21 June 2012 23:59, Dan Wendlandt<d...@nicira.com> wrote:
On Thu, Jun 21, 2012 at 5:34 PM, Jason Kölker<jkoel...@rackspace.com>
wrote:
On Thu, 2012-06-21 at 14:56 +0300, Gary Kotton wrote:
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?
I agree I'd like to avoid an extra HTTP call to allocate IP's
(specifically for nova vm creation). I would expect that a plugin would
allocate an ip to a port if there is a subnet associated with the
network the port is on. Adding additional ips past that 1st auto
allocated would require a post to /ips. But the method of operation is
really up to plugin vendors.
Hi folks,
Sorry, I was chairing a session at the conference today, so I've been mostly
offline. Long email below trying to catch up :)
I think I agree with a lot of points in the threads.
I definitely agree with Jason's comment that:
"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".
Stated another way, if someone understands the JSON definition of an object
(e.g., a port), we want them to easily be able to figure out what how to
query using simple "rules". The simple rule we started with was that any
top-level primitive value can be used as a filter with the key being the
attribute name, and the value being the attribute value (e.g., GET
/ports?admin_status_up=True ).
The idea of filtering on non-primitives (lists and dicts) is trickier, and
requires the API user to learn more special semantics. Jason's "in"-like
semantics are one approach, but I think even there are are tricky cases
(presumably this just for lists of primitives, but not lists of compound
objects? Does the "in" filtering also work for testing if a 'key' exists in
a dict as it does in python, or just for lists?).
I like the "in-" like approach. I actually did not get it from Jason
email as I did not realized the subtles difference between "fixed_ips"
and "fixed_ip" (sorry I'm not a native english speaker) but ended up
proposing something similar (has_fixed_ip).
For compounds, I see options:
1) choose a "default" attribute of the compound attribute, and allow
to use that field only (or peraphs just the uuid) in filters. For ips,
this will clearly be the ip address
2) Use the following syntax:
/v2.0/ports?has_fixed_ip={ ip:10.0.0.1, subnet: AAA }
Which I've seen used in some REST APIs, mongoDB I believe
3) Do both things by allowing syntax proposed in 2 and also having a
default attribute for filters, which if not specified is the uuid.
At the moment the port returns a list of allocated ips in fixed_ips.
What if it returns the ip's and their subnet id's. That is, a list of
dictionaries: [{subnet_id: id, ip_address: ip}...].
This will aid us in the updates of IP's on the ports and may also
resolve the search issue discussed above (unless I am missing something).
The nested "." syntax is
another example of special semantics.
The dotted syntax is quite similar to the above proposal number 2.
Conceptually is probably the same thing, but I guess that syntax
should be easier to parse.
I think we agree that searching on IPs is important, so assuming ports can
have multiple IPs, it seems that we either need some special query
semantics, or to expose IPs as a top-level resource, so we can again use the
simple query semantics.
> From this thread it seems that we have a need for both.
Overall, I'm definitely open to IPs as a top-level API entity, but there are
at least a few issues to address:
1) It seems somewhat cumbersome to have to make additional port calls to add
IPs to ports, as gary mentioned. This seems like it could be addressed by
allowing a POST to /ports to include embedded IPs, just like we talked about
allowing POST to /networks to include embedded subnet info (note: we should
also figured out if we allowed embedded updates of IPs using a PUT to
/ports, or if that would require a POST to /ips).
+1 for embedding IP resources in POST requests to /ports - consider
having the same capability on /subnets
+1 for POST/PUT/DELETE request on /ips for updates
2) Having IPs as a top-level entity could be seen as being more symmetric
with the fact that subnets are a top-level entity as well. However, the
examples so far have some subtle asymmetries. First, IPs do not have a
UUID, while subnets do.
I think this is because we have not conceived them as a primary
resource. I might be naive but in my mind port : network = ip : subnet
One might argue that if something is an independent
top-level entity in the API, and you create new instances by POSTing to that
entity, it should have a UUID. Also, the subnet list in the network object
only includes IDs unless verbose=True is specified. Would we follow a
similar model with the fixed_ips attribute of a port?
This is a good point. The result of the GET operation is a view, and
the view should always return something that is meaningful to the
user. The uuid of an IP won't be useful at all, while the uuid of a
subnet is likely to be used in a subsequent call. I'd say that since
IPs are "leaf" resources in our tree, it is fine having a view that
returns by default human-readable info.
So in sum, I think either approach (special query semantics or ip as
top-level API entity) could work. My main preference is really just that we
get things decided quickly, particularly if we decide to add a new URL to
the API (as this change propagates to the client, etc.)
I agree. We already have Gary's patch on the /ports resource under
review. The next step would probably be allowing the in-like filtering
mechanism (we had it in API v1.1 after all!!!) using the IP itself
only as a searchable parameter, and then reason whether we want to
promote IPs to first class resource.
Dan
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
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
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
