Open Stack

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> 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 review 
https://wiki.openstack.org/wiki/Governance/Approved/APIStability and the 
details of https://wiki.openstack.org/wiki/APIChangeGuidelines to make 
sure they still reflect the will of the TC and our community.

  -David
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev