Open Stack

On Wed, Feb 20, 2019 at 9:52 AM Chris Dent <cdent+os at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190220/e1626483/attachment.html>