Open Stack

Just to follow up, there was a discussion at the TC meeting on this, and
given how close we are to summit we're proposing we have a cross project
session there about it - http://odsreg.openstack.org/cfp/details/27

We'll try to get that scheduled in a way that it will not conflict with
operator sessions, so we can operators in the room for it as well.

For folks that can't make it to summit, don't worry, we'll take that
discussion as a seed and bring the results back to the list / gerrit.

On 10/01/2015 11:05 AM, Ivan Kolodyazhny wrote:
> 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
> <mailto: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>
>     >> <mailto: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>
>     >>     <mailto: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://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>
>     >>     <mailto: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://OpenStack-dev-request@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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> __________________________________________________________________________
> 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