Re: [openstack-dev] [Neutron][IPv6] Prefix delegation and user facing API thoughts
On 3/18/15, 9:12 PM, Sean M. Collins s...@coreitpro.com wrote: My hope is that either the new IPAM subsystem for subnet allocations would provide this, or that a small API extension could paper over some of the sharper edges. In IPAM we have added this concept of a subnet request. The built-in support would allow you to request any subnet or a specific subnet. This concept applies to both pool-based and non-pool-based requests. Currently, a request needs to be essentially encoded in the cidr field of the subnet creation API call, in order to provide complete API backwards compatibility. A blank CIDR indicates any subnet; a specific CIDR indicates to allocate that subnet. However, the intention is that individual drivers could add their own types of requests. This is supported in the request factory defined in [1]. This means, for example, we can implement a request class RFC3633SubnetRequest that handles acquiring the CIDR via prefix delegation. The user will pass RFC3633 as the cidr attribute in that case, so that the correct request class is instantiated. A similar mechanism can be used for address requests - for example, EUI64 and other auto-generated addresses. To enable this, an additional change needed beyond [1] is to use the request factory for validation of the cidr field rather than the API layer. [1] https://review.openstack.org/#/c/153236/25/neutron/ipam/__init__.py __ 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] [Neutron][IPv6] Prefix delegation and user facing API thoughts
Following discussion on IRC, a patch is now up to add this config option. Reviews appreciated. https://review.openstack.org/#/c/166973/ Cheers, John On 23/03/2015 18:11, Carl Baldwin c...@ecbaldwin.net wrote: On Mon, Mar 23, 2015 at 12:04 PM, John Davidge (jodavidg) jodav...@cisco.com wrote: The above blueprint outlines an admin-configurable global default pool to be used in the case of a user calling subnet-create without specifying a CIDR or subnet-pool ID. If the OpenStack environment has been made PD-capable by the operator (a PD-server has been setup), this default could be set in such a way to indicate that PD should be used. This would give the user a hassle-free workflow and avoids overloading api attributes. It also has the added benefit of not allowing the user to request a PD-defined CIDR in an environment that isn¹t PD-capable. Thank you for bringing up this default. This was indeed specified in the BP for this purpose. However, it is a loose end which we need to tied up. It should be easy to add the code to enable setting this default. We also need to be sure that our subnet pool code properly ignores this pool id. Ping me on IRC and we can coordinate this. 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] [Neutron][IPv6] Prefix delegation and user facing API thoughts
On Mon, Mar 23, 2015 at 12:04 PM, John Davidge (jodavidg) jodav...@cisco.com wrote: The above blueprint outlines an admin-configurable global default pool to be used in the case of a user calling subnet-create without specifying a CIDR or subnet-pool ID. If the OpenStack environment has been made PD-capable by the operator (a PD-server has been setup), this default could be set in such a way to indicate that PD should be used. This would give the user a hassle-free workflow and avoids overloading api attributes. It also has the added benefit of not allowing the user to request a PD-defined CIDR in an environment that isn¹t PD-capable. Thank you for bringing up this default. This was indeed specified in the BP for this purpose. However, it is a loose end which we need to tied up. It should be easy to add the code to enable setting this default. We also need to be sure that our subnet pool code properly ignores this pool id. Ping me on IRC and we can coordinate this. 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] [Neutron][IPv6] Prefix delegation and user facing API thoughts
Going forward, I think the best approach for PD would be to align with the subnet-pools being added by the subnet allocation BP work (thanks to Sean for bringing this to our attention again). http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-alloca tion.html#rest-api-impact The above blueprint outlines an admin-configurable global default pool to be used in the case of a user calling subnet-create without specifying a CIDR or subnet-pool ID. If the OpenStack environment has been made PD-capable by the operator (a PD-server has been setup), this default could be set in such a way to indicate that PD should be used. This would give the user a hassle-free workflow and avoids overloading api attributes. It also has the added benefit of not allowing the user to request a PD-defined CIDR in an environment that isn¹t PD-capable. If anyone has any concerns/comments about such an approach I¹d be happy to hear them. I¹ll be keeping my eye on the subnet allocation patches as they are merged so we can align our patch as soon as it¹s feasible. Cheers, John On 23/03/2015 15:31, John Belamaric jbelama...@infoblox.com wrote: On 3/18/15, 9:12 PM, Sean M. Collins s...@coreitpro.com wrote: My hope is that either the new IPAM subsystem for subnet allocations would provide this, or that a small API extension could paper over some of the sharper edges. In IPAM we have added this concept of a subnet request. The built-in support would allow you to request any subnet or a specific subnet. This concept applies to both pool-based and non-pool-based requests. Currently, a request needs to be essentially encoded in the cidr field of the subnet creation API call, in order to provide complete API backwards compatibility. A blank CIDR indicates any subnet; a specific CIDR indicates to allocate that subnet. However, the intention is that individual drivers could add their own types of requests. This is supported in the request factory defined in [1]. This means, for example, we can implement a request class RFC3633SubnetRequest that handles acquiring the CIDR via prefix delegation. The user will pass RFC3633 as the cidr attribute in that case, so that the correct request class is instantiated. A similar mechanism can be used for address requests - for example, EUI64 and other auto-generated addresses. To enable this, an additional change needed beyond [1] is to use the request factory for validation of the cidr field rather than the API layer. [1] https://review.openstack.org/#/c/153236/25/neutron/ipam/__init__.py __ 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] [Neutron][IPv6] Prefix delegation and user facing API thoughts
On Wed, Mar 18, 2015 at 8:15 AM, Sean M. Collins s...@coreitpro.com wrote: On Wed, Mar 18, 2015 at 06:45:59AM PDT, John Davidge (jodavidg) wrote: In the IPv6 meeting yesterday you mentioned doing this with an extension rather than modifying the core API. Could you go into some detail about how you see this extension looking? The easiest, is to evaluate the REST API that is being worked on by the subnet allocation spec: http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html#rest-api-impact Since it also solves the issue of the CIDR being a required attribute in the subnet-create call. My recollection was that the subnet create for a PD subnet would use a specially configured subnet pool id for PD and no cidr. The subnet pool This was to allow both are efforts to continue with very little dependency between them but also be interoperable. It looks like it has diverged a bit from this resolution. This was a face-to-face discussion without any log. But, it looks like this made it in to the spec [1]. Carl [1] https://review.openstack.org/#/c/93054/ __ 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] [Neutron][IPv6] Prefix delegation and user facing API thoughts
Copying my response on the review below: Yes that completely makes sense Sean. In our original proposal we wanted to allow the user to initiate a subnet-create without providing a CIDR, and have an 'ipv6_pd_enabled' flag which could be set in the API call to tell Neutron that this particular subnet needs to have its CIDR defined by PD. The consensus from the community early in the Kilo development cycle was that changes to the API should be avoided if at all possible, and so it was agreed that we would use a special ::/64 CIDR for the initial implementation. In the IPv6 meeting yesterday you mentioned doing this with an extension rather than modifying the core API. Could you go into some detail about how you see this extension looking? Cheers, John On 18/03/2015 13:12, Sean M. Collins s...@coreitpro.com wrote: Hi all, I recently posted this comment in the review for https://review.openstack.org/#/c/158697/, and wanted to post it here so that people can respond. Basically, I have concerns that I raised during the spec submission process (https://review.openstack.org/#/c/93054/). I'm still not totally on board with the proposed user facing API, where they create a subnet cidr of ::/64, then later it is updated by Neutron to actually be the cidr that is delegated. My hope is to have a user facing API that would require little to no user input (since we are relying on an external system to delegate us a subnet) and Neutron would create the required constructs internally. My hope is that either the new IPAM subsystem for subnet allocations would provide this, or that a small API extension could paper over some of the sharper edges. Basically, I know we need the user to create a CIDR of ::/64 to satisfy the Neutron core API's requirement that a subnet MUST have a CIDR when creating, but I think that in the case of prefix delegation we shouldn't expose this sharp edge to the user by default. Does this make sense? -- Sean M. Collins __ 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
[openstack-dev] [Neutron][IPv6] Prefix delegation and user facing API thoughts
Hi all, I recently posted this comment in the review for https://review.openstack.org/#/c/158697/, and wanted to post it here so that people can respond. Basically, I have concerns that I raised during the spec submission process (https://review.openstack.org/#/c/93054/). I'm still not totally on board with the proposed user facing API, where they create a subnet cidr of ::/64, then later it is updated by Neutron to actually be the cidr that is delegated. My hope is to have a user facing API that would require little to no user input (since we are relying on an external system to delegate us a subnet) and Neutron would create the required constructs internally. My hope is that either the new IPAM subsystem for subnet allocations would provide this, or that a small API extension could paper over some of the sharper edges. Basically, I know we need the user to create a CIDR of ::/64 to satisfy the Neutron core API's requirement that a subnet MUST have a CIDR when creating, but I think that in the case of prefix delegation we shouldn't expose this sharp edge to the user by default. Does this make sense? -- Sean M. Collins __ 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] [Neutron][IPv6] Prefix delegation and user facing API thoughts
On Wed, Mar 18, 2015 at 06:45:59AM PDT, John Davidge (jodavidg) wrote: In the IPv6 meeting yesterday you mentioned doing this with an extension rather than modifying the core API. Could you go into some detail about how you see this extension looking? The easiest, is to evaluate the REST API that is being worked on by the subnet allocation spec: http://specs.openstack.org/openstack/neutron-specs/specs/kilo/subnet-allocation.html#rest-api-impact Since it also solves the issue of the CIDR being a required attribute in the subnet-create call. This was part of my comments when reviewing the spec, that we should rely on the API changes that the subnet allocation spec as the user facing portion of prefix delegation. Anthony Veiga and I did some preliminary sketches on what an API extension that handled prefix delegation would look like nearly a year ago ( http://lists.openstack.org/pipermail/openstack-dev/2014-March/030581.html), and I have some additional thoughts on how the REST API would behave, but at this stage of the game I think the subnet allocation REST API is a superior spec. -- Sean M. Collins __ 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
