Re: [openstack-dev] [ironic][openstackclient] deprecation process

2016-05-16 Thread Loo, Ruby 
Thanks Steve, that’s exactly what I wanted to know!

—ruby

From: Steve Martinelli <s.martine...@gmail.com<mailto:s.martine...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, May 12, 2016 at 12:05 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [ironic][openstackclient] deprecation process

I thought we had this written down somewhere but I can't find it. The OSC 
deprecation process is two major releases. So if something was deprecated in L, 
it is removed in N. This goes for optional parameters being renamed / dropped, 
or commands being dropped / renamed.

If an optional parameter is being deprecated (say --tenant in favor of 
--project), then we usually add a mutually exclusive group for these, and force 
the user to only pick one, log a deprecation message if they pick the wrong 
one, and suppress the help text of the old option. See [1] for an example

If a command is being deprecated it's a bit easier, just log a deprecation 
message and remove it. If it is being renamed then you can also have it 
subclass the new command.

As always, the deprecation message should indicate which command / option to 
use.

[1] 
https://github.com/openstack/python-openstackclient/blob/b4c3adbd308e65679489c4c64680cbe0324f4bc7/openstackclient/volume/v1/volume.py#L53-L63

On Thu, May 12, 2016 at 9:46 AM, Loo, Ruby 
<ruby@intel.com<mailto:ruby@intel.com>> wrote:
Hi OpenStackClient folks,

Ironic is following the standard deprecation process [1]. We added an OSC 
plugin and realized that we didn’t get the commands quite right. This patch [2] 
adds the right commands and deprecates the wrong ones. My question is what the 
deprecation process might be. Since it is a plugin to OSC, should it follow 
OSC’s deprecation process and if so, what might that process be? Or since the 
commands are related to ironic, should it follow ironic’s deprecation process? 
In particular, I wanted to know how long should/must we support those 
deprecated commands.

For the user’s sake, it seems like it would make sense that all OSC (plugin or 
not, does the user know the difference?) commands follow the same deprecation 
policy.

I took a quick look and didn’t see anything documented about this, so I might 
have missed it.

What sez you?

—ruby

[1] 
https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html
[2] https://review.openstack.org/#/c/284160


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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] [ironic][openstackclient] deprecation process

2016-05-12 Thread Steve Martinelli 
I thought we had this written down somewhere but I can't find it. The OSC
deprecation process is two major releases. So if something was deprecated
in L, it is removed in N. This goes for optional parameters being renamed /
dropped, or commands being dropped / renamed.

If an optional parameter is being deprecated (say --tenant in favor of
--project), then we usually add a mutually exclusive group for these, and
force the user to only pick one, log a deprecation message if they pick the
wrong one, and suppress the help text of the old option. See [1] for an
example

If a command is being deprecated it's a bit easier, just log a deprecation
message and remove it. If it is being renamed then you can also have it
subclass the new command.

As always, the deprecation message should indicate which command / option
to use.

[1]
https://github.com/openstack/python-openstackclient/blob/b4c3adbd308e65679489c4c64680cbe0324f4bc7/openstackclient/volume/v1/volume.py#L53-L63

On Thu, May 12, 2016 at 9:46 AM, Loo, Ruby  wrote:

> Hi OpenStackClient folks,
>
> Ironic is following the standard deprecation process [1]. We added an OSC
> plugin and realized that we didn’t get the commands quite right. This patch
> [2] adds the right commands and deprecates the wrong ones. My question is
> what the deprecation process might be. Since it is a plugin to OSC, should
> it follow OSC’s deprecation process and if so, what might that process be?
> Or since the commands are related to ironic, should it follow ironic’s
> deprecation process? In particular, I wanted to know how long should/must
> we support those deprecated commands.
>
> For the user’s sake, it seems like it would make sense that all OSC
> (plugin or not, does the user know the difference?) commands follow the
> same deprecation policy.
>
> I took a quick look and didn’t see anything documented about this, so I
> might have missed it.
>
> What sez you?
>
> —ruby
>
> [1]
> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html
> [2] https://review.openstack.org/#/c/284160
>
>
> __
> 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

[openstack-dev] [ironic][openstackclient] deprecation process

2016-05-12 Thread Loo, Ruby 
Hi OpenStackClient folks,

Ironic is following the standard deprecation process [1]. We added an OSC 
plugin and realized that we didn’t get the commands quite right. This patch [2] 
adds the right commands and deprecates the wrong ones. My question is what the 
deprecation process might be. Since it is a plugin to OSC, should it follow 
OSC’s deprecation process and if so, what might that process be? Or since the 
commands are related to ironic, should it follow ironic’s deprecation process? 
In particular, I wanted to know how long should/must we support those 
deprecated commands.

For the user’s sake, it seems like it would make sense that all OSC (plugin or 
not, does the user know the difference?) commands follow the same deprecation 
policy.

I took a quick look and didn’t see anything documented about this, so I might 
have missed it.

What sez you?

—ruby

[1] 
https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html
[2] https://review.openstack.org/#/c/284160

__
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