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 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. Emilien has posted an update on using etcd with configuration management.

Pending Stuff

Queens Community Goals

Last week's report 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. 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 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 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 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 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 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, 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) 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. 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.