Open Stack

This week had a TC meeting. Notes from that are in the last
section below. Information about other pending or new changes that
may impact readers are in the earlier sections.

# New Things

The TC now has [office
hours](https://governance.openstack.org/tc/#office-hours) and a
dedicated IRC channel on freenode: `#openstack-tc`. Office hours will
be for an hour at 09:00 UTC on Tuesdays, 01:00 UTC on Wednesdays,
and 15:00 UTC on Thursdays. The idea is that some segment of the
TC membership will be available during at least these times for
unstructured discussion with whomever from the community wants to
join in.

`etcd` has been approved as a [base
service](https://governance.openstack.org/tc/reference/base-services.html).
Emilien has posted an
[update](http://lists.openstack.org/pipermail/openstack-dev/2017-June/117943.html)
on using etcd with configuration management.

# Pending Stuff

## Queens Community Goals

[Last week's report](https://anticdent.org/tc-report-22.html) has a
bunch of links on community goals for Pike. There are enough of them
that we'll have to pick and choose amongst them. A new one proposes
[policy and docs in code](https://review.openstack.org/#/c/469954/).
The document has a long list of benefits of doing this. A big one is
that you can end up with a much smaller policy file. Even one that
doesn't exist at all if you choose to use the defaults.

The [email version of the
report](http://lists.openstack.org/pipermail/openstack-dev/2017-May/117655.html)
spawned a series of subthreads on the efficacy and relative fairness
of how we deal with plugins in tempest. It's unclear yet if there is
any actionable followup from that. One option might be to propose an
adjustment to the original [split plugins
goal](https://governance.openstack.org/tc/goals/queens/split-tempest-plugins.html)
to see how much or little support there is for the idea of all tests
being managed via plugins.

## Managing Binary Artifacts

With the increased interest in containers and integrating and
interacting with other communities (where the norms and requirements
for useful releases are sometimes different from those established
in OpenStack) some clarity was required on the constraints a project
must satisfy to do binary releases. [Guidelines for managing
releases of binary
artifacts](https://review.openstack.org/#/c/469265/) have been
proposed. They are not particularly onerous but the details deserve
wide review to make sure we're not painting ourselves into any
corners or introducing unnecessary risks.

# Meeting Stuff

This week had a scheduled TC meeting for the express purpose of
discussing what to do about PostgreSQL. The remainder of this
document has notes from that meeting.

There are several different concerns related to PostgreSQL, but the
most pressing one is that much of the OpenStack documentation makes
it appear that the volume of testing and other attention that MySQL
receives is also applied to PostgreSQL. This is not the case (for a
variety of reasons). There has been general agreement that something
must be done, at least presenting warnings in the documentation.

A [first proposal](https://review.openstack.org/#/c/427880/) was created
which provides a good deal of historical context and laid out some
steps for making the current state of PostgreSQL in OpenStack more
clear. After some disagreement over the extent and reach of the document
I created a [second proposal](https://review.openstack.org/#/c/465589/)
that tried to say less in general but specifically less about
MySQL and tried to point to a future where PostgreSQL could be a
legitimate option (in part because there are real people out there using
it, in part because two implementations is healthy in many ways).

This drew out a lot of discussion, including some about [the
philosophy of how we manage
databases](http://lists.openstack.org/pipermail/openstack-dev/2017-May/117148.html),
but much of it only identified fairly tightly held differences and
did not move us towards helping real people.

After some fatigue it was decided to have this meeting whereupon we
decided (taking the entire hour [to talk about
it](http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-06-06-20.00.log.html))
that there were two things we could agree to, one we could not, and
a need to have a discussion about some of the philosophical concerns
at some other time.

The things we can agree about are:

* The OpenStack documentation needs to indicate the lower attention
   that PostgreSQL currently receives from the upstream community.

* We need better insight of usage of OpenStack by people who are
   "behind" a vendor and may not care about or know about the user
   survey and thus we need to work with the foundation board to
   improve that situation.

Where we don't agree is whether the resolution being proposed needs
to include information about work being done to evaluate where on a
scale of "no big deal" to "really hard" a transition to MySQL from
PostgreSQL might be. This work is already planned or in progress by
SUSE. I, and maybe a few others (not entirely clear), feel that
while this is useful work, including it in a resolution about the
current state of PostgreSQL support is at least irrelevant and at
worst effectively a statement of a desire to kill support for
PostgreSQL. Publishing such a statement, even if casually and
without intent, could signal that effort to improve the attention
PostgreSQL gets would be wasted effort.

Which leads to one of the philosophical concerns: Having even
limited support for PostgreSQL means that OpenStack is demonstrating
support for the idea that the database layer should be an
abstraction and which RDBMS (or RDBMS interface-alike) used in a
deployment is a deployers choice. For some this is a sign of quality
and maturity (somewhat like being able to choose which ever WSGI
server you feel is ideal for your situation). For others, not
choosing a specific RDBMS builds in limitations that will prevent
OpenStack from being able to scale and upgrade elegantly.

We were unable to agree on this point but at least some people felt
it a topic we need to address in order to be able to fully resolve
the PostgreSQL question. On the other side of the same coin: since
there is as yet no resolution on the merit of a strong database
abstraction layer it would be inappropriate to overstate the
OpenStack commitment to MySQL.

The next step is that dirk has been volunteered to integrate the
latest feedback on the [first
proposal](https://review.openstack.org/#/c/427880/). Once that is
done, we will iterate there. People have committed to keeping their
concerns and feedback focused around making the document be about
those things on which we agree.

-- 
Chris Dent                  ┬──┬◡ﾉ(° -°ﾉ)       https://anticdent.org/
freenode: cdent                                         tw: @anticdent