On Wed, Feb 20, 2019 at 9:52 AM 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.

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!

I considered top-posting just because you said this :P

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

I suspect that this is a combination of a few things:

* A decline in contributors who have enough time dedicated to spend

contributing to the TC. We're far down the hill of the hype cycle, and not as

many people can get time from their employers to do the "softer" things in

the community. I'm not sure if this is a problem or not - does the current TC

feel overloaded with work? If not, maybe we don't need so many people.

* A decline in contributors who think being on the TC can help further

their goals. Most contributors have focused technical goals, and being a

part of the TC usually doesn't accelerate those. This seems fine to me,

though I'd love to have more people with larger technical goals (more on

this later).

* The change in the perceived role of the TC. I'll dig into this more in the

next question.

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

As Sylvain mentioned, this is near the time of the big tent reform. Until

then, the TC was getting into technical details within/between projects. The

big tent reform was an admission that the TC overseeing technical bits doesn't

scale to something OpenStack-sized. As such, the role of the TC has become

far less technical, instead becoming stewards of the technical community. In

some ways, this is a good thing, as it gives projects autonomy to do what is

right for their project's users.

However, this means that there are few people driving for larger OpenStack-wide

changes to improve the experience for deployers, operators, and users. There

are some awesome people (you know who you are) making smaller improvements that

improve the story, but nothing like the architectural changes we need to really

fix some of our underlying issues.

I believe the TC needs to drive more of these big-picture changes, rather than

only focusing on governance. I'm not sure if that means doing the research to

decide what to focus on, writing POCs and doing performance tests, doing the

actual implementation, or just herding the right cats to get it done. I'm also

unsure how much time TC members would be able to commit to this. But, I think

without the TC driving things, it will never get done.

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

Mohammed mentioned our tooling not being great here, and I agree. But we've

also decided time and time again that's not changing, so. I think what the

community needs to be doing is to be willing to spend the time mentoring

these people, and holding their hand while they stumble through gerrit or

writing complex tests. We should also be willing to take a patch from a

contributor (whether by gerrit, email, or bar napkin), and finish it for them.

For example, An operator that knows just enough python to find and fix an

off-by-one error probably isn't going to be able to fix the unit tests or think

through upgrade concerns.

I actually think we do a pretty good job with this today. Of course, it can

always improve, so I'd like to see us continue that. As far as the TC's role,

I think they should continue to encourage this behavior, and maybe make some

sort of push to communicating the fact that we're willing to help outside

of our usual channels. Busy users probably aren't reading this mailing list

much - we should find some more accessible ways to call for these

contributions.

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

The fun question! Note: these are strong opinions, held loosely. If someone can

prove that these changes won't improve OpenStack, I'm happy to drop them. :)

I agree with Mohammed, using rabbitmq for RPC isn't working out. I'd like us

to be using HTTP and service discovery.

I also think that running more than one agent on a hypervisor isn't productive.

These agents are fairly tightly coupled and are interacting with the same

resources - we should combine them into a single agent which services talk

to (over HTTP, of course). This should be organized under a single "compute

node" or "hypervisor" team. This aligns the team more with a layer of the

stack, rather than the APIs that abstracts those layers. Bonus points if this

agent becomes easier to deploy - a container or a statically linked binary

makes the hypervisor much easier to manage. Just image or PXE boot an OS,

drop the binary in, and go.

Last, we need to fix the developer experience in OpenStack. In my experience,

tooling that allows developers to iterate on changes quickly is the number one

quality of life improvement a software project can do. Our services often take

tens of minutes to run unit tests, and getting devstack up and running can

easily take an hour. This is a huge turn-off for casual contributors, and

a huge timesink for regular contributors.

As mentioned above, I believe that changes like this are fundamental to the

future of OpenStack. We keep improving, but without fixing the underlying

architectural issues, using or running OpenStack will always be painful. I

believe that the TC needs to lead these initiatives, and continue to push

on them, or else they won't get done.

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

Honestly, I don't believe that the average OpenStack community member really

cares much about the discussions and decisions of the TC. Most of these don't

directly affect said average person. See the next question.

One thing that the average community member does seem to care about is the

goals process. I believe this is because these are technical changes which

improve OpenStack as a whole. We should do more of that.

* 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 don't think most of what the TC does is relevant to the average

community member. I think that the TC needs to be more technically focused,

and as such will be more relevant to the community. I hope to help steer us

this way.

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

Thanks for asking!

// jim