[openstack-dev] [tc] [all] TC Report 22

Graham Hayes ghayes at suse.de
Wed May 31 08:50:28 UTC 2017


On 30/05/17 18:16, Chris Dent wrote:
> 
> There's no TC meeting this week. Thierry did a second weekly status
> report[^1]. There will be a TC meeting next week (Tuesday, 6th June
> at 20:00 UTC) with the intention of discussing the proposals about
> postgreSQL (of which more below). Here are my comments on pending TC
> activity that either seems relevant or needs additional input.
> 
> [^1]:
> <http://lists.openstack.org/pipermail/openstack-dev/2017-May/117531.html>
> 
> # Pending Stuff
> 
> ## Queens Community Goals
> 
> Proposals for community-wide goals[^2] for the Queens cycle have started
> coming in. These are changes which, if approved, all projects are
> expected to satisfy. In Pike the goals are:
> 
> * [all control plane APIs deployable as WSGI
> apps](https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html)
> 
> * [supporting Python
> 3.5](https://governance.openstack.org/tc/goals/pike/python35.html)
> 
> The full suite of goals for Queens has not yet been decided.
> Identifying goals is a community-wide process. Your ideas are
> wanted.
> 
> ### Split Tempest Plugins into Separate Repos
> 
> This goal for Queens is already approved. Any project which manages
> its tempest tests as a plugin should move those tests into a
> separate repo. The goal is at[^3]. The review for it[^4] has further
> discussion on why it is a good idea.
> 
> The original goal did not provide instructions on how to do it.
> There is a proposal in progress[^5] to add a link to an etherpad[^6]
> with instructions.
> 
> Note that this goal only applies to tempest _plugins_. Projects
> which have their tests in the core of tempest have nothing to do. I
> wonder if it wouldn't be more fair for all projects to use plugins
> for their tempest tests?

+ 1000. But apparently I am wrong on this.

> 
> ### Two Proposals on Improving Version Discovery
> 
> Monty has been writing API-WG guidelines about how to properly use
> the service catalog and do version discovery[^7]. Building from that
> he's proposed two new goals:
> 
> * [Add Queens goal to add collection
> links](https://review.openstack.org/#/c/468436/)
> * [Add Queens goal for full discovery
> alignment](https://review.openstack.org/#/c/468437/)
> 
> The first is a small step in the direction of improving version
> discovery, the second is all the steps to getting all projects
> supporting proper version discovery, in case we are feeling extra
> capable.
> 
> Both of these need review from project contributors, first to see if there
> is agreement on the strategies, second to see if they are
> achievable.
> 
> [^2]: <https://governance.openstack.org/tc/goals/index.html>
> [^3]:
> <https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html>
> 
> [^4]: <https://review.openstack.org/#/c/369749/>
> [^5]: <https://review.openstack.org/#/c/468972/>
> [^6]: <https://etherpad.openstack.org/p/tempest-separate-plugin>
> [^7]: <https://review.openstack.org/#/c/462814/>
> 
> ## etcd as a base service
> 
> etcd has been proposed as a base service[^8]. A "base" service is
> one that that can be expected to be present in any OpenStack
> deployment. The hope is that by declaring this we can finally
> bootstrap the distributed locking, group membership and service
> liveness functionality that we've been talking about for years. If
> you want this please say so on the review. You want this.
> 
> If for some reason you _don't_ want this, then you'll want to
> register your reasons as soon as possible. The review will merge
> soon.
> 
> [^8]: <https://review.openstack.org/#/c/467436/>
> 
> ## openstack-tc IRC channel
> 
> With the decrease in the number of TC meetings on IRC there's a plan
> to have [office hours](https://review.openstack.org/#/c/467256/)
> where some significant chunk of the TC will be available. Initially
> this was going to be in the `#openstack-dev` channel but in the
> hopes of making the logs readable after the fact, a [new channel is
> proposed](https://review.openstack.org/#/c/467386/).
> 
> This is likely to pass soon, unless objections are raised. If you
> have some, please raise them on the review.
> 
> ## postgreSQL
> 
> The discussions around postgreSQL have yet to resolve. See [last week's
> report](https://anticdent.org/tc-report-21.html) for additional
> information. Because things are blocked and there have been some
> expressions of review fatigue there will be, as mentioned above, a
> TC meeting next week on 6th June, 20:00 UTC. Show up if you have an
> opinion if or how postgreSQL should or should not have a continuing
> presence in OpenStack. Some links:
> 
> * [original proposal documenting the lack of community attention to
>   postgreSQL](https://review.openstack.org/#/c/427880/)
> * [a shorter, less MySQL-oriented
> version](https://review.openstack.org/#/c/465589/)
> * [related email
>  
> thread](http://lists.openstack.org/pipermail/openstack-dev/2017-May/116642.html)
> 
> * [active vs external approaches to RDBMS
>  
> management](http://lists.openstack.org/pipermail/openstack-dev/2017-May/117148.html)
> 
> 
> ## Draft Vision for the TC
> 
> johnthetubaguy, dtroyer and I (cdent) continue to work on digesting
> the feedback[^9] to the TC Vision document[^10]. We've made a bit of
> progress but there's more work to do. If you have new feedback,
> please add it to the review.
> 
> [^9]:
> <https://docs.google.com/spreadsheets/d/1YzHPP2EQh2DZWGTj_VbhwhtsDQebAgqldyi1MHm6QpE>
> 
> [^10]: <https://review.openstack.org/#/c/453262/>
> 
> 
> 
> __________________________________________________________________________
> 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
> 




More information about the OpenStack-dev mailing list