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....@intel.com> wrote: > On 2017-03-06, 3:46 PM, "Mario Villaplana" <mario.villapl...@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-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
