Re: [openstack-dev] [python-openstackclient][python-openstacksdk][neutron][nova] supporting resource extensions with our CLI

2017-08-08 Thread Akihiro Motoki 
2017-08-08 23:12 GMT+09:00 Akihiro Motoki :
> 2017-08-08 22:41 GMT+09:00 Boden Russell :
>> On 8/7/17 10:39 PM, Clint Byrum wrote:
>>> If the thing you're doing doesn't fit in the mainline API, then what
>>> you're doing is making a new API. Extensions just bypass the important
>>> part where that API gets designed and thought through.
>>
>> Irrespective of opinions as to if API extensions are good or not, the
>> fact of the matter is we support them in neutron today and as a result
>> we have users that rely on them as well as the ability to interface
>> (CLI) with such extensions via python-neutronclient. That said, I think
>> this concern has been heard [1] and we will work to address it
>> short-to-mid term.
>
> I totally agree with other comments that all API features should be 
> upstreamed.
>
> Replying to Boden's question on the short-term solution.
> If you need CLI support, you can implement OSC plugin to support your
> API extensions
> rather than extending OSC or OSC plugin provided by python-neutronclient.
> If you need SDK support, you can provide your own python bindings
> (perhaps it will be most stable)
> or continue to use the python-neutronclient CLI extension mechanism
> (which extends methods
> based on "neutronclient.extension" entry points.
>
> Does it answer to you, Boden?

My above reply does not answer the original question.
The subject of the thread says "resource extension" but this is
actually on attribute extension.
My reply applies to 'resource' extension but does not apply to
'attribute extension'

>
> Akihiro
>
>> As to neutron's longer-term goals W/R/T API extensions; I can't speak to
>> that.
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2017-August/120759.html
>>
>> __
>> 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] [python-openstackclient][python-openstacksdk][neutron][nova] supporting resource extensions with our CLI

2017-08-08 Thread Akihiro Motoki 
2017-08-08 22:41 GMT+09:00 Boden Russell :
> On 8/7/17 10:39 PM, Clint Byrum wrote:
>> If the thing you're doing doesn't fit in the mainline API, then what
>> you're doing is making a new API. Extensions just bypass the important
>> part where that API gets designed and thought through.
>
> Irrespective of opinions as to if API extensions are good or not, the
> fact of the matter is we support them in neutron today and as a result
> we have users that rely on them as well as the ability to interface
> (CLI) with such extensions via python-neutronclient. That said, I think
> this concern has been heard [1] and we will work to address it
> short-to-mid term.

I totally agree with other comments that all API features should be upstreamed.

Replying to Boden's question on the short-term solution.
If you need CLI support, you can implement OSC plugin to support your
API extensions
rather than extending OSC or OSC plugin provided by python-neutronclient.
If you need SDK support, you can provide your own python bindings
(perhaps it will be most stable)
or continue to use the python-neutronclient CLI extension mechanism
(which extends methods
based on "neutronclient.extension" entry points.

Does it answer to you, Boden?

Akihiro

> As to neutron's longer-term goals W/R/T API extensions; I can't speak to
> that.
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2017-August/120759.html
>
> __
> 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] [python-openstackclient][python-openstacksdk][neutron][nova] supporting resource extensions with our CLI

2017-08-08 Thread Boden Russell 
On 8/7/17 10:39 PM, Clint Byrum wrote:
> If the thing you're doing doesn't fit in the mainline API, then what
> you're doing is making a new API. Extensions just bypass the important
> part where that API gets designed and thought through.

Irrespective of opinions as to if API extensions are good or not, the
fact of the matter is we support them in neutron today and as a result
we have users that rely on them as well as the ability to interface
(CLI) with such extensions via python-neutronclient. That said, I think
this concern has been heard [1] and we will work to address it
short-to-mid term.

As to neutron's longer-term goals W/R/T API extensions; I can't speak to
that.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/120759.html

__
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] [python-openstackclient][python-openstacksdk][neutron][nova] supporting resource extensions with our CLI

2017-08-08 Thread Jay Pipes 

On 08/08/2017 12:39 AM, Clint Byrum wrote:

Excerpts from Matt Riedemann's message of 2017-08-07 14:33:22 -0500:

There is nothing like this for Nova so I'm not sure why Nova should be
involved here. We dropped all support for extending the API via
stevedore extension loading in Pike [1]. The virt drivers don't extend
the REST API either.

[1] https://blueprints.launchpad.net/nova/+spec/api-no-more-extensions-pike



And there was much rejoicing.

If the thing you're doing doesn't fit in the mainline API, then what
you're doing is making a new API. Extensions just bypass the important
part where that API gets designed and thought through.


100 times this.

-jay

__
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] [python-openstackclient][python-openstacksdk][neutron][nova] supporting resource extensions with our CLI

