Open Stack

-----Original Message-----
From: Ken'ichi Ohmichi <ken1ohmichi at gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev at lists.openstack.org>
Date: January 12, 2017 at 13:35:56
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [glance][tempest][api] community images,
tempest tests, and API stability

> 2017-01-12 5:47 GMT-08:00 Brian Rosmaita :
> > The issue is that we are proposing to introduce an incompatible change
> > in order to address an incoherence with image visibility semantics. We
> > have acknowledged that this is a breaking change, but the impact of the
> > change is mitigated by the way that the default visibility value is
> > assigned in Ocata.
> >
> > As I've documented earlier in the thread, we have discussed this change
> > with the wider community and the API Working Group, and they are OK with it.
> >
> > The current tempest test has done its duty and identified an
> > incompatibility in the Ocata code. We acknowledge that and salute you.
> > On balance, however, this change will be better for users (and as I've
> > documented earlier in the thread, we've minimized the impact of the
> > change), and we want to make it anyway.
>
> It is difficult to expect the impact of API change is small by us as developers.

We're not claiming it is small. We have done our best to minimize the
impact though.

> For example, if there could be some APPs which list images of both
> private and shared by depending on
> https://bugs.launchpad.net/glance/+bug/1394299 , the APPs will be
> broken after fixing it.
> Nova team faced such situation we expected the impact of the change
> was small but horizon was broken, then we reverted the change in the
> same dev cycle.

We really wanted to include this in our last beta release but the
Tempest test we're talking about right now prevented exactly that. We
might have been able to garner more information from users that way
but alas, we likely won't have time for users to adopt the changes,
provide us feedback, *and* give us time to revert if it does end up
being as disruptive as some are claiming it will be. (Honestly, I
think it'll probably end up being somewhere between where Brian and
others think it will be and where the QA team is claiming it will be.)

> Then Nova has now API microversions mechanism to avoid impacting to
> the existing APPs.

Right. Microversions do sometimes make changes like this better. That
said, microversioning would probably cause yet *more* confusion around
this change than a hard break would and would likely further introduce
security issues. A microversioned API here would (probably) map
"shared" and "private" in what we're proposing to "private" in what
already exists. That means someone continuing with the old version
could add members to a private image and there would *need* to be an
implicit conversion on the new side. This means someone could create
an image as "private" in our new version, switch to the old and
*force* it to be shared. That's all kinds of awful.

Microversions are great. But they're not a panacea. They would not
have helped us had we already had them. I would like Glance to add
them, but there's a vocal minority among our team that's opposed.

Moving past the microversioning conversation (that we've had far too
many times to date), it sounds like the tempest project still sees
itself as a sort of wiser and older sibling to other projects. Other
projects breaking their APIs (intentionally, to improve the user
experience) are then treated as if they're children and talked down
to, in each email on a topic. That's probably not at all the team's
intention, but that is absolutely how it feels on this side of the
conversation. (And as a reminder, intentions don't magically fix
things.) I'm surprised by this behaviour. It's not at all what I
expected from another project in OpenStack. I understand the QA team
feels as if it is defending some idealized user, but the reality is
that as of the last User Survey, *at least* 40% of users are *still*
using Kilo. If and when they upgrade, they'll be encountering far more
disruptive changes than tempest can prevent. Most are internal
implementation details that will require a whole lot more work to fix
for large clouds than fixing some API interactions.

In short, the Glance team is ready, willing, and able to own the
responsibility for any breakage this causes users and any
interoperability problems this will pose. We'd really appreciate
cooperation on this.

And besides "No one uses Glance" [ref:
http://lists.openstack.org/pipermail/openstack-dev/2013-February/005758.html]
;)

--
Ian Cordasco