Open Stack

( With brackets: https://anticdent.org/tc-report-41.html )

If there's a unifying theme in the mix of discussions that have
happended in `#openstack-tc` this past week, it is power: who has it,
what does it really mean, and how to exercise it.

This is probably because it is election season. After a slow start
there is now a [rather large number of
candidates](https://governance.openstack.org/election/#queens-tc-candidates),
a very diverse group. Is great to see.

On
[Wednesday](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-04.log.html),
there were questions about the
[constellations](https://governance.openstack.org/tc/resolutions/20170404-vision-2019.html#navigating-with-constellations)
idea mooted in the TC Vision Statement and the extent to which the TC has power
to enforce integration between projects. Especially those which are considered
_core_ and those that are not (in this particular case Zaqar). The precedent
here is that the TC has minimal direct power in such cases (each project is
fairly autonomous), whereas individuals, some of whom happen to be on the TC,
do have power, by virtue of making specific changes in code. The role of the TC
in these kinds of situations is in making ideas and approaches visible (like
constellations) and drawing attention to needs (like the [top 5
list](https://governance.openstack.org/tc/reference/top-5-help-wanted.html)).

[Thursday's](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-05.log.html#t2017-10-05T15:00:01)
discussion provides an interesting counterpoint.  There some potential
candidates expressed concern about running because they were interested in
maintaining the good things that OpenStack has and had no specific agenda for
drastic or dramatic change while candidates often express what they'd like to
change. This desire for stability is probably a good fit, because in some ways
the main power of the TC is choosing which projects to let into the club and in
extreme cases kicking bad projects out. That latter is effectively the nuclear
option: since nobody wants to use it the autonomy of projects is enhanced.

Continuing the rolling segues: On the same day, ttx provided access
to [the answers to two
questions](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-05.log.html#t2017-10-05T15:46:43)
related to "developer satisfaction" that were added to the PTG survey.
These aren't the original questions, they were adjusted to be
considerably more open ended than the originals, which were
effectively yes or no questions. The questions:

* What is the most important thing we should do to improve the
   OpenStack software over the next year?
* What is one change that would make you happier as an OpenStack
   Upstream developer?

I intend to analyse and group these for themes when I have the time,
but just reading them en masse is interesting if you have some time. One
emerging theme is that some projects are perceived to have too much
power.

Which bring us to today's [office
hours](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-10.log.html#t2017-10-10T09:01:40)
where the power to say yes or no to a project was discussed again.

First up [Glare](https://review.openstack.org/#/c/479285/)
There are a few different (sometimes overlapping) camps:

* If we can't come up with reasons to _not_ include them, we should
   include them.
* If we can't come up with reasons to include then, we should _not_
   include them.
* If they are going to cause difficulties for Glance or the stability of
   the images API, that's a risk.
* If the Glare use case is abstract storage of stuff, and that's
   useful for everyone, why should Glare be an OpenStack project and
   not a more global or general open source project?

This needs to be resolved soon. It would be easier to figure out if
there was already a small and clear use case being addressed by Glare
with a clear audience.

Then [Mogan](https://review.openstack.org/#/c/508400/), a bare metal
compute service. There the camps are:

* The overlaps with Nova and Ironic, especially at the API-level
   are a significant _problem_.
* The overlaps with Nova and Ironic, especially at the API-level
   are a significant _opportunity_.

Straight [into the
log](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-10.log.html#t2017-10-10T09:55:08)
for more.

Finally, we landed on the topic of whether there's anything the TC can
do to help with the [extraction of
placement](http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2017-10-10.log.html#t2017-10-10T10:06:18)
from nova.

-- 
Chris Dent                      (⊙＿⊙')         https://anticdent.org/
freenode: cdent                                         tw: @anticdent