Open Stack

On Wed, Mar 8, 2017 at 9:05 AM, Mario Villaplana <mario.villaplana at gmail.com
> wrote:

> 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 agree, I think we should pin it, otherwise it's one more hump to
overcome when we do want to make a breaking change.

FWIW, nova pins (both clients) to the max the client knows about,
specifically for this reason:
https://github.com/openstack/python-openstackclient/blob/master/openstackclient/compute/client.py#L52-L57
https://github.com/openstack/python-novaclient/blob/master/novaclient/__init__.py#L23-L28


> 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. :)
>

I tend to think a spec is a bit overkill for this, but I won't deny Ruby's
request.
Ping me when it's up and I'm happy to review it ASAP.

// jim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170308/275471ee/attachment.html>