Open Stack

Sean,

Thanks for bringing this topic to TC meeting.

Regards,
Ivan Kolodyazhny,
Web Developer,
http://blog.e0ne.info/,
http://notacash.com/,
http://kharkivpy.org.ua/

On Thu, Oct 1, 2015 at 1:43 PM, Sean Dague <sean at dague.net> wrote:

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