<div dir="ltr">LBaaS is a little special since Octavia will have it's own API endpoint completely that they will evolve on their own. The other spun-out projects (e.g. VPNaaS) will have the API defined in neutron-lib[1].<div><br></div><div>The specific DVR issue you are referring to with roaming IPs being the target of floating IPs (I think that's what you're referring to) is something I'm planning to address in Pike with the help of other DVR contributors because floating IP translations for unbound addresses blocks various other use cases. <br></div><div><br></div><div>1. <a href="https://github.com/openstack/neutron-lib/blob/master/api-ref/source/v2/vpnaas.inc">https://github.com/openstack/neutron-lib/blob/master/api-ref/source/v2/vpnaas.inc</a></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 25, 2017 at 6:40 AM, Hayes, Graham <span dir="ltr"><<a href="mailto:graham.hayes@hpe.com" target="_blank">graham.hayes@hpe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 25/01/2017 01:08, Kevin Benton wrote:<br>
>>I would really like us to discuss this issue head-on and see what is<br>
> missing in Neutron APIs and what would take to make them extensible so<br>
> that vendors do not run around trying to figure out alternative<br>
> solutions....<br>
><br>
> The Neutron API is already very extensible and that's problematic. Right<br>
> now a vendor can write an out-of-tree service plugin or driver that adds<br>
> arbitrary fields and endpoints to the API that results in whatever<br>
> behavior they want. This is great for vendors because they can directly<br>
> expose features without having to make them vendor agnostic. However,<br>
> it's terrible for operators because it leads to lock-in and terrible for<br>
> the users because it leads to cross-cloud compatibility issues.<br>
><br>
> For a concrete example of what I mean, take a look at this extension<br>
> here: [1]. This is directly exposing vendor-specific things onto Neutron<br>
> network API payloads. Nobody can build any tooling that depends on those<br>
> fields without being locked into a specific vendor.<br>
><br>
> So what I would like to encourage is bringing API extension work into<br>
> Neutron-lib where we can ensure that the relevant abstractions are in<br>
> place and it's not just a pass-through to a bunch of vendor-specific<br>
> features. I would rather relax our constraint around requiring a<br>
> reference implementation for new extensions in neutron-lib than continue<br>
> to encourage developers to do expose whatever they want with the the<br>
> existing extension framework.<br>
><br>
> So I'm all for developing new APIs *as a community* to enable NFV use<br>
> cases not supported by the current APIs. However, I don't want to<br>
> encourage or make it easier for vendors to just build arbitrary<br>
> extensions on top of Neutron that expose backend details.<br>
><br>
> In my view, Neutron should provide a unified API for networking across<br>
> OpenStack clouds, not a platform for writing deployment-specific<br>
> networking APIs.<br>
<br>
</div></div>How does this tie in with the removal of some of the networking *aaS<br>
projects from the stadium? I know LBaaS is doing a shim API layer in<br>
the short term, but long term that will have to move to a separate API.<br>
<br>
How do you think this will impact inter service bugs (e.g. Octavia HA +<br>
Neutron DVR issues that have been around for cycles)<br>
<span class=""><br>
><br>
> 1. <a href="https://github.com/Juniper/contrail-neutron-plugin/blob/19ad4bcee4c1ff3bf2d2093e14727866412a694a/neutron_plugin_contrail/extensions/contrail.py#L9-L22" rel="noreferrer" target="_blank">https://github.com/Juniper/<wbr>contrail-neutron-plugin/blob/<wbr>19ad4bcee4c1ff3bf2d2093e147278<wbr>66412a694a/neutron_plugin_<wbr>contrail/extensions/contrail.<wbr>py#L9-L22</a><br>
><br>
> Cheers,<br>
> Kevin Benton<br>
><br>
> On Tue, Jan 24, 2017 at 3:42 PM, Sukhdev Kapur <<a href="mailto:sukhdevkapur@gmail.com">sukhdevkapur@gmail.com</a><br>
</span><div><div class="h5">> <mailto:<a href="mailto:sukhdevkapur@gmail.com">sukhdevkapur@gmail.com</a><wbr>>> wrote:<br>
><br>
><br>
> Ihar and Kevin,<br>
><br>
> As our potential future PTLs, I would like to draw your attention to<br>
> one of the critical issue regarding Neutron as "the" networking<br>
> service in OpenStack.<br>
><br>
> I keep hearing off and on that Neutron is not flexible to address<br>
> many networking use cases and hence a new (or additional) networking<br>
> project is needed. For example, to address the use cases around NFV<br>
> (rigid resource inter-dependencies). Another one keeps popping up<br>
> is that it is very hard/difficult to add/enhance Neutron API -<br>
> hence, I picked this one goal called out in Ihar's candidacy.<br>
><br>
> I would really like us to discuss this issue head-on and see what is<br>
> missing in Neutron APIs and what would take to make them extensible<br>
> so that vendors do not run around trying to figure out alternative<br>
> solutions....<br>
><br>
> cheers..<br>
> -Sukhdev<br>
><br>
><br>
><br>
><br>
> * Explore alternative ways to evolve Neutron API. Piling up<br>
> extensions and allowing third parties to completely change core<br>
> resource behaviour is not ideal, and now that api-ref and API<br>
> consolidation effort in neutron-lib are closer to completion, we may<br>
> have better answers to outstanding questions than during previous<br>
> attempts to crack the nut. I would like to restart the<br>
> discussion some<br>
> time during Pike.<br>
><br>
><br>
><br>
><br>
><br>
><br>
> Thanks for attention,<br>
> Ihar<br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
</div></div>> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:<wbr>unsubscribe</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a>><br>
<span class="">><br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
</span>> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:<wbr>unsubscribe</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<div class="HOEnZb"><div class="h5">> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a>><br>
><br>
><br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br></div>