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