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?). The nested "." syntax
is another example of special semantics.
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.
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).
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. 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?
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.)
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
