-----Original Message----- From: Ken'ichi Ohmichi <ken1ohmi...@gmail.com> Reply: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Date: January 12, 2017 at 13:35:56 To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@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 __________________________________________________________________________ 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
