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

2017-05-31 Thread Graham Hayes 
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]: 
>> 
>>
>> # 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]: 
>> [^3]: 
>> 
>> [^4]: 
>> [^5]: 
>> [^6]: 
>> [^7]: 
>>
>> ## 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]: 
>>
>> ## 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.
>>
>>

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

2017-05-31 Thread Graham Hayes 
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]:
> 
> 
> # 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]: 
> [^3]:
> 
> 
> [^4]: 
> [^5]: 
> [^6]: 
> [^7]: 
> 
> ## 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]: 
> 
> ## 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

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

2017-05-30 Thread Doug Hellmann 
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]: 
> 
> 
> # 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

> 
> ### 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]: 
> [^3]: 
> 
> [^4]: 
> [^5]: 
> [^6]: 
> [^7]: 
> 
> ## 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]: 
> 
> ## 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

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

2017-05-30 Thread Chris Dent 


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]: 

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

### 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]: 
[^3]: 

[^4]: 
[^5]: 
[^6]: 
[^7]: 

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

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