Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
Right now we force tenants choose a CIDR even if they don't care what address they get. This allows them to skip that required input. More importantly, if the network is fully routed, not only do tenants not know which CIDR to configure, allowing them to choose arbitrary CIDRs can disrupt the entire network. This workflow isn't stopping the old one from working, it's just enabling new deployments that basically weren't feasible before since we had an implicit requirement that the tenants could configure whatever addresses they wanted. On Mar 26, 2015 10:23 AM, Neil Jerram neil.jer...@metaswitch.com wrote: Salvatore Orlando sorla...@nicira.com writes: Neutron is adding a new concept of subnet pool. [...] http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html I apologize for asking this question so long after this spec has been proposed and discussed - but what is the problem that subnet allocation solves? Or what is it possible to do with subnet allocation, that was not possible before? Of course the spec has text to address this, but for me it doesn't actually answer the above questions: Problem Description IPAM in Neutron cannot allocate subnets. Subnet details must be specified by the End User at the time of subnet creation. This seems to me to be restating the premise. End Users may want to offload the burden of keeping track of subnets and which addresses are in use. In this case, the End User should be able to set up a private address space from which these are automatically allocated. This sounds to me like what already happens. When I launch a set of instances, I simply specify which subnet to use for each of their vNICs. The Neutron DB keeps track of which addresses are in use, so I don't see any burden here. For IPv4, this will often be a portion of the RFC1918 address space but doesn’t need to be. It might be part of a corporate address space which has been delegated to the cloud. For IPv6, the End User may want Neutron to automatically calculate a useable ULA subnet using a pseudo-random algorithm in harmony with RFC4193 [1]. This seems equivalent to configuring that usable subnet explicitly and then launching instances that are attached to its network. This implies that the algorithm for the selection of subnets within the space is pluggable in some way. [1] http://tools.ietf.org/html/rfc4193 Deployers will set up external networks and may have a chunk of routable addresses that could be leased or delegated to tenants for use on their networks. And that could presumably be configured as subnets? Neutron needs an API for creating and managaging address spaces and making them available to tenants. I can certainly see the value in address spaces (or scopes) as a distinct concept from tenants - if that is what this is saying. But I believe that's an independent concept from the idea of changing from explicit subnet configuration to subnet allocation, because it would be possible for an operator or tenant to configure a subnet within one of the address spaces that was available to them. Many thanks, and apologies again for asking this so late in the game. Regards, Neil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
Salvatore Orlando sorla...@nicira.com writes: Neutron is adding a new concept of subnet pool. [...] http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html I apologize for asking this question so long after this spec has been proposed and discussed - but what is the problem that subnet allocation solves? Or what is it possible to do with subnet allocation, that was not possible before? Of course the spec has text to address this, but for me it doesn't actually answer the above questions: Problem Description IPAM in Neutron cannot allocate subnets. Subnet details must be specified by the End User at the time of subnet creation. This seems to me to be restating the premise. End Users may want to offload the burden of keeping track of subnets and which addresses are in use. In this case, the End User should be able to set up a private address space from which these are automatically allocated. This sounds to me like what already happens. When I launch a set of instances, I simply specify which subnet to use for each of their vNICs. The Neutron DB keeps track of which addresses are in use, so I don't see any burden here. For IPv4, this will often be a portion of the RFC1918 address space but doesn’t need to be. It might be part of a corporate address space which has been delegated to the cloud. For IPv6, the End User may want Neutron to automatically calculate a useable ULA subnet using a pseudo-random algorithm in harmony with RFC4193 [1]. This seems equivalent to configuring that usable subnet explicitly and then launching instances that are attached to its network. This implies that the algorithm for the selection of subnets within the space is pluggable in some way. [1] http://tools.ietf.org/html/rfc4193 Deployers will set up external networks and may have a chunk of routable addresses that could be leased or delegated to tenants for use on their networks. And that could presumably be configured as subnets? Neutron needs an API for creating and managaging address spaces and making them available to tenants. I can certainly see the value in address spaces (or scopes) as a distinct concept from tenants - if that is what this is saying. But I believe that's an independent concept from the idea of changing from explicit subnet configuration to subnet allocation, because it would be possible for an operator or tenant to configure a subnet within one of the address spaces that was available to them. Many thanks, and apologies again for asking this so late in the game. Regards, Neil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
On 3/21/15, 9:10 AM, Salvatore Orlando sorla...@nicira.commailto:sorla...@nicira.com wrote: If we feel a need for specifying the relative position of gateway address and allocation pools when creating a subnet from a pool which will pick a CIDR from its prefixes, then the integer value solution is probably marginally better than the fake IP one (eg.: 0.0.0.1 to say the gateway is the first IP). Technically they're equivalent - and one could claim that the address-like notation is nothing bug and octet based representation of a number. I agree here. An integer is probably clearer. I wonder why a user would ask for a random CIDR with a given prefix, and then mandate that gateway IP and allocation pools are in precise locations within this randomly chosen CIDR. I guess there are good reasons I cannot figure out by myself. Early in the spec review cycle we talked about some generalizations of these concepts. I would consider the location of the gateway IP to be a reservation; we discussed having subnet templates that (in my mind) are essentially a collection of IP reservations. This would allow a user to specify the specific locations of various services in a pre-defined manner; routing is just one of those services that is prominent as a specific case for backwards compatibility. In my opinion all that counts here is that the semantics of a resource attribute should be the same in the request and the response. For instance, one should not have gateway_ip as a relative counter-like IP in the request body and then as an actual IP address in the response object. So, you are agreeing with an alternate name in the request, as suggested? John __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
How would you represent that you want the last address in a /26 network if you don't know what address range you are getting? 0.0.0.63? That seems pretty confusing when the resulting address turns out to be 192.168.10.191. It isn't a new concept to think about the network and host parts of an IP address separately. Definitely, but with small subnets like the example above, it is impossible to know the absolute numbers for the host portion of the address. It's about setting the right expectation for the caller. Specifying '0.0.0.63' implies the caller is going to get something back that ends in '63', which is only true some of the time. By using 'ip_index', I was trying to convey that you are getting something counted from the start of whatever is chosen, rather than getting a specific address ending. On Mon, Mar 23, 2015 at 11:25 AM, Carl Baldwin c...@ecbaldwin.net wrote: An integer index doesn't do it for me. Maybe I'm the only one. It is part of an IP address. It isn't a new concept to think about the network and host parts of an IP address separately. Why would we change the notation from dotted quad (ipv4) to integer just because we mask out the network part? Am I alone in this? Carl On Fri, Mar 20, 2015 at 3:34 PM, Kevin Benton blak...@gmail.com wrote: What if we just call it 'address_index' and make it an integer representing the offset from the network start address? On Fri, Mar 20, 2015 at 12:39 PM, Carl Baldwin c...@ecbaldwin.net wrote: On Fri, Mar 20, 2015 at 1:34 PM, Jay Pipes jaypi...@gmail.com wrote: How is 0.0.0.1 a host address? That isn't a valid IP address, AFAIK. It isn't a valid *IP* address without the network part. However, it can be referred to as the host address on the network or the host part of the IP address. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
On Mon, Mar 23, 2015 at 8:52 AM, John Belamaric jbelama...@infoblox.com wrote: On 3/21/15, 9:10 AM, Salvatore Orlando sorla...@nicira.com wrote: If we feel a need for specifying the relative position of gateway address and allocation pools when creating a subnet from a pool which will pick a CIDR from its prefixes, then the integer value solution is probably marginally better than the fake IP one (eg.: 0.0.0.1 to say the gateway is the first IP). Technically they're equivalent - and one could claim that the address-like notation is nothing bug and octet based representation of a number. I agree here. An integer is probably clearer. I don't agree. I don't see what problem this solves but I said that in another message. I wonder why a user would ask for a random CIDR with a given prefix, and then mandate that gateway IP and allocation pools are in precise locations within this randomly chosen CIDR. I guess there are good reasons I cannot figure out by myself. Salvatore makes a good point. Maybe we'll never need this. We removed the use case from Kilo because it needed further discussion. At this point, let's look for people to speak up with a need for this use case. If no one does, then we just leave it on the shelf. That has been my thinking since we dropped it but I figured the thread should continue to play itself out because it doesn't hurt to discuss it a little more here. Early in the spec review cycle we talked about some generalizations of these concepts. I would consider the location of the gateway IP to be a reservation; we discussed having subnet templates that (in my mind) are essentially a collection of IP reservations. This would allow a user to specify the specific locations of various services in a pre-defined manner; routing is just one of those services that is prominent as a specific case for backwards compatibility. I figure some users may like to have a consistent pattern for how to reserve parts of a subnet regardless of the network address. So, I agree with John here. It is really orthogonal to the specific network address used. I don't quite agree with Salvatore that not caring what the network address is implies that one does not care how some routinely reserved special IPs get laid out within a subnet. However, I do tend to agree that the use case may not be all that important. In my opinion all that counts here is that the semantics of a resource attribute should be the same in the request and the response. For instance, one should not have gateway_ip as a relative counter-like IP in the request body and then as an actual IP address in the response object. In my opinion, we have solved this by using some other -- write-only -- attribute for the template, index, or whatever you want to call it. Thanks Jay for this suggestion. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
An integer index doesn't do it for me. Maybe I'm the only one. It is part of an IP address. It isn't a new concept to think about the network and host parts of an IP address separately. Why would we change the notation from dotted quad (ipv4) to integer just because we mask out the network part? Am I alone in this? Carl On Fri, Mar 20, 2015 at 3:34 PM, Kevin Benton blak...@gmail.com wrote: What if we just call it 'address_index' and make it an integer representing the offset from the network start address? On Fri, Mar 20, 2015 at 12:39 PM, Carl Baldwin c...@ecbaldwin.net wrote: On Fri, Mar 20, 2015 at 1:34 PM, Jay Pipes jaypi...@gmail.com wrote: How is 0.0.0.1 a host address? That isn't a valid IP address, AFAIK. It isn't a valid *IP* address without the network part. However, it can be referred to as the host address on the network or the host part of the IP address. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
On Mon, Mar 23, 2015 at 4:23 PM, Kevin Benton blak...@gmail.com wrote: How would you represent that you want the last address in a /26 network if you don't know what address range you are getting? 0.0.0.63? That seems pretty confusing when the resulting address turns out to be 192.168.10.191. It isn't a new concept to think about the network and host parts of an IP address separately. Definitely, but with small subnets like the example above, it is impossible to know the absolute numbers for the host portion of the address. It's about setting the right expectation for the caller. Specifying '0.0.0.63' implies the caller is going to get something back that ends in '63', which is only true some of the time. By using 'ip_index', I was trying to convey that you are getting something counted from the start of whatever is chosen, rather than getting a specific address ending. I see what you're saying but it still doesn't do it for me. To me, 0.0.0.63 didn't say that I'd get something ending in .63. I know that I can get something ending in .127, .191, or .255. Also, I don't think that a raw integer like 63 would do any better at setting the expectation. I bet the same users who would be surprised by one would be surprised by the other. My vote would still be to use the dotted-quad notation. When working with ipv4 addresses, one must understand that the address is a 32-bit number. Dotted quad is just the familiar format for seeing them but, no matter the format, the concept is the same. The same is true for the host part. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
I don't think they would be surprised if we call it offset or index. To me, 0.0.0.63 didn't say that I'd get something ending in .63. Perhaps this is just a difference in backgrounds then. Even though I'm work on network stuff all of the time, when I see that it's not obvious that it will be masked with the inverse subnet mask to get the host bits and then combine it with the network to get the real address. Do you have some examples where this syntax is used elsewhere? Ignoring the usability concern since that might just be an issue with me, there are two other reasons that still make an integer preferable to me. First, the dotted-quad notation unnecessarily ties it to IPv4. If this is going to work for IPv6 subnets at some point, we would need to support both formats, each with their own validation logic, even though they are ultimately representing the same idea. Second, using an integer could allow negatives to make asking for the last address in the subnet as simple as '-1' instead of making the user calculate it out. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
I just think that we might bury this discussion considering what Carl said, and that I agree with. So far we don't even know if we'll ever need this feature. When a concrete use case will come for asking things like: gimme a /22 Ipv4 network and make sure I have a pool spanning from the 1st to the 444th address, and that the gateway IP is the 555th address, then we'll think about that. Just for the sake of it, in the example above I've used Kevin's proposed notation, but simply because it's a bit more natural to me. I frankly believe both address-index and relative network address not that good from a usability perspective, but probably in this case there's just no way to ensure good API UX. Salvatore On 24 March 2015 at 00:36, Kevin Benton blak...@gmail.com wrote: I don't think they would be surprised if we call it offset or index. To me, 0.0.0.63 didn't say that I'd get something ending in .63. Perhaps this is just a difference in backgrounds then. Even though I'm work on network stuff all of the time, when I see that it's not obvious that it will be masked with the inverse subnet mask to get the host bits and then combine it with the network to get the real address. Do you have some examples where this syntax is used elsewhere? Ignoring the usability concern since that might just be an issue with me, there are two other reasons that still make an integer preferable to me. First, the dotted-quad notation unnecessarily ties it to IPv4. If this is going to work for IPv6 subnets at some point, we would need to support both formats, each with their own validation logic, even though they are ultimately representing the same idea. I think this is the plan. So far we've seen only dotted-quad examples for simplicity I guess Second, using an integer could allow negatives to make asking for the last address in the subnet as simple as '-1' instead of making the user calculate it out. Just like dotted-quad notation might be usable only for people used to subnetting, masking and other IP network arithmetics, -1 would suits only developers fluent in a specific sets of languages... __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
Great suggestion Kevin. Passing 0.0.0.1 as gateway_ip_template (or whatever you call it) is essentially passing an address index, so when you OR 0.0.0.1 with the CIDR you get your gateway set as the first usable IP in the subnet. The intent of the user is to allocate the first usable IP address in the subnet to the gateway. The wildcard notation for gateway IP is really a more convoluted way of expressing this intent. Something like address_index is a little more explicit in my mind. I think Kevin is on to something. -Ryan From: Kevin Benton [mailto:blak...@gmail.com] Sent: Friday, March 20, 2015 2:34 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool What if we just call it 'address_index' and make it an integer representing the offset from the network start address? On Fri, Mar 20, 2015 at 12:39 PM, Carl Baldwin c...@ecbaldwin.netmailto:c...@ecbaldwin.net wrote: On Fri, Mar 20, 2015 at 1:34 PM, Jay Pipes jaypi...@gmail.commailto:jaypi...@gmail.com wrote: How is 0.0.0.1 a host address? That isn't a valid IP address, AFAIK. It isn't a valid *IP* address without the network part. However, it can be referred to as the host address on the network or the host part of the IP address. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
If we feel a need for specifying the relative position of gateway address and allocation pools when creating a subnet from a pool which will pick a CIDR from its prefixes, then the integer value solution is probably marginally better than the fake IP one (eg.: 0.0.0.1 to say the gateway is the first IP). Technically they're equivalent - and one could claim that the address-like notation is nothing bug and octet based representation of a number. I wonder why a user would ask for a random CIDR with a given prefix, and then mandate that gateway IP and allocation pools are in precise locations within this randomly chosen CIDR. I guess there are good reasons I cannot figure out by myself. In my opinion all that counts here is that the semantics of a resource attribute should be the same in the request and the response. For instance, one should not have gateway_ip as a relative counter-like IP in the request body and then as an actual IP address in the response object. Salvatore On 21 March 2015 at 00:08, Tidwell, Ryan ryan.tidw...@hp.com wrote: Great suggestion Kevin. Passing 0.0.0.1 as gateway_ip_template (or whatever you call it) is essentially passing an address index, so when you OR 0.0.0.1 with the CIDR you get your gateway set as the first usable IP in the subnet. The intent of the user is to allocate the first usable IP address in the subnet to the gateway. The wildcard notation for gateway IP is really a more convoluted way of expressing this intent. Something like address_index is a little more explicit in my mind. I think Kevin is on to something. -Ryan *From:* Kevin Benton [mailto:blak...@gmail.com] *Sent:* Friday, March 20, 2015 2:34 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool What if we just call it 'address_index' and make it an integer representing the offset from the network start address? On Fri, Mar 20, 2015 at 12:39 PM, Carl Baldwin c...@ecbaldwin.net wrote: On Fri, Mar 20, 2015 at 1:34 PM, Jay Pipes jaypi...@gmail.com wrote: How is 0.0.0.1 a host address? That isn't a valid IP address, AFAIK. It isn't a valid *IP* address without the network part. However, it can be referred to as the host address on the network or the host part of the IP address. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes jaypi...@gmail.com wrote:
2) Is the action of creating a subnet from a pool better realized as a
different way of creating a subnet, or should there be some sort of
pool action? Eg.:
POST /subnet_pools/my_pool_id/subnet
{'prefix_len': 24}
which would return a subnet response like this (note prefix_len might
not be needed in this case)
{'id': 'meh',
'cidr': '192.168.0.0/24 http://192.168.0.0/24',
'gateway_ip': '192.168.0.1',
'pool_id': 'my_pool_id'}
I am generally not a big fan of RESTful actions. But in this case the
semantics of the API operation are that of a subnet creation from within
a pool, so that might be ok.
+1 to using resource subcollection semantics here.
The issue I see here is that there is a window of time between
requesting the subnet allocation and creating the subnet when the
subnet could be taken by someone else. We need to acknowledge the
window and address it somehow.
Does IPAM hold a reservation or something on the subnet to lock out
others? Or, does the client just retry on failure? If there are
multiple clients requesting subnet allocations, it seems that IPAM
should keep some state (e.g. a reservation) to avoid giving out the
same one more than once to difference clients at least.
I think that the first operation should result in full allocation of
the subnet to the tenant. In this case, I think that the allocation
should have an id and be a first class object (it is not currently).
The tenant will need to manage these allocations like anything else.
The tenant will also be required to delete unused allocations. This
might be the way to go long-term.
If allocations have an id. I think I'd have the client pass in the
allocation id instead of the pool id to the subnet create to
differentiate between asking for a new allocation and using an
existing allocation.
Carl
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
On 03/20/2015 02:51 PM, Carl Baldwin wrote:
On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes jaypi...@gmail.com wrote:
What about this instead?
POST /v2.0/subnets
{
'network_id': 'meh',
'gateway_ip_template': '*.*.*.1'
'prefix_len': 24,
'pool_id': 'some_pool'
}
At least that way it's clear the gateway attribute is not an IP, but a
template/string instead?
I thought about doing *s but in the world of Classless Inter-Domain
Routing where not all networks are /24, /16, or /8 it seemed a bit
imprecise. But, maybe that doesn't matter.
Understood.
I think the more important difference with your proposal here is that
it is passed as a new attribute called 'gateway_ip_template'. I don't
think that attribute would ever be sent back to the user. Is it ok to
have write-only attributes? Is everyone comfortable with that?
I don't see anything wrong with attributes that are only in the request.
I mean, we have attributes that are only in the response (things like
status, for example).
Looking at the EC2 API, they support write-only attributes as well,
for just this purpose:
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html
The MaxCount and MinCount attributes are not in the response but are in
the request. Same thing for Nova's POST /servers REST API (min_count,
max_count).
Best,
-jay
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes jaypi...@gmail.com wrote:
What about this instead?
POST /v2.0/subnets
{
'network_id': 'meh',
'gateway_ip_template': '*.*.*.1'
'prefix_len': 24,
'pool_id': 'some_pool'
}
At least that way it's clear the gateway attribute is not an IP, but a
template/string instead?
I thought about doing *s but in the world of Classless Inter-Domain
Routing where not all networks are /24, /16, or /8 it seemed a bit
imprecise. But, maybe that doesn't matter.
I think the more important difference with your proposal here is that
it is passed as a new attribute called 'gateway_ip_template'. I don't
think that attribute would ever be sent back to the user. Is it ok to
have write-only attributes? Is everyone comfortable with that?
Carl
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
On Fri, Mar 20, 2015 at 12:58 PM, Dean Troyer dtro...@gmail.com wrote: I thought about doing *s but in the world of Classless Inter-Domain Routing where not all networks are /24, /16, or /8 it seemed a bit imprecise. But, maybe that doesn't matter. So do a CIDR host address: 0.0.0.1/24 can be merged into a subnet just as easily as it can be masked out. Dean, I'm not sure what you're suggesting. Are you suggesting that 0.0.0.1/24 is suitable as a template for the gateway? If so, that is what I had originally proposed in the spec and what others seemed to object to. Maybe what others didn't like was that a template was passed in for gateway_ip. In this case, does passing a template like this as 'gateway_ip_template' make them feel better? Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
On 03/09/2015 09:05 AM, Salvatore Orlando wrote:
POST /v2.0/subnets
{'network_id': 'meh',
'gateway_ip': '0.0.0.1',
'prefix_len': 24,
'pool_id': 'some_pool'}
would indicate that the user wishes to use the first address in the
range as the gateway IP, and the API would return something like this:
Yeah, the above is definitely icky. (technical term, there...)
What about this instead?
POST /v2.0/subnets
{
'network_id': 'meh',
'gateway_ip_template': '*.*.*.1'
'prefix_len': 24,
'pool_id': 'some_pool'
}
At least that way it's clear the gateway attribute is not an IP, but a
template/string instead?
2) Is the action of creating a subnet from a pool better realized as a
different way of creating a subnet, or should there be some sort of
pool action? Eg.:
POST /subnet_pools/my_pool_id/subnet
{'prefix_len': 24}
which would return a subnet response like this (note prefix_len might
not be needed in this case)
{'id': 'meh',
'cidr': '192.168.0.0/24 http://192.168.0.0/24',
'gateway_ip': '192.168.0.1',
'pool_id': 'my_pool_id'}
I am generally not a big fan of RESTful actions. But in this case the
semantics of the API operation are that of a subnet creation from within
a pool, so that might be ok.
+1 to using resource subcollection semantics here.
3) Would it be possible to consider putting information about how to
generate a subnet from a pool in the subnet request body as follows?
POST /v2.0/subnets
{
'pool_info':
{'pool_id': my_pool_id,
'prefix_len': 24}
}
-1. Too complicated IMO.
Best,
-jay
This would return a response like the previous.
This approach is in theory simple, but composite attributes proved to a
difficult beast already - for instance you can look at
external_gateway_info in the router definition [4]
Thanks for your time and thanks in advance for your feedback.
Salvatore
[1]
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html
[2] https://review.openstack.org/#/c/148698/
[3] https://review.openstack.org/#/c/157597/21/neutron/api/v2/attributes.py
[4]
http://git.openstack.org/cgit/openstack/neutron/tree/neutron/extensions/l3.py#n106
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
On Fri, Mar 20, 2015 at 1:09 PM, Dean Troyer dtro...@gmail.com wrote: Template is totally the wrong word. It is a host address without a network. The prefix is there for the same purpose, to OR it back into a network address. I just want us to stop inventing things that already exist. You want to specify the gateway IP, to get that you need a network address, presumably to be allocated somewhere and a host address. OR them together and you have an IP address. I'm not sure template is the wrong word. But, I think we're just arguing terminology now. To me, calling it a template indicates that it must be combined with something else before it is usable for our purpose. Here are some options for what to call the attribute: gateway_ip_template: '0.0.0.1' gateway_ip_host: '0.0.0.1' gateway_ip_host_part: '0.0.0.1' I'm sure there are 100 other names we could use. The key take-aways for me are that we don't use '*.*.*.1' and that we don't pass the host-only part of the address as the 'gateway_ip'. So, these are wrong IMO: gateway_ip: '0.0.0.1' gateway_ip_template: '*.*.*.1' gateway_ip_host_port: '*.*.*.1' Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
On 03/20/2015 03:02 PM, Carl Baldwin wrote:
On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes jaypi...@gmail.com wrote:
2) Is the action of creating a subnet from a pool better realized as a
different way of creating a subnet, or should there be some sort of
pool action? Eg.:
POST /subnet_pools/my_pool_id/subnet
{'prefix_len': 24}
which would return a subnet response like this (note prefix_len might
not be needed in this case)
{'id': 'meh',
'cidr': '192.168.0.0/24 http://192.168.0.0/24',
'gateway_ip': '192.168.0.1',
'pool_id': 'my_pool_id'}
I am generally not a big fan of RESTful actions. But in this case the
semantics of the API operation are that of a subnet creation from within
a pool, so that might be ok.
+1 to using resource subcollection semantics here.
The issue I see here is that there is a window of time between
requesting the subnet allocation and creating the subnet when the
subnet could be taken by someone else. We need to acknowledge the
window and address it somehow.
I actually don't think the API URI structure should acknowledge if there
is or is not a window of time that is involved in some action. Instead,
whether or not the API call returns a 202 Accepted or a 201 Created
should be sufficient for communicating that information to the API user.
Does IPAM hold a reservation or something on the subnet to lock out
others? Or, does the client just retry on failure? If there are
multiple clients requesting subnet allocations, it seems that IPAM
should keep some state (e.g. a reservation) to avoid giving out the
same one more than once to difference clients at least.
Any API that returns 202 Accepted must return information in the HTTP
headers (Location: URI) about where the client can get an update on
the status of the resource that should be created:
https://github.com/openstack/api-wg/blob/master/guidelines/http.rst#2xx-success-codes
Whether or not this mechanism returns a reservation resource link
(something like /reservations/{res_id}), or a link to the resource
itself (/subnets/{subnet_id}) is entirely implementation-dependent.
I personally prefer the latter, but could go either way.
I think that the first operation should result in full allocation of
the subnet to the tenant. In this case, I think that the allocation
should have an id and be a first class object (it is not currently).
The tenant will need to manage these allocations like anything else.
The tenant will also be required to delete unused allocations. This
might be the way to go long-term.
In this case, you are suggesting to make the REST API operation
synchronous, and should use 201 Created.
There's no reason you couldn't support both the top-level and the
subcollection resource method of creating the subnet, though.
For instance, these two API calls would essentially be the same:
POST /subnets
{
'pool_id': 'some_pool',
'network_id': 'some_network',
'cidr': '192.168.0.0./24'
}
POST /subnetpools/some_pool/subnets
{
'network_id': 'some_network',
'cidr': '192.168.0.0./24'
}
And the above is totally fine, IMO.
Best,
-jay
If allocations have an id. I think I'd have the client pass in the
allocation id instead of the pool id to the subnet create to
differentiate between asking for a new allocation and using an
existing allocation.
Carl
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
On Fri, Mar 20, 2015 at 1:07 PM, Jay Pipes jaypi...@gmail.com wrote:
On 03/20/2015 02:51 PM, Carl Baldwin wrote:
On Fri, Mar 20, 2015 at 12:18 PM, Jay Pipes jaypi...@gmail.com wrote:
What about this instead?
POST /v2.0/subnets
{
'network_id': 'meh',
'gateway_ip_template': '*.*.*.1'
'prefix_len': 24,
'pool_id': 'some_pool'
}
At least that way it's clear the gateway attribute is not an IP, but a
template/string instead?
I thought about doing *s but in the world of Classless Inter-Domain
Routing where not all networks are /24, /16, or /8 it seemed a bit
imprecise. But, maybe that doesn't matter.
Understood.
I think the more important difference with your proposal here is that
it is passed as a new attribute called 'gateway_ip_template'. I don't
think that attribute would ever be sent back to the user. Is it ok to
have write-only attributes? Is everyone comfortable with that?
I don't see anything wrong with attributes that are only in the request. I
mean, we have attributes that are only in the response (things like status,
for example).
Looking at the EC2 API, they support write-only attributes as well, for
just this purpose:
http://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_RunInstances.html
The MaxCount and MinCount attributes are not in the response but are in the
request. Same thing for Nova's POST /servers REST API (min_count,
max_count).
Makes sense. I think I like this gateway_ip_template attribute then
for this purpose.
Carl
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
On Fri, Mar 20, 2015 at 1:34 PM, Jay Pipes jaypi...@gmail.com wrote: How is 0.0.0.1 a host address? That isn't a valid IP address, AFAIK. It isn't a valid *IP* address without the network part. However, it can be referred to as the host address on the network or the host part of the IP address. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
What if we just call it 'address_index' and make it an integer representing the offset from the network start address? On Fri, Mar 20, 2015 at 12:39 PM, Carl Baldwin c...@ecbaldwin.net wrote: On Fri, Mar 20, 2015 at 1:34 PM, Jay Pipes jaypi...@gmail.com wrote: How is 0.0.0.1 a host address? That isn't a valid IP address, AFAIK. It isn't a valid *IP* address without the network part. However, it can be referred to as the host address on the network or the host part of the IP address. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
I agree with dropping support for the wildcards. It can always be revisited at later. I agree that being locked into backward compatibility with a design that we really haven't thought through is a good thing to avoid. Most importantly (to me anyway) is that this will help in getting subnet allocation completed for Kilo. We can iterate on it later, but at least the base functionality will be there. -Ryan -Original Message- From: Carl Baldwin [mailto:c...@ecbaldwin.net] Sent: Tuesday, March 10, 2015 11:44 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool On Tue, Mar 10, 2015 at 12:24 PM, Salvatore Orlando sorla...@nicira.com wrote: I guess that frustration has now become part of the norm for Openstack. It is not the first time I frustrate people because I ask to reconsider decisions approved in specifications. I'm okay revisiting decisions. It is just the timing that is difficult. This is probably bad behaviour on my side. Anyway, I'm not suggesting to go back to the drawing board, merely trying to get larger feedback, especially since that patch should always have had the ApiImpact flag. It did have the ApiImpact flag since PS1 [1]. Needless to say, I'm happy to proceed with things as they've been agreed. I'm happy to discuss and I value your input very highly. I was just hoping that it had come at a better time to react. There is nothing intrinsically wrong with it - in the sense that it does not impact the functional behaviour of the system. My comment is about RESTful API guidelines. What we pass to/from the API endpoint is a resource, in this case the subnet being created. You expect gateway_ip to be always one thing - a gateway address, whereas with the wildcarded design it could be an address or an incremental counter within a range, but with the counter being valid only in request objects. Differences in entities between requests and response are however fairly common in RESTful APIs, so if the wildcards sastisfy a concrete and valid use case I will stop complaining, but I'm not sure I see any use case for wildcarded gateways and allocation pools. Let's drop the use case and the wildcards as we've discussed. Also, there might also be backward-compatible ways of switching from one approach to another, in which case I'm happy to keep things as they are and relieve Ryan from yet another worry. I think dropping the use case for now allows us the most freedom and doesn't commit us to supporting backward compatibility for a decision that may end up proving to be a mistake in API design. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I also agree wilcards do not look solid, and without clear use cases with reasonable demand from operators, it's better to avoid putting ourselves into position of supporting the feature for eternity. We had cases of immature API design rushed into the tree before (particularly, ipv6 ra|addr modes for subnets) resulting in long fire fighting and confusing behaviour that we're stuck in, and it's better to avoid it here if possible. /Ihar On 03/10/2015 09:03 PM, Tidwell, Ryan wrote: I agree with dropping support for the wildcards. It can always be revisited at later. I agree that being locked into backward compatibility with a design that we really haven't thought through is a good thing to avoid. Most importantly (to me anyway) is that this will help in getting subnet allocation completed for Kilo. We can iterate on it later, but at least the base functionality will be there. -Ryan -Original Message- From: Carl Baldwin [mailto:c...@ecbaldwin.net] Sent: Tuesday, March 10, 2015 11:44 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool On Tue, Mar 10, 2015 at 12:24 PM, Salvatore Orlando sorla...@nicira.com wrote: I guess that frustration has now become part of the norm for Openstack. It is not the first time I frustrate people because I ask to reconsider decisions approved in specifications. I'm okay revisiting decisions. It is just the timing that is difficult. This is probably bad behaviour on my side. Anyway, I'm not suggesting to go back to the drawing board, merely trying to get larger feedback, especially since that patch should always have had the ApiImpact flag. It did have the ApiImpact flag since PS1 [1]. Needless to say, I'm happy to proceed with things as they've been agreed. I'm happy to discuss and I value your input very highly. I was just hoping that it had come at a better time to react. There is nothing intrinsically wrong with it - in the sense that it does not impact the functional behaviour of the system. My comment is about RESTful API guidelines. What we pass to/from the API endpoint is a resource, in this case the subnet being created. You expect gateway_ip to be always one thing - a gateway address, whereas with the wildcarded design it could be an address or an incremental counter within a range, but with the counter being valid only in request objects. Differences in entities between requests and response are however fairly common in RESTful APIs, so if the wildcards sastisfy a concrete and valid use case I will stop complaining, but I'm not sure I see any use case for wildcarded gateways and allocation pools. Let's drop the use case and the wildcards as we've discussed. Also, there might also be backward-compatible ways of switching from one approach to another, in which case I'm happy to keep things as they are and relieve Ryan from yet another worry. I think dropping the use case for now allows us the most freedom and doesn't commit us to supporting backward compatibility for a decision that may end up proving to be a mistake in API design. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVAMFWAAoJEC5aWaUY1u57p3IH/j3PQgbQS/g1r1xjCvLT0Dmx T25VBtT+jercZMd7Xe+isY1nhwmCOnlZH27ZwviIz6HIfL/t2qyyrW/B5t9ZiL49 kYDd2SXcxGm/qSiSV99hPMR5vVLC57PzAjwjoFoNebodbYDwqTb00jYcA/+JLgrm LQxisvo7C3QBSd+/xAyDCy4Y62B6RFvcYItmBVN2shbPkseNrJk3+jnoK0qxzOXa FyOecP1hi+W0OuR7SCEi8BBYvKSGDJ977I1+B3tUsfjBOxW1Ay5Llb3X3CfM4Xks XHA+W43lJtgz1CtK1ur906gkrNnT5ve95oxdiXj+fAl27zNUqqqKWjbt2ecbWHg= =+PU9 -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
Honestly, I'm a little frustrated that this is coming up now when we tried very hard to discuss this during the spec review and we thought we got to a resolution. It seems a little late to go back to the drawing board. On Mon, Mar 9, 2015 at 7:05 AM, Salvatore Orlando sorla...@nicira.com wrote: The problem with this approach is, in my opinion, that attributes such as gateway_ip are used with different semantics in requests and responses; this might also need users to write client applications expecting the values in the response might differ from those in the request. Is this so strange? Could you explain why this is a problem with an example? 1) (this is more for neutron people) Is there a real use case for requesting specific gateway IPs and allocation pools when allocating from a pool? If not, maybe we should let the pool set a default gateway IP and allocation pools. The user can then update them with another call. Another option would be to provide subnet templates from which a user can choose. For instance one template could have the gateway as first IP, and then a single pool for the rest of the CIDR. If you really don't like this aspect of the design then my vote will be to drop support for this use case for Kilo. Neutron will specify gateway and allocation pools from the subnet and maybe the user can update the subnet afterward if it needs to change. 2) Is the action of creating a subnet from a pool better realized as a different way of creating a subnet, or should there be some sort of pool action? Eg.: I think this shift in direction will push this work entirely out to Liberty. We have one week until Kilo-3. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
On Mon, Mar 9, 2015 at 5:34 PM, Tidwell, Ryan ryan.tidw...@hp.com wrote: With implicit allocations, the thinking is that this is where a subnet is created in a backward-compatible way with no subnetpool_id and the subnets API’s continue to work as they always have. Correct. In the case of a specific subnet allocation request (create-subnet passing a pool ID and specific CIDR), I would look in the pool’s available prefix list and carve out a subnet from one of those prefixes and ask for it to be reserved for me. In that case I know the CIDR I’ll be getting up front. In such a case, I’m not sure I’d ever specify my gateway using notation like 0.0.0.1, even if I was allowed to. If I know I’ll be getting 10.10.10.0/24, I can simply pass gateway_ip as 10.10.10.1 and be done with it. I see no added value in supporting that wildcard notation for a gateway on a specific subnet allocation. Correct. Not what it was designed for. In the case of an “any” subnet allocation request (create-subnet passing a pool ID, but no specific CIDR), I’m already delegating responsibility for addressing my subnet to Neutron. As such, it seems reasonable to not have strong opinions about details like gateway_ip when making the request to create a subnet in this manner. I'm okay dropping this use case if we need to. To me, this all points to not supporting wildcards for gateway_ip and allocation_pools on subnet create (even though it found its way into the spec). My opinion (which I think lines up with yours) is that on an any request it makes sense to let the pool fill in allocation_pools and gateway_ip when requesting an “any” allocation from a subnet pool. When creating a specific subnet from a pool, gateway IP and allocation pools could still be passed explicitly by the user. If this is what we need to do. I don't think there is high demand for this use case. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
On 10 March 2015 at 16:48, Carl Baldwin c...@ecbaldwin.net wrote: Honestly, I'm a little frustrated that this is coming up now when we tried very hard to discuss this during the spec review and we thought we got to a resolution. It seems a little late to go back to the drawing board. I guess that frustration has now become part of the norm for Openstack. It is not the first time I frustrate people because I ask to reconsider decisions approved in specifications. This is probably bad behaviour on my side. Anyway, I'm not suggesting to go back to the drawing board, merely trying to get larger feedback, especially since that patch should always have had the ApiImpact flag. Needless to say, I'm happy to proceed with things as they've been agreed. On Mon, Mar 9, 2015 at 7:05 AM, Salvatore Orlando sorla...@nicira.com wrote: The problem with this approach is, in my opinion, that attributes such as gateway_ip are used with different semantics in requests and responses; this might also need users to write client applications expecting the values in the response might differ from those in the request. Is this so strange? Could you explain why this is a problem with an example? There is nothing intrinsically wrong with it - in the sense that it does not impact the functional behaviour of the system. My comment is about RESTful API guidelines. What we pass to/from the API endpoint is a resource, in this case the subnet being created. You expect gateway_ip to be always one thing - a gateway address, whereas with the wildcarded design it could be an address or an incremental counter within a range, but with the counter being valid only in request objects. Differences in entities between requests and response are however fairly common in RESTful APIs, so if the wildcards sastisfy a concrete and valid use case I will stop complaining, but I'm not sure I see any use case for wildcarded gateways and allocation pools. 1) (this is more for neutron people) Is there a real use case for requesting specific gateway IPs and allocation pools when allocating from a pool? If not, maybe we should let the pool set a default gateway IP and allocation pools. The user can then update them with another call. Another option would be to provide subnet templates from which a user can choose. For instance one template could have the gateway as first IP, and then a single pool for the rest of the CIDR. If you really don't like this aspect of the design then my vote will be to drop support for this use case for Kilo. Neutron will specify gateway and allocation pools from the subnet and maybe the user can update the subnet afterward if it needs to change. I reckon Ryan is of the same advice as well. The point is not about what I like or not. Nobody care about that. The point is whether this really makes sense or not. If you already have use cases for using such wildcards then we'll look at supporting them. 2) Is the action of creating a subnet from a pool better realized as a different way of creating a subnet, or should there be some sort of pool action? Eg.: I think this shift in direction will push this work entirely out to Liberty. We have one week until Kilo-3. One week is barely enough for code review alone. But code-wise implementing support for a slightly different API is fairly simple. Also, there might also be backward-compatible ways of switching from one approach to another, in which case I'm happy to keep things as they are and relieve Ryan from yet another worry. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
On Tue, Mar 10, 2015 at 12:24 PM, Salvatore Orlando sorla...@nicira.com wrote: I guess that frustration has now become part of the norm for Openstack. It is not the first time I frustrate people because I ask to reconsider decisions approved in specifications. I'm okay revisiting decisions. It is just the timing that is difficult. This is probably bad behaviour on my side. Anyway, I'm not suggesting to go back to the drawing board, merely trying to get larger feedback, especially since that patch should always have had the ApiImpact flag. It did have the ApiImpact flag since PS1 [1]. Needless to say, I'm happy to proceed with things as they've been agreed. I'm happy to discuss and I value your input very highly. I was just hoping that it had come at a better time to react. There is nothing intrinsically wrong with it - in the sense that it does not impact the functional behaviour of the system. My comment is about RESTful API guidelines. What we pass to/from the API endpoint is a resource, in this case the subnet being created. You expect gateway_ip to be always one thing - a gateway address, whereas with the wildcarded design it could be an address or an incremental counter within a range, but with the counter being valid only in request objects. Differences in entities between requests and response are however fairly common in RESTful APIs, so if the wildcards sastisfy a concrete and valid use case I will stop complaining, but I'm not sure I see any use case for wildcarded gateways and allocation pools. Let's drop the use case and the wildcards as we've discussed. Also, there might also be backward-compatible ways of switching from one approach to another, in which case I'm happy to keep things as they are and relieve Ryan from yet another worry. I think dropping the use case for now allows us the most freedom and doesn't commit us to supporting backward compatibility for a decision that may end up proving to be a mistake in API design. Carl __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [api][neutron] Best API for generating subnets from pool
Greetings!
Neutron is adding a new concept of subnet pool. To put it simply, it is a
collection of IP prefixes from which subnets can be allocated. In this way
a user does not have to specify a full CIDR, but simply a desired prefix
length, and then let the pool generate a CIDR from its prefixes. The full
spec is available at [1], whereas two patches are up for review at [2]
(CRUD) and [3] (integration between subnets and subnet pools).
While [2] is quite straightforward, I must admit I am not really sure that
the current approach chosen for generating subnets from a pool might be the
best one, and I'm therefore seeking your advice on this matter.
A subnet can be created with or without a pool.
Without a pool the user will pass the desired cidr:
POST /v2.0/subnets
{'network_id': 'meh',
'cidr': '192.168.0.0/24'}
Instead with a pool the user will pass pool id and desired prefix lenght:
POST /v2.0/subnets
{'network_id': 'meh',
'prefix_len': 24,
'pool_id': 'some_pool'}
The response to the previous call would populate the subnet cidr.
So far it looks quite good. Prefix_len is a bit of duplicated information,
but that's tolerable.
It gets a bit awkward when the user specifies also attributes such as
desired gateway ip or allocation pools, as they have to be specified in a
cidr-agnostic way. For instance:
POST /v2.0/subnets
{'network_id': 'meh',
'gateway_ip': '0.0.0.1',
'prefix_len': 24,
'pool_id': 'some_pool'}
would indicate that the user wishes to use the first address in the range
as the gateway IP, and the API would return something like this:
POST /v2.0/subnets
{'network_id': 'meh',
'cidr': '10.10.10.0/24'
'gateway_ip': '10.10.10.1',
'prefix_len': 24,
'pool_id': 'some_pool'}
The problem with this approach is, in my opinion, that attributes such as
gateway_ip are used with different semantics in requests and responses;
this might also need users to write client applications expecting the
values in the response might differ from those in the request.
I have been considering alternatives, but could not find any that I would
regard as winner.
I therefore have some questions for the neutron community and the API
working group:
1) (this is more for neutron people) Is there a real use case for
requesting specific gateway IPs and allocation pools when allocating from a
pool? If not, maybe we should let the pool set a default gateway IP and
allocation pools. The user can then update them with another call. Another
option would be to provide subnet templates from which a user can choose.
For instance one template could have the gateway as first IP, and then a
single pool for the rest of the CIDR.
2) Is the action of creating a subnet from a pool better realized as a
different way of creating a subnet, or should there be some sort of pool
action? Eg.:
POST /subnet_pools/my_pool_id/subnet
{'prefix_len': 24}
which would return a subnet response like this (note prefix_len might not
be needed in this case)
{'id': 'meh',
'cidr': '192.168.0.0/24',
'gateway_ip': '192.168.0.1',
'pool_id': 'my_pool_id'}
I am generally not a big fan of RESTful actions. But in this case the
semantics of the API operation are that of a subnet creation from within a
pool, so that might be ok.
3) Would it be possible to consider putting information about how to
generate a subnet from a pool in the subnet request body as follows?
POST /v2.0/subnets
{
'pool_info':
{'pool_id': my_pool_id,
'prefix_len': 24}
}
This would return a response like the previous.
This approach is in theory simple, but composite attributes proved to a
difficult beast already - for instance you can look at
external_gateway_info in the router definition [4]
Thanks for your time and thanks in advance for your feedback.
Salvatore
[1]
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html
[2] https://review.openstack.org/#/c/148698/
[3] https://review.openstack.org/#/c/157597/21/neutron/api/v2/attributes.py
[4]
http://git.openstack.org/cgit/openstack/neutron/tree/neutron/extensions/l3.py#n106
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool
Thanks Salvatore. Here are my thoughts, hopefully there’s some merit to them:
With implicit allocations, the thinking is that this is where a subnet is
created in a backward-compatible way with no subnetpool_id and the subnets
API’s continue to work as they always have.
In the case of a specific subnet allocation request (create-subnet passing a
pool ID and specific CIDR), I would look in the pool’s available prefix list
and carve out a subnet from one of those prefixes and ask for it to be reserved
for me. In that case I know the CIDR I’ll be getting up front. In such a
case, I’m not sure I’d ever specify my gateway using notation like 0.0.0.1,
even if I was allowed to. If I know I’ll be getting 10.10.10.0/24, I can
simply pass gateway_ip as 10.10.10.1 and be done with it. I see no added value
in supporting that wildcard notation for a gateway on a specific subnet
allocation.
In the case of an “any” subnet allocation request (create-subnet passing a pool
ID, but no specific CIDR), I’m already delegating responsibility for addressing
my subnet to Neutron. As such, it seems reasonable to not have strong opinions
about details like gateway_ip when making the request to create a subnet in
this manner.
To me, this all points to not supporting wildcards for gateway_ip and
allocation_pools on subnet create (even though it found its way into the spec).
My opinion (which I think lines up with yours) is that on an any request it
makes sense to let the pool fill in allocation_pools and gateway_ip when
requesting an “any” allocation from a subnet pool. When creating a specific
subnet from a pool, gateway IP and allocation pools could still be passed
explicitly by the user.
-Ryan
From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: Monday, March 09, 2015 6:06 AM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [api][neutron] Best API for generating subnets from
pool
Greetings!
Neutron is adding a new concept of subnet pool. To put it simply, it is a
collection of IP prefixes from which subnets can be allocated. In this way a
user does not have to specify a full CIDR, but simply a desired prefix length,
and then let the pool generate a CIDR from its prefixes. The full spec is
available at [1], whereas two patches are up for review at [2] (CRUD) and [3]
(integration between subnets and subnet pools).
While [2] is quite straightforward, I must admit I am not really sure that the
current approach chosen for generating subnets from a pool might be the best
one, and I'm therefore seeking your advice on this matter.
A subnet can be created with or without a pool.
Without a pool the user will pass the desired cidr:
POST /v2.0/subnets
{'network_id': 'meh',
'cidr': '192.168.0.0/24http://192.168.0.0/24'}
Instead with a pool the user will pass pool id and desired prefix lenght:
POST /v2.0/subnets
{'network_id': 'meh',
'prefix_len': 24,
'pool_id': 'some_pool'}
The response to the previous call would populate the subnet cidr.
So far it looks quite good. Prefix_len is a bit of duplicated information, but
that's tolerable.
It gets a bit awkward when the user specifies also attributes such as desired
gateway ip or allocation pools, as they have to be specified in a
cidr-agnostic way. For instance:
POST /v2.0/subnets
{'network_id': 'meh',
'gateway_ip': '0.0.0.1',
'prefix_len': 24,
'pool_id': 'some_pool'}
would indicate that the user wishes to use the first address in the range as
the gateway IP, and the API would return something like this:
POST /v2.0/subnets
{'network_id': 'meh',
'cidr': '10.10.10.0/24http://10.10.10.0/24'
'gateway_ip': '10.10.10.1',
'prefix_len': 24,
'pool_id': 'some_pool'}
The problem with this approach is, in my opinion, that attributes such as
gateway_ip are used with different semantics in requests and responses; this
might also need users to write client applications expecting the values in the
response might differ from those in the request.
I have been considering alternatives, but could not find any that I would
regard as winner.
I therefore have some questions for the neutron community and the API working
group:
1) (this is more for neutron people) Is there a real use case for requesting
specific gateway IPs and allocation pools when allocating from a pool? If not,
maybe we should let the pool set a default gateway IP and allocation pools. The
user can then update them with another call. Another option would be to provide
subnet templates from which a user can choose. For instance one template
could have the gateway as first IP, and then a single pool for the rest of the
CIDR.
2) Is the action of creating a subnet from a pool better realized as a
different way of creating a subnet, or should there be some sort of pool
action? Eg.:
POST /subnet_pools/my_pool_id/subnet
{'prefix_len': 24}
which would return a subnet response like this (note prefix_len might not be
needed in this case)
{'id': 'meh
