<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 21, 2014 at 2:04 AM, Christopher Yeoh <span dir="ltr"><<a href="mailto:cbkyeoh@gmail.com" target="_blank">cbkyeoh@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Thu, 20 Mar 2014 15:45:11 -0700<br>
Dan Smith <<a href="mailto:dms@danplanet.com">dms@danplanet.com</a>> wrote:<br>
><br>
> I know that our primary delivery mechanism is releases right now, and<br>
> so if we decide to revert before this gets into a release, that's<br>
> cool. However, I think we need to be looking at CD as a very important<br>
> use-case and I don't want to leave those folks out in the cold.<br>
><br>
<br>
</div>I don't want to cause issues for the CD people, but perhaps it won't be<br>
too disruptive for them (some direct feedback would be handy). The<br>
initial backwards incompatible change did not result in any bug reports<br>
coming back to us at all. If there were lots of users using it I think<br>
we could have expected some complaints as they would have had to adapt<br>
their programs to no longer manually add the flavor access (otherwise<br>
that would fail). It is of course possible that new programs written in<br>
the meantime would rely on the new behaviour.<br>
<br>
I think (please correct me if I'm wrong) the public CD clouds don't<br>
expose that part of API to their users so the fallout could be quite<br>
limited. Some opinions from those who do CD for private clouds would be<br>
very useful. I'll send an email to openstack-operators asking what<br>
people there believe the impact would be but at the moment I'm thinking<br>
that revert is the way we should go.<br>
<div class=""><br>
> Could we consider a middle road? What if we made the extension<br>
> silently tolerate an add-myself operation to a flavor, (potentially<br>
> only) right after create? Yes, that's another change, but it means<br>
> that old clients (like horizon) will continue to work, and new<br>
> clients (which expect to automatically get access) will continue to<br>
> work. We can document in the release notes that we made the change to<br>
> match our docs, and that anyone that *depends* on the (admittedly<br>
> weird) behavior of the old broken extension, where a user doesn't<br>
> retain access to flavors they create, may need to tweak their client<br>
> to remove themselves after create. </div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<br>
</div>My concern is that we'd be digging ourselves an even deeper hole with<br>
that approach. That for some reason we don't really understand at the<br>
moment, people have programs which rely on adding flavor access to a<br>
tenant which is already on the access list being rejected rather than<br>
silently accepted. And I'm not sure its the behavior from flavor access<br>
that we actually want.<br>
<br></blockquote><div><br></div><div>I agree this sounds like we are just digging the hole deeper.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But we certainly don't want to end up in the situation of trying to<br>
work out how to rollback two backwards incompatible API changes.<br>
<br>
Chris<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>