Mailing List Archive

On Wed, 2012-06-20 at 19:05 +0300, Gary Kotton wrote:
> Hi,
> In the API (http://wiki.openstack.org/QuantumV2APIIntro#Port), the user
> is able to pass /*fixed_ips_v4*/ and /*fixed_ips_v6*/. If possible can
> we please change this to /*fixed_ips*/_,_ where the /*fixed_ips*/ is a
> list of dictionary's. The dictionary has the following key value pairs:
> 'subnet_id' : <subnet uuid> This is mandatory if configured.
> 'ip_address': <a ip v4 or ipv6 address - depending on the subnet
> defined above>. This is optional.
>
> The server will treat the values as follows:
> i. If this is not set then then a address will be allocated if
> there is a subnet defined on the network. This will be done for IPv4 and
> IPv6 subnets.
> ii. If only the subnet ID is set then the server will assign an IP
> address from the specific subnet
> iii. If both are set the server will allocate this address (if it
> has not already been allocated :))
>
> Please note that in all of the above cases the input will be checked for
> validity, for example - the subnet_id is a configured subnet on the
> network etc.
>
> Please let me know if you have any comments.

The only issue is then we can't search by ip unless we invent a schema
for nested resource searching. One of the reasons I was an advocate of a
top level /ips resource.

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

On 06/20/2012 07:39 PM, Jason Kölker wrote:
> On Wed, 2012-06-20 at 19:05 +0300, Gary Kotton wrote:
>> Hi,
>> In the API (http://wiki.openstack.org/QuantumV2APIIntro#Port), the user
>> is able to pass /*fixed_ips_v4*/ and /*fixed_ips_v6*/. If possible can
>> we please change this to /*fixed_ips*/_,_ where the /*fixed_ips*/ is a
>> list of dictionary's. The dictionary has the following key value pairs:
>> 'subnet_id' :<subnet uuid> This is mandatory if configured.
>> 'ip_address':<a ip v4 or ipv6 address - depending on the subnet
>> defined above>. This is optional.
>>
>> The server will treat the values as follows:
>> i. If this is not set then then a address will be allocated if
>> there is a subnet defined on the network. This will be done for IPv4 and
>> IPv6 subnets.
>> ii. If only the subnet ID is set then the server will assign an IP
>> address from the specific subnet
>> iii. If both are set the server will allocate this address (if it
>> has not already been allocated :))
>>
>> Please note that in all of the above cases the input will be checked for
>> validity, for example - the subnet_id is a configured subnet on the
>> network etc.
>>
>> Please let me know if you have any comments.
> The only issue is then we can't search by ip unless we invent a schema
> for nested resource searching. One of the reasons I was an advocate of a
> top level /ips resource.
I am not sure that I understand. I do not understand how the
configuration parameters affect the search. Can you please clarify. The
above proposal is changing the input from the user.
> 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

On Wed, Jun 20, 2012 at 9:05 AM, Gary Kotton <gkotton@redhat.com> wrote:

> **
> Hi,
> In the API (http://wiki.openstack.org/QuantumV2APIIntro#Port), the user
> is able to pass *fixed_ips_v4* and *fixed_ips_v6*. If possible can we
> please change this to *fixed_ips**,* where the *fixed_ips* is a list of
> dictionary's. The dictionary has the following key value pairs:
> 'subnet_id' : <subnet uuid> This is mandatory if configured.
> 'ip_address': <a ip v4 or ipv6 address - depending on the subnet
> defined above>. This is optional.
>
> The server will treat the values as follows:
> i. If this is not set then then a address will be allocated if there
> is a subnet defined on the network. This will be done for IPv4 and IPv6
> subnets.
> ii. If only the subnet ID is set then the server will assign an IP
> address from the specific subnet
> iii. If both are set the server will allocate this address (if it has
> not already been allocated :))
>
> Please note that in all of the above cases the input will be checked for
> validity, for example - the subnet_id is a configured subnet on the network
> etc.
>

I think this makes sense, and seems inline with some feedback on the API v2
wiki.

One other case to consider is how someone adds/removes an IP after the fact
to a port. The model I was thinking was that a PUT can update the list,
and we effectively do a diff agains the previous list, add/removing IPs if
needed. To request a new IP be allocated from the subnet on up update,
just add an entry to the list that includes only a subnet_id (as is the
case with add).

dan



>
> Please let me know if you have any comments.
> Thanks
> Gary
>
> --
> 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~

On Wed, Jun 20, 2012 at 9:39 AM, Jason Kölker <jkoelker@rackspace.com>wrote:

> On Wed, 2012-06-20 at 19:05 +0300, Gary Kotton wrote:
> > Hi,
> > In the API (http://wiki.openstack.org/QuantumV2APIIntro#Port), the user
> > is able to pass /*fixed_ips_v4*/ and /*fixed_ips_v6*/. If possible can
> > we please change this to /*fixed_ips*/_,_ where the /*fixed_ips*/ is a
> > list of dictionary's. The dictionary has the following key value pairs:
> > 'subnet_id' : <subnet uuid> This is mandatory if configured.
> > 'ip_address': <a ip v4 or ipv6 address - depending on the subnet
> > defined above>. This is optional.
> >
> > The server will treat the values as follows:
> > i. If this is not set then then a address will be allocated if
> > there is a subnet defined on the network. This will be done for IPv4 and
> > IPv6 subnets.
> > ii. If only the subnet ID is set then the server will assign an IP
> > address from the specific subnet
> > iii. If both are set the server will allocate this address (if it
> > has not already been allocated :))
> >
> > Please note that in all of the above cases the input will be checked for
> > validity, for example - the subnet_id is a configured subnet on the
> > network etc.
> >
> > Please let me know if you have any comments.
>
> The only issue is then we can't search by ip unless we invent a schema
> for nested resource searching. One of the reasons I was an advocate of a
> top level /ips resource.
>

Hi Jason,

The fact that the existing API doesn't have a straightforward way of
searching for ports by IP is definitely something that bothers me as well,
and we need a good solution for it.

I believe the basic filtering model were were originally shooting for with
the v2 API is that we could do exact match filtering on any top-level
dictionary key. However, I don't think that supports searching on IPs,
even with the old model.

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?

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

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

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?

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

On Wed, 2012-06-20 at 20:27 +0300, Gary Kotton wrote:
> >>
> >> Please let me know if you have any comments.
> > The only issue is then we can't search by ip unless we invent a schema
> > for nested resource searching. One of the reasons I was an advocate of a
> > top level /ips resource.
> I am not sure that I understand. I do not understand how the
> configuration parameters affect the search. Can you please clarify. The
> above proposal is changing the input from the user.

So to search for an ip we can currently do:

GET /ports?ips=172.16.0.1

Since this would be an encapsulated resource (you cant get to it any
other way), we'd have to document a hierarchy separator so something
like:

GET /ports?ips.ip_address=172.16.0.1

This just seams dirty to me, since I would expect ip then to not be a
collection but to be a resource itself.

Much better in my opinion would be:

GET /ips?address=172.16.0.1

Since its a direct lookup on a resource.

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

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.

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


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

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

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

On 06/20/2012 09:42 PM, Dan Wendlandt wrote:
>
>
> On Wed, Jun 20, 2012 at 9:05 AM, Gary Kotton <gkotton@redhat.com
> <mailto:gkotton@redhat.com>> wrote:
>
> Hi,
> In the API (http://wiki.openstack.org/QuantumV2APIIntro#Port), the
> user is able to pass /*fixed_ips_v4*/ and /*fixed_ips_v6*/. If
> possible can we please change this to /*fixed_ips*/_,_ where the
> /*fixed_ips*/ is a list of dictionary's. The dictionary has the
> following key value pairs:
> 'subnet_id' : <subnet uuid> This is mandatory if configured.
> 'ip_address': <a ip v4 or ipv6 address - depending on the
> subnet defined above>. This is optional.
>
> The server will treat the values as follows:
> i. If this is not set then then a address will be allocated if
> there is a subnet defined on the network. This will be done for
> IPv4 and IPv6 subnets.
> ii. If only the subnet ID is set then the server will assign
> an IP address from the specific subnet
> iii. If both are set the server will allocate this address (if
> it has not already been allocated :))
>
> Please note that in all of the above cases the input will be
> checked for validity, for example - the subnet_id is a configured
> subnet on the network etc.
>
>
> I think this makes sense, and seems inline with some feedback on the
> API v2 wiki.
>
> One other case to consider is how someone adds/removes an IP after the
> fact to a port. The model I was thinking was that a PUT can update
> the list, and we effectively do a diff agains the previous list,
> add/removing IPs if needed. To request a new IP be allocated from the
> subnet on up update, just add an entry to the list that includes only
> a subnet_id (as is the case with add).

