On Fri, Mar 21, 2014 at 2:04 AM, Christopher Yeoh <[email protected]> wrote:
> On Thu, 20 Mar 2014 15:45:11 -0700 > Dan Smith <[email protected]> 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. > > I agree this sounds like we are just digging the hole deeper. > 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 > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
