Open Stack

On 30/05/17 19:09, Doug Hellmann wrote:
> Excerpts from Chris Dent's message of 2017-05-30 18:16:25 +0100:
>>
>> 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?
> 
> All projects may have plugins, but all projects with tests used by
> the Interop WG (formerly DefCore) for trademark certification must
> place at least those tests in the tempest repo, to be managed by
> the QA team [1]. As new projects are added to those trademark
> programs, the tests are supposed to move to the central repo to
> ensure the additional review criteria are applied properly.
> 
> [1] https://governance.openstack.org/tc/resolutions/20160504-defcore-test-location.html

In the InterOp discussions in Boston, it was indicated that some people
on the QA team were not comfortable with "non core" project (even in
the InterOp program) having tests in core tempest.

I do think that may be a bigger discussion though.

> 
>>
>> ### 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
>