<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Wed, Feb 20, 2019 at 9:52 AM Chris Dent <<a href="mailto:cdent%2Bos@anticdent.org" target="_blank">cdent+os@anticdent.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
It's the Campaigning slot of the TC election process, where members<br>
of the community (including the candidates) are encouraged to ask<br>
the candidates questions and witness some debate. I have some<br>
questions.<br>
<br>
First off, I'd like to thank all the candidates for running and<br>
being willing to commit some of their time. I'd also like to that<br>
group as a whole for being large enough to force an election. A<br>
representative body that is not the result of an election would not<br>
be very representing nor have much of a mandate.<br>
<br>
The questions follow. Don't feel obliged to answer all of these. The<br>
point here is to inspire some conversation that flows to many<br>
places. I hope other people will ask in the areas I've chosen to<br>
skip. If you have a lot to say, it might make sense to create a<br>
different message for each response. Beware, you might be judged on<br>
your email etiquette and attention to good email technique!<br></blockquote><div><br></div><div>I considered top-posting just because you said this :P</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* How do you account for the low number of candidates? Do you<br>
consider this a problem? Why or why not?<br></blockquote><div><br></div><div>I suspect that this is a combination of a few things:</div><div><br></div><div>* A decline in contributors who have enough time dedicated to spend</div><div> contributing to the TC. We're far down the hill of the hype cycle, and not as</div><div> many people can get time from their employers to do the "softer" things in</div><div> the community. I'm not sure if this is a problem or not - does the current TC</div><div> feel overloaded with work? If not, maybe we don't need so many people.</div><div><br></div><div>* A decline in contributors who think being on the TC can help further</div><div> their goals. Most contributors have focused technical goals, and being a</div><div> part of the TC usually doesn't accelerate those. This seems fine to me,</div><div> though I'd love to have more people with larger technical goals (more on</div><div> this later).</div><div><br></div><div>* The change in the perceived role of the TC. I'll dig into this more in the</div><div> next question. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* Compare and contrast the role of the TC now to 4 years ago. If you<br>
weren't around 4 years ago, comment on the changes you've seen<br>
over the time you have been around. In either case: What do you<br>
think the TC role should be now?<br></blockquote><div><br></div><div>As Sylvain mentioned, this is near the time of the big tent reform. Until</div><div>then, the TC was getting into technical details within/between projects. The</div><div>big tent reform was an admission that the TC overseeing technical bits doesn't</div><div>scale to something OpenStack-sized. As such, the role of the TC has become</div><div>far less technical, instead becoming stewards of the technical community. In</div><div>some ways, this is a good thing, as it gives projects autonomy to do what is</div><div>right for their project's users.</div><div><br></div><div>However, this means that there are few people driving for larger OpenStack-wide</div><div>changes to improve the experience for deployers, operators, and users. There</div><div>are some awesome people (you know who you are) making smaller improvements that</div><div>improve the story, but nothing like the architectural changes we need to really</div><div>fix some of our underlying issues.</div><div><br></div><div>I believe the TC needs to drive more of these big-picture changes, rather than</div><div>only focusing on governance. I'm not sure if that means doing the research to</div><div>decide what to focus on, writing POCs and doing performance tests, doing the</div><div>actual implementation, or just herding the right cats to get it done. I'm also</div><div>unsure how much time TC members would be able to commit to this. But, I think</div><div>without the TC driving things, it will never get done. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* What, to you, is the single most important thing the OpenStack<br>
community needs to do to ensure that packagers, deployers, and<br>
hobbyist users of OpenStack are willing to consistently upstream<br>
their fixes and have a positive experience when they do? What is<br>
the TC's role in helping make that "important thing" happen?<br></blockquote><div><br></div><div>Mohammed mentioned our tooling not being great here, and I agree. But we've</div><div>also decided time and time again that's not changing, so. I think what the</div><div>community needs to be doing is to be willing to spend the time mentoring</div><div>these people, and holding their hand while they stumble through gerrit or</div><div>writing complex tests. We should also be willing to take a patch from a</div><div>contributor (whether by gerrit, email, or bar napkin), and finish it for them.</div><div>For example, An operator that knows just enough python to find and fix an</div><div>off-by-one error probably isn't going to be able to fix the unit tests or think</div><div>through upgrade concerns.</div><div><br></div><div>I actually think we do a pretty good job with this today. Of course, it can</div><div>always improve, so I'd like to see us continue that. As far as the TC's role,</div><div>I think they should continue to encourage this behavior, and maybe make some</div><div>sort of push to communicating the fact that we're willing to help outside</div><div>of our usual channels. Busy users probably aren't reading this mailing list</div><div>much - we should find some more accessible ways to call for these</div><div>contributions.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* If you had a magic wand and could inspire and make a single<br>
sweeping architectural or software change across the services,<br>
what would it be? For now, ignore legacy or upgrade concerns.<br>
What role should the TC have in inspiring and driving such<br>
changes?<br></blockquote><div><br></div><div>The fun question! Note: these are strong opinions, held loosely. If someone can</div><div>prove that these changes won't improve OpenStack, I'm happy to drop them. :)</div><div><br></div><div>I agree with Mohammed, using rabbitmq for RPC isn't working out. I'd like us</div><div>to be using HTTP and service discovery.</div><div><br></div><div>I also think that running more than one agent on a hypervisor isn't productive.</div><div>These agents are fairly tightly coupled and are interacting with the same</div><div>resources - we should combine them into a single agent which services talk</div><div>to (over HTTP, of course). This should be organized under a single "compute</div><div>node" or "hypervisor" team. This aligns the team more with a layer of the</div><div>stack, rather than the APIs that abstracts those layers. Bonus points if this</div><div>agent becomes easier to deploy - a container or a statically linked binary</div><div>makes the hypervisor much easier to manage. Just image or PXE boot an OS,</div><div>drop the binary in, and go.</div><div><br></div><div>Last, we need to fix the developer experience in OpenStack. In my experience,</div><div>tooling that allows developers to iterate on changes quickly is the number one</div><div>quality of life improvement a software project can do. Our services often take</div><div>tens of minutes to run unit tests, and getting devstack up and running can</div><div>easily take an hour. This is a huge turn-off for casual contributors, and</div><div>a huge timesink for regular contributors.</div><div><br></div><div>As mentioned above, I believe that changes like this are fundamental to the</div><div>future of OpenStack. We keep improving, but without fixing the underlying</div><div>architectural issues, using or running OpenStack will always be painful. I</div><div>believe that the TC needs to lead these initiatives, and continue to push</div><div>on them, or else they won't get done.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* What can the TC do to make sure that the community (in its many<br>
dimensions) is informed of and engaged in the discussions and<br>
decisions of the TC?<br></blockquote><div><br></div><div>Honestly, I don't believe that the average OpenStack community member really</div><div>cares much about the discussions and decisions of the TC. Most of these don't</div><div>directly affect said average person. See the next question.</div><div><br></div><div>One thing that the average community member does seem to care about is the</div><div>goals process. I believe this is because these are technical changes which</div><div>improve OpenStack as a whole. We should do more of that.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* How do you counter people who assert the TC is not relevant?<br>
(Presumably you think it is, otherwise you would not have run. If<br>
you don't, why did you run?)<br></blockquote><div><br></div><div>Again, I don't think most of what the TC does is relevant to the average</div><div>community member. I think that the TC needs to be more technically focused,</div><div>and as such will be more relevant to the community. I hope to help steer us</div><div>this way. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
That's probably more than enough. Thanks for your attention.<br></blockquote><div><br></div><div>Thanks for asking!</div><div><br></div><div>// jim</div></div></div></div></div></div></div></div></div></div>