OK, sounds reasonable.
>
> dan
>
>
> Please let me know if you have any comments.
> Thanks
> Gary
>
> --
> Mailing list: https://launchpad.net/~netstack
> <https://launchpad.net/%7Enetstack>
> Post to : netstack@lists.launchpad.net
> <mailto:netstack@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~netstack
> <https://launchpad.net/%7Enetstack>
> More help : https://help.launchpad.net/ListHelp
>
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Dan Wendlandt
> Nicira, Inc: www.nicira.com <http://www.nicira.com>
> twitter: danwendlandt
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

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 <jkoelker@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

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<jkoelker@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

Replies inline!

Have a good day,
Salvatore

On 21 June 2012 12:56, Gary Kotton <gkotton@redhat.com> wrote:
> 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 get the point, and it totally makes sense.
On the other hand, I might argue that I would like to have a port
allocated and configured when an IP is allocated...
(I'm not really advocating it - just trying to make an example!)

The bottom line is whether IPs are worth being a resource on their own
or just an attribute of the relationship between the "port" and the
"subnet" resources.
In the first case, IPs could either be a first level resource, as
advocated by Jason, or a second level resource, as the port was in
Quantum v1.
In the latter case, the situation is somewhat similar to the
"attachment" we had in v1, and we should be able to use either PUTs
on both subnet and port resources to allocate them, or the
corresponding POST operation, as Gary suggest.

Is there any particular reason for not considering IPs as resources in
the Quantum API? (Apart from avoiding an additional step for IP
configuration)

> I think that having an additional step for IP configuration could be
> cumbersome for the user.

That is true. Finding the right trade-off between simplicity (ie:
atomic operations) and efficiency (ie: avoid unnecessary API calls
whenever possible) should be our goals. We can do whatever we want,
but so far we've avoided operations involving several resources at
once. For instance a first prototype had an operation which created a
network and a bunch of ports, but that operation was then removed.
I don't think we are REST fundamentalists though :) Nothing has been
cast in stone, and moreover is we decide IPs are not worth being a
resource, then the problem will not exist at all!

> Is there any option of say adding the table that
> you have suggested for read only purposes?
>

A read-only resource? I'm neutral on this - read-only resources are
often used in REST APIs, but I don't know whether they would be
welcome in this one...


>
>> 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<jkoelker@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

--
Mailing list: https://launchpad.net/~netstack
Post to : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help : https://help.launchpad.net/ListHelp

On Thu, 2012-06-21 at 10:27 +0100, Salvatore Orlando wrote:
> > > 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?

fixed_ips is the collection, fixed_ip is the element in the collection.
I think by using the pluralized form it makes sense to know that this is
a collection and the non-pluralized that its an element in the
pluralized collection.

So to take it further:

GET /ports?fixed_ips=10.0.0.2&fixed_ips=172.16.0.1

*Could* translate to:

WHERE ['10.0.0.2', '172.16.0.1'] == fixed_ips

And

GET /ports?fixed_ip=10.0.0.2

would translate to:

WHERE '10.0.0.2' IN fixed_ips

Note however I'm -1 on allowing the search of the exact collection, I
think it would make it confusing, but this is an implementation detail
left to plugin vendors.

> 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)?

Yea I'm indifferent on just creating a DSL for querying.

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

Right, its an object (and really a resource) all in its own then that
has its own set of attributes.

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

It doesn't. Its just whether its the query string, a form-encoded body,
or a json body of the same format, it really doesn't matter all that
much, so I was pointing out that I see them all as interchangeable. My
personal preference however is the query string or the form-encoded
body, as a POST with a json body to me seems like a request with a
partial resource. In this case it is since the selectors end up being
part of the resource object, but in other api's I've used that's not
always the case, so I err on that side.

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

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.

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

On Thu, Jun 21, 2012 at 5:34 PM, Jason Kölker <jkoelker@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
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Joining Dan in the late-night fun of doing emails :)

Replies inline.
Salvatore

On 21 June 2012 23:59, Dan Wendlandt <dan@nicira.com> wrote:
>
>
> On Thu, Jun 21, 2012 at 5:34 PM, Jason Kölker <jkoelker@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

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<dan@nicira.com> wrote:
>>
>> On Thu, Jun 21, 2012 at 5:34 PM, Jason Kölker<jkoelker@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