On 2/20/19 11:23 AM, Sylvain Bauza wrote:

Thanks Chris for asking us questions so we can clarify our opinions.

On Wed, Feb 20, 2019 at 3:52 PM Chris Dent <cdent+os@anticdent.org> wrote:

It's the Campaigning slot of the TC election process, where members
of the community (including the candidates) are encouraged to ask
the candidates questions and witness some debate. I have some
questions.

First off, I'd like to thank all the candidates for running and
being willing to commit some of their time. I'd also like to that
group as a whole for being large enough to force an election. A
representative body that is not the result of an election would not
be very representing nor have much of a mandate.

I agree with you on this point. It's important for OpenStack to have time to discuss about mandates.

The questions follow. Don't feel obliged to answer all of these. The
point here is to inspire some conversation that flows to many
places. I hope other people will ask in the areas I've chosen to
skip. If you have a lot to say, it might make sense to create a
different message for each response. Beware, you might be judged on
your email etiquette and attention to good email technique!

* How do you account for the low number of candidates? Do you
   consider this a problem? Why or why not?

Yes, again, I agree and to be honest, when I only saw we were only having 4 candidates 8 hours before the deadline, I said to myself "OK, you love OpenStack. You think the TC is important. But then, why aren't you then throwing your hat ?"

We all have opinions, right ? But then, why people don't want to be in the TC ? Because we don't have a lot of time for it ? Or because people think the TC isn't important ?

I don't want to discuss about politics here. But I somehow see a parallel in between what the TC is and what the European Union is : both are governances not fully decision-makers but are there for sharing same rules and vision.

If we stop having the TC, what would become OpenStack ? Just a set of parallel projects with no common guidance ?

The fact that a large number of candidacies went very late (including me) is a bit concerning to me. How can we become better ? I have no idea but saying that probably given the time investment it requires, most of the candidacies were probably holding some management acceptance before people would propose their names. Probably worth thinking about how the investment it requires, in particular given we have less full-time contributors that can dedicate large time for governance.

* Compare and contrast the role of the TC now to 4 years ago. If you
   weren't around 4 years ago, comment on the changes you've seen
   over the time you have been around. In either case: What do you
   think the TC role should be now?

4 years ago, we were in the Kilo timeframe. That's fun you mention this period, because at that exact time of the year, the TC voted on one of the probably most important decisions that impacted OpenStack : The Big Tent reform [1]

Taking a look at this time, I remember frustration and hard talks but also people committed to change things.

This decision hasn't changed a lot the existing service projects that were before the Big Tent, but it actually created a whole new ecosystem for developers. It had challenges but it never required to be abandoned, which means the program is a success.

Now the buzz is gone and the number of projects stable, the TC necessarly has to mutate to a role of making sure all the projects sustain the same pace and reliability. Most of the challenges for the TC is now about defining and applying criterias for ensuring that all our projects have a reasonable state for production. If you see my candidacy letter, two of my main drivers for my nomination are about upgradability and scalability concerns.

* What, to you, is the single most important thing the OpenStack
   community needs to do to ensure that packagers, deployers, and
   hobbyist users of OpenStack are willing to consistently upstream
   their fixes and have a positive experience when they do? What is
   the TC's role in helping make that "important thing" happen?

There are two very distinct reasons when a company decides to downstream-only : either by choice or because of technical reasons.

I don't think a lot of companies decide to manage technical debt on their own by choice. OpenStack is nearly 9 years old and most of the users know the price it is.

Consequently, I assume that the reasons are technical :

1/ they're running an old version and haven't upgraded (yet). We have good user stories of large cloud providers that invested in upgrades (for example OVH) and see the direct benefit of it. Maybe we can educate more on the benefits of upgrading frequently.

2/ they think upstreaming is difficult. I'm all open to hear the barriers they have. For what it's worth, OpenStack invested a lot in mentoring with the FirstContact SIG, documentation and Upstream Institute. There will probably also be a new program about peer-mentoring and recognition [2] if the community agrees with the idea. Honestly, I don't know what do do more. If you really can't upstream but care about your production, just take a service contract I guess.

 

* If you had a magic wand and could inspire and make a single
   sweeping architectural or software change across the services,
   what would it be? For now, ignore legacy or upgrade concerns.
   What role should the TC have in inspiring and driving such
   changes?

Take me as a fool but I don't think the role of the TC is to drive architectural decision between projects.

The TC can help two projects to discuss, the TC can (somehow) help moderate between two teams about some architectural concern but certainly not be the driver of such change.

Is there a particular reason why you feel this way?

I think the TC is in a great position to have a profound impact on the architecture of OpenStack, with a caveat.

I believe if you ask anyone with even a brief history in OpenStack, you'll dust up some architectural opinions. For example, Jim and Mohammed have already pointed out a bunch in their responses. Another example, Melanie and I had a productive discussion today about how restructuring the architecture of policy enforcement could significantly improvement usability and security [0], which certainly isn't specific to keystone or nova. I don't think we have to look very far to find excellent areas for improvement. As others have noted, the project is at a point where development and hype isn't nearly as intense as it was 4 years ago. While contributor numbers, in a way, reflect project stabilization, I also think it puts us in a prime position to address some of the architectural pain points we've grown to live with over the years. I think we can use the opportunity to make services more consistent, giving consumers and users a more refined and polished experience, among other benefits.

That said, I certainly think if the TC is to _facilitate_ in architectural decisions, it needs to be done in the open and with plenty of communication and feedback with the entire community. Similar to the approach we try and take with community goals.

I understand there may be a fine line in making decisions of this nature at the TC level, but I also think it presents numerous opportunities to communicate and focus efforts in a unified direction. I see that involvement range from socializing issues to advocating for sponsorship on a particular initiative to diving into the problem and helping projects directly.

[0] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2019-02-20.log.html#t2019-02-20T18:35:06

That doesn't mean the TC can't be technical. We have goals, for example. But in order to have well defined goals that are understandable by project contributors, we also need to have the projects be the drivers of such architectural changes.

 

* What can the TC do to make sure that the community (in its many
   dimensions) is informed of and engaged in the discussions and
   decisions of the TC?

You made a very good job in providing TC feedback. I surely think the TC has to make sure that a regular weekly feedback is provided.

For decisions that impact projects, I don't really see how TC members can vote without getting feedback from the project contributors, so here I see communication (thru Gerrit at least).

 

* How do you counter people who assert the TC is not relevant?
   (Presumably you think it is, otherwise you would not have run. If
   you don't, why did you run?)

Again, I think that is a matter of considering the TC responsibilities. We somehow need to clarify what are those responsibilities and I think I voiced on that above.

That's probably more than enough. Thanks for your attention.

I totally appreciate you challenging us. That's very important that people vote based on opinions rather than popularity.

-Sylvain

[1] https://governance.openstack.org/tc/resolutions/20141202-project-structure-reform-spec.html

[2] https://review.openstack.org/#/c/636956/

--
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent