Open Stack

On 03/21/2014 02:18 PM, Chris Behrens wrote:
>
> FWIW, I'm fine with any of the options posted. But I'm curious about 
> the precedence that reverting would create. It essentially sounds like 
> if we release a version with an API bug, the bug is no longer a bug in 
> the API and the bug becomes a bug in the documentation. The only way 
> to 'fix' the API then would be to rev it. Is that an accurate 
> representation and is that desirable? Or do we just say we take these 
> on a case-by-case basis?
>
> - Chris
It has to be on a case-by-case basis. Obviously if fixing a security bug 
required an api change we would make it. But as the eco-system around 
the OpenStack APIs continue to grow, there should be a higher and higher 
bar based on what is gained by the change. In my view, we are well past 
the point where the value of a change like this one would justify 
violating the API stability guidelines.

There was a related discussion about getting more eyes on changes that 
propose to be excepted from the API stability guidelines here 
http://lists.openstack.org/pipermail/openstack-dev/2014-January/023254.html

  -David
>
>
> On Mar 21, 2014, at 10:34 AM, David Kranz <dkranz at redhat.com 
> <mailto:dkranz at redhat.com>> wrote:
>
>> On 03/21/2014 05:04 AM, Christopher Yeoh wrote:
>>> On Thu, 20 Mar 2014 15:45:11 -0700
>>> Dan Smith <dms at danplanet.com <mailto:dms at danplanet.com>> wrote:
>>>> I know that our primary delivery mechanism is releases right now, and
>>>> so if we decide to revert before this gets into a release, that's
>>>> cool. However, I think we need to be looking at CD as a very important
>>>> use-case and I don't want to leave those folks out in the cold.
>>>>
>>> I don't want to cause issues for the CD people, but perhaps it won't be
>>> too disruptive for them (some direct feedback would be handy). The
>>> initial backwards incompatible change did not result in any bug reports
>>> coming back to us at all. If there were lots of users using it I think
>>> we could have expected some complaints as they would have had to adapt
>>> their programs to no longer manually add the flavor access (otherwise
>>> that would fail). It is of course possible that new programs written in
>>> the meantime would rely on the new behaviour.
>>>
>>> I think (please correct me if I'm wrong) the public CD clouds don't
>>> expose that part of API to their users so the fallout could be quite
>>> limited. Some opinions from those who do CD for private clouds would be
>>> very useful. I'll send an email to openstack-operators asking what
>>> people there believe the impact would be but at the moment I'm thinking
>>> that revert is the way we should go.
>>>
>>>> Could we consider a middle road? What if we made the extension
>>>> silently tolerate an add-myself operation to a flavor, (potentially
>>>> only) right after create? Yes, that's another change, but it means
>>>> that old clients (like horizon) will continue to work, and new
>>>> clients (which expect to automatically get access) will continue to
>>>> work. We can document in the release notes that we made the change to
>>>> match our docs, and that anyone that *depends* on the (admittedly
>>>> weird) behavior of the old broken extension, where a user doesn't
>>>> retain access to flavors they create, may need to tweak their client
>>>> to remove themselves after create.
>>> My concern is that we'd be digging ourselves an even deeper hole with
>>> that approach. That for some reason we don't really understand at the
>>> moment, people have programs which rely on adding flavor access to a
>>> tenant which is already on the access list being rejected rather than
>>> silently accepted. And I'm not sure its the behavior from flavor access
>>> that we actually want.
>>>
>>> But we certainly don't want to end up in the situation of trying to
>>> work out how to rollback two backwards incompatible API changes.
>>>
>>> Chris
>> Nope.  IMO we should just accept that an incompatible change was made 
>> that should not have been, revert it, and move on. I hope that saying 
>> our code base is going to support CD does not mean that any 
>> incompatible change that slips through our very limited gate cannot 
>> be reverted. October was a while back but I'm not sure what principle 
>> we would use to draw the line. I am also not sure why this is phrased 
>> as a CD vs. not issue. Are the *users* of a system that happens to be 
>> managed using CD thought to be more tolerant of their code breaking?
>>
>> Perhaps it would be a good time to 
>> reviewhttps://wiki.openstack.org/wiki/Governance/Approved/APIStabilityand 
>> the details ofhttps://wiki.openstack.org/wiki/APIChangeGuidelinesto 
>> make sure they still reflect the will of the TC and our community.
>>
>> -David
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org 
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org 
>> <mailto:OpenStack-dev at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140321/c1de63ef/attachment.html>