Open Stack

We want to deprecate ironic CLI soon, but I would prefer if that were
discussed on a separate thread if possible, aside from concerns about
versioning in ironic CLI. Feature parity should exist in Pike, then we
can issue a warning in Queens and deprecate the cycle after. More
information is on L56:
https://etherpad.openstack.org/p/ironic-pike-ptg-operations

I'm a bit torn on whether to use the API version coded in the OSC
plugin or not. On one hand, it'd be good to be able to test out new
features as soon as they're available. On the other hand, it's
possible that the client won't know how to parse certain items after a
microversion bump. I think I prefer using the hard-coded version to
avoid breakage, but we'd have to be disciplined about updating the
client when the API version is bumped (if needed). Opinions on this
are welcome. In either case, I think the deprecation warning could
land without specifying that.

I'll certainly make an RFE when I update the patch later this week,
great suggestion.

I can make a spec, but it might be mostly empty except for the client
impact section. Also, this is a < 40 line change. :)

Mario

On Tue, Mar 7, 2017 at 10:59 AM, Loo, Ruby <ruby.loo at intel.com> wrote:
> On 2017-03-06, 3:46 PM, "Mario Villaplana" <mario.villaplana at gmail.com> wrote:
>
>     Hi ironic,
>
>     At the PTG, an issue regarding the default version of the ironic API
>     used in our python-openstackclient plugin was discussed. [0] In short,
>     the issue is that we default to a very old API version when the user
>     doesn't otherwise specify it. This limits discoverability of new
>     features and makes the client more difficult to use for deployments
>     running the latest version of the code.
>
>     We came to the following consensus:
>
>     1. For a deprecation period, we should log a warning whenever the user
>     doesn't specify an API version, informing them of this change.
>
>     2. After the deprecation period:
>
>     a) OSC baremetal plugin will default to the latest available version
>
> I think OSC and ironic CLI have the same behaviour -- are we only interested in OSC or are we interested in both, except that we also want to at some point soon perhaps, deprecate ironic CLI?
>
> Also, by 'latest available version', the OSC plugin knows (or thinks it knows) what the latest version is [1]. Will you be using that, or 'latest'?
>
>     b) Specifying just macroversion will default to latest microversion
>     within that macroversion (example: --os-baremetal-api-version=1 would
>     default to 1.31 if 1.31 is the last microversion with 1 macroversion,
>     even if we have API 2.2 supported)
>
>     I have a patch up for review with the deprecation warning:
>     https://review.openstack.org/442153
>
> Do you have an RFE? I'd like a spec for this too please.
>
>     Please comment on that patch with any concerns.
>
>     We also still have yet to decide what a suitable deprecation period is
>     for this change, as far as I'm aware. Please respond to this email
>     with any suggestions on the deprecation period.
>
>     Thanks,
>     Mario
>
>
>     [0] https://etherpad.openstack.org/p/ironic-pike-ptg-operations L30
>
> Thank YOU!
>
> --ruby
>
> [1] https://github.com/openstack/python-ironicclient/blob/f242c6af3b295051019aeabb4ec7cf82eb085874/ironicclient/osc/plugin.py#L29
>
> __________________________________________________________________________
> 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