<div dir="ltr">On Mon, Feb 26, 2018 at 3:44 PM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02/26/2018 09:57 AM, Akihiro Motoki wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi neutron and openstacksdk team,<br>
<br>
This mail proposes to change the first priority of neutron-related<br>
python binding to OpenStack SDK rather than neutronclient python<br>
bindings.<br>
I think it is time to start this as OpenStack SDK became a official<br>
project in Queens.<br>
</blockquote>
<br></span>
++<div><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[Current situations and problems]<br>
<br>
Network OSC commands are categorized into two parts: OSC and<br>
neutronclient OSC plugin.<br>
Commands implemented in OSC consumes OpenStack SDK<br>
and commands implemented as neutronclient OSC plugin consumes<br>
neutronclient python bindings.<br>
This brings tricky situation that some features are supported only in<br>
OpenStack SDK and some features are supported only in neutronclient<br>
python bindings.<br>
<br>
[Proposal]<br>
<br>
The proposal is to implement all neutron features in OpenStack SDK as<br>
the first citizen,<br>
and the neutronclient OSC plugin consumes corresponding OpenStack SDK APIs.<br>
<br>
Once this is achieved, users of OpenStack SDK users can see all<br>
network related features.<br>
<br>
[Migration plan]<br>
<br>
The migration starts from Rocky (if we agree).<br>
<br>
New features should be supported in OpenStack SDK and<br>
OSC/neutronclient OSC plugin as the first priority. If new feature<br>
depends on neutronclient python bindings, it can be implemented in<br>
neutornclient python bindings first and they are ported as part of<br>
existing feature transition.<br>
<br>
Existing features only supported in neutronclient python bindings are<br>
ported into OpenStack SDK,<br>
and neutronclient OSC plugin will consume them once they are<br>
implemented in OpenStack SDK.<br>
</blockquote>
<br></div></div>
I think this is a great idea. We've got a bunch of good functional/integrations tests in the sdk gate as well that we can start running on neutron patches so that we don't lose cross-gating.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[FAQ]<br>
<br>
1. Will neutornclient python bindings be removed in future?<br>
<br>
Different from "neutron" CLI, as of now, there is no plan to drop the<br>
neutronclient python bindings.<br>
Not a small number of projects consumes it, so it will be maintained as-is.<br>
The only change is that new features are implemented in OpenStack SDK first and<br>
enhancements of neutronclient python bindings will be minimum.<br>
<br>
2. Should projects that consume neutronclient python bindings switch<br>
to OpenStack SDK?<br>
<br>
Necessarily not. It depends on individual projects.<br>
Projects like nova that consumes small set of neutron features can<br>
continue to use neutronclient python bindings.<br>
Projects like horizon or heat that would like to support a wide range<br>
of features might be better to switch to OpenStack SDK.<br>
</blockquote>
<br></span>
We've got a PTG session with Heat to discuss potential wider-use of SDK (and have been meaning to reach our to horizon as well) Perhaps a good first step would be to migrate the heat.engine.clients.os.neutron<wbr>:NeutronClientPlugin code in Heat from neutronclient to SDK.</blockquote><div><br></div><div>Yeah, this would only be possible after openstacksdk supports all neutron features as mentioned in the proposal.<br><br></div><div>Note: We had initially added the OpenStackSDKPlugin in heat to support neutron segments and were thinking of doing all new neutron stuff with openstacksdk. However, we soon realised that it's not possible when implementing neutron trunk support and had to drop the idea. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> There's already an heat.engine.clients.os.opensta<wbr>cksdk:OpenStackSDKPlugin plugin in Heat. I started a patch to migrate senlin from senlinclient (which is just a thin wrapper around sdk): <a href="https://review.openstack.org/#/c/532680/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/532680/</a><br>
<br>
For those of you who are at the PTG, I'll be giving an update on SDK after lunch on Wednesday. I'd also be more than happy to come chat about this more in the neutron room if that's useful to anybody.<span class="HOEnZb"><font color="#888888"><br>
<br>
Monty</font></span><div class="HOEnZb"><div class="h5"><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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Regards,</div>Rabi Mishra<div><br></div></div></div></div></div>
</div></div>