Open Stack

On 02/26/2018 10:55 AM, Rabi Mishra wrote:
> On Mon, Feb 26, 2018 at 3:44 PM, Monty Taylor <mordred at inaugust.com 
> <mailto:mordred at inaugust.com>> wrote:
> 
>     On 02/26/2018 09:57 AM, Akihiro Motoki wrote:
> 
>         Hi neutron and openstacksdk team,
> 
>         This mail proposes to change the first priority of neutron-related
>         python binding to OpenStack SDK rather than neutronclient python
>         bindings.
>         I think it is time to start this as OpenStack SDK became a official
>         project in Queens.
> 
> 
>     ++
> 
> 
>         [Current situations and problems]
> 
>         Network OSC commands are categorized into two parts: OSC and
>         neutronclient OSC plugin.
>         Commands implemented in OSC consumes OpenStack SDK
>         and commands implemented as neutronclient OSC plugin consumes
>         neutronclient python bindings.
>         This brings tricky situation that some features are supported
>         only in
>         OpenStack SDK and some features are supported only in neutronclient
>         python bindings.
> 
>         [Proposal]
> 
>         The proposal is to implement all neutron features in OpenStack
>         SDK as
>         the first citizen,
>         and the neutronclient OSC plugin consumes corresponding
>         OpenStack SDK APIs.
> 
>         Once this is achieved, users of OpenStack SDK users can see all
>         network related features.
> 
>         [Migration plan]
> 
>         The migration starts from Rocky (if we agree).
> 
>         New features should be supported in OpenStack SDK and
>         OSC/neutronclient OSC plugin as the first priority. If new feature
>         depends on neutronclient python bindings, it can be implemented in
>         neutornclient python bindings first and they are ported as part of
>         existing feature transition.
> 
>         Existing features only supported in neutronclient python
>         bindings are
>         ported into OpenStack SDK,
>         and neutronclient OSC plugin will consume them once they are
>         implemented in OpenStack SDK.
> 
> 
>     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.
> 
>         [FAQ]
> 
>         1. Will neutornclient python bindings be removed in future?
> 
>         Different from "neutron" CLI, as of now, there is no plan to
>         drop the
>         neutronclient python bindings.
>         Not a small number of projects consumes it, so it will be
>         maintained as-is.
>         The only change is that new features are implemented in
>         OpenStack SDK first and
>         enhancements of neutronclient python bindings will be minimum.
> 
>         2. Should projects that consume neutronclient python bindings switch
>         to OpenStack SDK?
> 
>         Necessarily not. It depends on individual projects.
>         Projects like nova that consumes small set of neutron features can
>         continue to use neutronclient python bindings.
>         Projects like horizon or heat that would like to support a wide
>         range
>         of features might be better to switch to OpenStack SDK.
> 
> 
>     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:NeutronClientPlugin code in Heat from
>     neutronclient to SDK.
> 
> 
> Yeah, this would only be possible after openstacksdk supports all 
> neutron features as mentioned in the proposal.

++

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

Maybe we start converting one thing at a time and when we find something 
sdk doesn't support we should be able to add it pretty quickly... which 
should then also wind up improving the sdk layer.

>     There's already an
>     heat.engine.clients.os.openstacksdk:OpenStackSDKPlugin plugin in
>     Heat. I started a patch to migrate senlin from senlinclient (which
>     is just a thin wrapper around sdk):
>     https://review.openstack.org/#/c/532680/
>     <https://review.openstack.org/#/c/532680/>
> 
>     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.
> 
>     Monty
> 
> 
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe:
>     OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>     <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
> 
> 
> -- 
> Regards,
> Rabi Mishra
> 
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>