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.
> 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