2017-08-07 Thread Clint Byrum 
Excerpts from Matt Riedemann's message of 2017-08-07 14:33:22 -0500:
> On 8/3/2017 1:39 PM, Boden Russell wrote:
> > I think we have a gap in our OSC CLI for non-stadium plugin/driver
> > projects (neutron plugin projects, nova driver projects) that implement
> > RESTful resource API attribute extensions.
> > 
> > For details, go directly to [1].
> > For a summary read on...
> > 
> > 
> > For OpenStack APIs that support extensions (ex [2]), the classic
> > python-client CLIs worked "out of the box" for extensions
> > adding attributes to existing RESTful resources.
> > 
> > For example, your project has a neutron plugin that adds a 'my_bool'
> > boolean attribute to 'network' resources that can be set via POST/PUT
> > and is returned with GET. This just works with the python-neutronclient
> > CLI without any client-side code changes.
> > 
> > 
> > However, with OSC resource attributes must be added directly/statically
> > to the sdk's resource and then consumed in the client; the support does
> > not come "for free" in the CLI. While this is fine for stadium projects
> > (they can contribute directly to the sdk/client), non-stadium projects
> > have no viable option to plugin/extend the CLI today for this type of
> > API extension mechanism.
> > 
> > With the phasing out of the python clients, a number of our users will
> > be left without a CLI to interface with these extensions.
> > 
> > I'd like to try and close this gap in Queens and welcome discussion in [1].
> > 
> > Thanks
> > 
> > 
> > [1] https://bugs.launchpad.net/python-openstacksdk/+bug/1705755
> > [2] https://wiki.openstack.org/wiki/NeutronDevelopment#API_Extensions
> > 
> > __
> > 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
> > 
> 
> There is nothing like this for Nova so I'm not sure why Nova should be 
> involved here. We dropped all support for extending the API via 
> stevedore extension loading in Pike [1]. The virt drivers don't extend 
> the REST API either.
> 
> [1] https://blueprints.launchpad.net/nova/+spec/api-no-more-extensions-pike
> 

And there was much rejoicing.

If the thing you're doing doesn't fit in the mainline API, then what
you're doing is making a new API. Extensions just bypass the important
part where that API gets designed and thought through.

__
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] [python-openstackclient][python-openstacksdk][neutron][nova] supporting resource extensions with our CLI

2017-08-07 Thread Matt Riedemann 

On 8/3/2017 1:39 PM, Boden Russell wrote:

I think we have a gap in our OSC CLI for non-stadium plugin/driver
projects (neutron plugin projects, nova driver projects) that implement
RESTful resource API attribute extensions.

For details, go directly to [1].
For a summary read on...


For OpenStack APIs that support extensions (ex [2]), the classic
python-client CLIs worked "out of the box" for extensions
adding attributes to existing RESTful resources.

For example, your project has a neutron plugin that adds a 'my_bool'
boolean attribute to 'network' resources that can be set via POST/PUT
and is returned with GET. This just works with the python-neutronclient
CLI without any client-side code changes.


However, with OSC resource attributes must be added directly/statically
to the sdk's resource and then consumed in the client; the support does
not come "for free" in the CLI. While this is fine for stadium projects
(they can contribute directly to the sdk/client), non-stadium projects
have no viable option to plugin/extend the CLI today for this type of
API extension mechanism.

With the phasing out of the python clients, a number of our users will
be left without a CLI to interface with these extensions.

I'd like to try and close this gap in Queens and welcome discussion in [1].

Thanks


[1] https://bugs.launchpad.net/python-openstacksdk/+bug/1705755
[2] https://wiki.openstack.org/wiki/NeutronDevelopment#API_Extensions

__
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



There is nothing like this for Nova so I'm not sure why Nova should be 
involved here. We dropped all support for extending the API via 
stevedore extension loading in Pike [1]. The virt drivers don't extend 
the REST API either.


[1] https://blueprints.launchpad.net/nova/+spec/api-no-more-extensions-pike

--

Thanks,

Matt

__
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] [python-openstackclient][python-openstacksdk][neutron][nova] supporting resource extensions with our CLI

2017-08-03 Thread Boden Russell 
I think we have a gap in our OSC CLI for non-stadium plugin/driver
projects (neutron plugin projects, nova driver projects) that implement
RESTful resource API attribute extensions.

For details, go directly to [1].
For a summary read on...


For OpenStack APIs that support extensions (ex [2]), the classic
python-client CLIs worked "out of the box" for extensions
adding attributes to existing RESTful resources.

For example, your project has a neutron plugin that adds a 'my_bool'
boolean attribute to 'network' resources that can be set via POST/PUT
and is returned with GET. This just works with the python-neutronclient
CLI without any client-side code changes.


However, with OSC resource attributes must be added directly/statically
to the sdk's resource and then consumed in the client; the support does
not come "for free" in the CLI. While this is fine for stadium projects
(they can contribute directly to the sdk/client), non-stadium projects
have no viable option to plugin/extend the CLI today for this type of
API extension mechanism.

With the phasing out of the python clients, a number of our users will
be left without a CLI to interface with these extensions.

I'd like to try and close this gap in Queens and welcome discussion in [1].

Thanks


[1] https://bugs.launchpad.net/python-openstacksdk/+bug/1705755
[2] https://wiki.openstack.org/wiki/NeutronDevelopment#API_Extensions

__
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