<div dir="ltr">Sean,<div><br></div><div>Thanks for bringing this topic to TC meeting.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">Regards,<br>Ivan Kolodyazhny,<br>Web Developer,<br><a href="http://blog.e0ne.info/" target="_blank">http://blog.e0ne.info/</a>,<div><a href="http://notacash.com/" target="_blank">http://notacash.com/</a>,</div><div><a href="http://kharkivpy.org.ua/" target="_blank">http://kharkivpy.org.ua/</a></div></div></div>
<br><div class="gmail_quote">On Thu, Oct 1, 2015 at 1:43 PM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is now queued up for discussion this week -<br>
<a href="https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Agenda</a><br>
<div class="HOEnZb"><div class="h5"><br>
On 10/01/2015 06:22 AM, Sean Dague wrote:<br>
> Some of us are actively watching the thread / participating. I'll make<br>
> sure it gets on the TC agenda in the near future.<br>
><br>
> I think most of the recommendations are quite good, especially on the<br>
> client support front for clients / tools within our community.<br>
><br>
> On 09/30/2015 10:37 PM, Matt Fischer wrote:<br>
>> Thanks for summarizing this Mark. What's the best way to get feedback<br>
>> about this to the TC? I'd love to see some of the items which I think<br>
>> are common sense for anyone who can't just blow away devstack and start<br>
>> over to get added for consideration.<br>
>><br>
>> On Tue, Sep 29, 2015 at 11:32 AM, Mark Voelker <<a href="mailto:mvoelker@vmware.com">mvoelker@vmware.com</a><br>
>> <mailto:<a href="mailto:mvoelker@vmware.com">mvoelker@vmware.com</a>>> wrote:<br>
>><br>
>><br>
>> Mark T. Voelker<br>
>><br>
>><br>
>><br>
>> > On Sep 29, 2015, at 12:36 PM, Matt Fischer <<a href="mailto:matt@mattfischer.com">matt@mattfischer.com</a><br>
>> <mailto:<a href="mailto:matt@mattfischer.com">matt@mattfischer.com</a>>> wrote:<br>
>> ><br>
>> ><br>
>> ><br>
>> > I agree with John Griffith. I don't have any empirical evidences<br>
>> to back<br>
>> > my "feelings" on that one but it's true that we weren't enable to<br>
>> enable<br>
>> > Cinder v2 until now.<br>
>> ><br>
>> > Which makes me wonder: When can we actually deprecate an API<br>
>> version? I<br>
>> > *feel* we are fast to jump on the deprecation when the replacement<br>
>> isn't<br>
>> > 100% ready yet for several versions.<br>
>> ><br>
>> > --<br>
>> > Mathieu<br>
>> ><br>
>> ><br>
>> > I don't think it's too much to ask that versions can't be<br>
>> deprecated until the new version is 100% working, passing all tests,<br>
>> and the clients (at least python-xxxclients) can handle it without<br>
>> issues. Ideally I'd like to also throw in the criteria that<br>
>> devstack, rally, tempest, and other services are all using and<br>
>> exercising the new API.<br>
>> ><br>
>> > I agree that things feel rushed.<br>
>><br>
>><br>
>> FWIW, the TC recently created an assert:follows-standard-deprecation<br>
>> tag. Ivan linked to a thread in which Thierry asked for input on<br>
>> it, but FYI the final language as it was approved last week [1] is a<br>
>> bit different than originally proposed. It now requires one release<br>
>> plus 3 linear months of deprecated-but-still-present-in-the-tree as<br>
>> a minimum, and recommends at least two full stable releases for<br>
>> significant features (an entire API version would undoubtedly fall<br>
>> into that bucket). It also requires that a migration path will be<br>
>> documented. However to Matt’s point, it doesn’t contain any<br>
>> language that says specific things like:<br>
>><br>
>> In the case of major API version deprecation:<br>
>> * $oldversion and $newversion must both work with<br>
>> [cinder|nova|whatever]client and openstackclient during the<br>
>> deprecation period.<br>
>> * It must be possible to run $oldversion and $newversion<br>
>> concurrently on the servers to ensure end users don’t have to switch<br>
>> overnight.<br>
>> * Devstack uses $newversion by default.<br>
>> * $newversion works in Tempest/Rally/whatever else.<br>
>><br>
>> What it *does* do is require that a thread be started here on<br>
>> openstack-operators [2] so that operators can provide feedback. I<br>
>> would hope that feedback like “I can’t get clients to use it so<br>
>> please don’t remove it yet” would be taken into account by projects,<br>
>> which seems to be exactly what’s happening in this case with Cinder<br>
>> v1. =)<br>
>><br>
>> I’d hazard a guess that the TC would be interested in hearing about<br>
>> whether you think that plan is a reasonable one (and given that TC<br>
>> election season is upon us, candidates for the TC probably would too).<br>
>><br>
>> [1] <a href="https://review.openstack.org/#/c/207467/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/207467/</a><br>
>> [2]<br>
>> <a href="http://git.openstack.org/cgit/openstack/governance/tree/reference/tags/assert_follows-standard-deprecation.rst#n59" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/openstack/governance/tree/reference/tags/assert_follows-standard-deprecation.rst#n59</a><br>
>><br>
>> At Your Service,<br>
>><br>
>> Mark T. Voelker<br>
>><br>
>><br>
>> ><br>
>> ><br>
>> > __________________________________________________________________________<br>
>> > OpenStack Development Mailing List (not for usage questions)<br>
>> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
>> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
>> _______________________________________________<br>
>> OpenStack-operators mailing list<br>
>> <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
>> <mailto:<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a>><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
>><br>
>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>><br>
><br>
><br>
<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>