Re: [openstack-dev] [neutron][sdk] Proposal to migrate neutronclient python bindings to OpenStack SDK

[Gary Kotton]

Thanks for the clarification. 

On 2/28/18, 3:22 PM, "Akihiro Motoki"  wrote:

Hi Gary,

You are talking about vender extension support in OSC, but this is
about python bindings.
I believe this is another topic. Commands implemented in OSC repo
already consumes OpenStack SDK, so the proposed change just increases
the number of python bindings supported in SDK.

Regarding the topic of third-party extension support after OSC
transition, possible options in my mind is to keep "neutron" CLI, or
to add some command which handle general network resources as
neutronclient OSC plugin. It is a compromise considering the current
neutron API. Note that OpenStackSDK proxy object supports
keystoneauth.Adapter, so even after migrating to OpenStackSDK, this
does not block arbitrary attributes immediately even though they are
things we would like to avoid. If you and/or boden are interested in
implementing so-called "generic network resource" commands in Neutron
OSC plugin, I can help the effort (as it speed up neutron CLI
deprecation).

Akihiro

2018-02-26 13:39 GMT+00:00 Gary Kotton :
> One of the concerns here is that the openstack client does not enable one 
to configure extensions that are not part of the core reference architecture. 
So any external third part that tries to have any etension added will not be 
able to leverage the openstack client. This is a major pain point.
>
>
> On 2/26/18, 1:26 PM, "Monty Taylor"  wrote:
>
> On 02/26/2018 10:55 AM, Rabi Mishra wrote:
> > On Mon, Feb 26, 2018 at 3:44 PM, Monty Taylor  > > 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 

Re: [openstack-dev] [neutron][sdk] Proposal to migrate neutronclient python bindings to OpenStack SDK

[Akihiro Motoki]

Hi Gary,

You are talking about vender extension support in OSC, but this is
about python bindings.
I believe this is another topic. Commands implemented in OSC repo
already consumes OpenStack SDK, so the proposed change just increases
the number of python bindings supported in SDK.

Regarding the topic of third-party extension support after OSC
transition, possible options in my mind is to keep "neutron" CLI, or
to add some command which handle general network resources as
neutronclient OSC plugin. It is a compromise considering the current
neutron API. Note that OpenStackSDK proxy object supports
keystoneauth.Adapter, so even after migrating to OpenStackSDK, this
does not block arbitrary attributes immediately even though they are
things we would like to avoid. If you and/or boden are interested in
implementing so-called "generic network resource" commands in Neutron
OSC plugin, I can help the effort (as it speed up neutron CLI
deprecation).

Akihiro

2018-02-26 13:39 GMT+00:00 Gary Kotton :
> One of the concerns here is that the openstack client does not enable one to 
> configure extensions that are not part of the core reference architecture. So 
> any external third part that tries to have any etension added will not be 
> able to leverage the openstack client. This is a major pain point.
>
>
> On 2/26/18, 1:26 PM, "Monty Taylor"  wrote:
>
> On 02/26/2018 10:55 AM, Rabi Mishra wrote:
> > On Mon, Feb 26, 2018 at 3:44 PM, Monty Taylor  > > 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 

Re: [openstack-dev] [neutron][sdk] Proposal to migrate neutronclient python bindings to OpenStack SDK

[Gary Kotton]

One of the concerns here is that the openstack client does not enable one to 
configure extensions that are not part of the core reference architecture. So 
any external third part that tries to have any etension added will not be able 
to leverage the openstack client. This is a major pain point.


On 2/26/18, 1:26 PM, "Monty Taylor"  wrote:

On 02/26/2018 10:55 AM, Rabi Mishra wrote:
> On Mon, Feb 26, 2018 at 3:44 PM, Monty Taylor  > 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.

Re: [openstack-dev] [neutron][sdk] Proposal to migrate neutronclient python bindings to OpenStack SDK

[Monty Taylor]

On 02/26/2018 10:55 AM, Rabi Mishra wrote:
On Mon, Feb 26, 2018 at 3:44 PM, Monty Taylor > 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/


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-requ...@lists.openstack.org?subject:unsubscribe

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





--
Regards,
Rabi Mishra

Re: [openstack-dev] [neutron][sdk] Proposal to migrate neutronclient python bindings to OpenStack SDK

[Rabi Mishra]

On Mon, Feb 26, 2018 at 3:44 PM, Monty Taylor  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.


> 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/
>
> 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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards,
Rabi Mishra
__
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][sdk] Proposal to migrate neutronclient python bindings to OpenStack SDK

[Sławomir Kapłoński]

I also agree that it is good idea and I would be very happy to help with such 
migration :)

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl

> Wiadomość napisana przez Monty Taylor  w dniu 
> 26.02.2018, o godz. 11:14:
> 
> 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. 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/
> 
> 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-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][sdk] Proposal to migrate neutronclient python bindings to OpenStack SDK

[Monty Taylor]

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


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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron][sdk] Proposal to migrate neutronclient python bindings to OpenStack SDK

[Akihiro Motoki]

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.

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


3. 

Thanks,
Akihiro

__
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