<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 21, 2019 at 7:28 PM Fox, Kevin M <<a href="mailto:Kevin.Fox@pnnl.gov">Kevin.Fox@pnnl.gov</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div style="direction:ltr;font-family:Tahoma;color:rgb(0,0,0);font-size:10pt">I think its good for the TC to discuss architectural shortcomings... Someone really needs to do it.<br>
<br>
If the way to do that is to have folks be elected based on recommending architecture changes and we vote on electing them, at least thats some way for folks to provide feedback on whats important there. Gives us operators more of a way to provide feedback.<br>
<br>
For example, I think CellsV2 mostly came about due to the current architecture not scaling well due to mysql/and torturing rabbit. The nova team felt I think it best to stick with the blessed architecture and try and scale it (not unreasonable from a single
project perspective). But, rather then add a bunch of complexity which operators now suffer for, it could have been handled by fixing the underlying architectural issue. </div></div></blockquote><div><br></div><div>That's a bit unfortunate if you feel having more operator complexity with Cells V2 (rather than, per say, Cells V1) because Cells V2 is the default Nova now. Operators don't have to configure anything in order to start with a single cell, right ?</div><div>Doing Cells V2 was actually what you said "fixing the underlying architectural issue". See <a href="https://docs.openstack.org/nova/latest/user/cells.html#manifesto">https://docs.openstack.org/nova/latest/user/cells.html#manifesto</a> for details.</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"><div><div style="direction:ltr;font-family:Tahoma;color:rgb(0,0,0);font-size:10pt">Stop torturing rabbit. If k8s can do 5000 nodes with one, non sharded control plane, nova
should be able to too. Scheduling/starting a container and scheduling/starting a vm are not fundamentally different in their system requirements. </div></div></blockquote><div><br></div><div>From a 30K-feet high level, yes. Also, I can point some recommended architecture that allows you to have a single MQ for 5000 compute nodes with Nova, of course.</div><div>But let's not jump into technical details here. We'll have the Forum late April which is the perfect place for operator/developer communication and address this particular concern. Feel free to propose a Forum session about this, I'd be happy to participate to it.</div><div></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"><div><div style="direction:ltr;font-family:Tahoma;color:rgb(0,0,0);font-size:10pt">Before, operators didn't have a frame of reference so just went along with it. Now they have more options and
can more easily see the pain points in OpenStack and can decide to shift workload elsewhere. A single project can't make these sorts of overarching architectural decisions. The TC should do one of decide/help decide/facilitate deciding/delegate deciding. But
someone needs to drive it, otherwise it gets dropped. That should be the TC IMO.<br>
<br></div></div></blockquote><div><br></div><div>The TC can make people discussing, certainly. The TC can help arbitraring priorities, for sure. The TC can insufflate some guidance on archtectural decisions eventually. But the TC can't really identify the pain points for a specific project and allocate resources to work on those. TC folks aren't PMs or EMs.</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"><div><div style="direction:ltr;font-family:Tahoma;color:rgb(0,0,0);font-size:10pt">
The TC candidates are talking more and more about OpenStack being stable. One development quote I like, "the code is done, not when there is nothing more to add, but nothing more to remove" speaks to me here... Do TC candidates think that should that be an
architectural goal coming up soon? Figure out how to continue to do what OpenStack does, but do it simpler and/or with less code/services? That may require braking down some project walls. Is that a good thing to do?<br>
<br></div></div></blockquote><div><br></div><div>I personnally expressed the idea to have the TC focusing on maturity gaps between projects. Having TC goals be aligned with efforts for filling those gaps is somehow something I look for. What you mention is slighly different, you'd propose a goal about reducing tech debt. I don't really see actionable items on this from a first sight, but it's worth to consider discussing it at the PTG.</div><div><br></div><div>-Sylvain</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"><div><div style="direction:ltr;font-family:Tahoma;color:rgb(0,0,0);font-size:10pt">
Thanks,<br>
Kevin<br>
<br>
<div style="font-family:Times New Roman;color:rgb(0,0,0);font-size:16px">
<hr>
<div id="gmail-m_-4897978726945511697divRpF974850" style="direction:ltr"><font size="2" face="Tahoma" color="#000000"><b>From:</b> Sylvain Bauza [<a href="mailto:sbauza@redhat.com" target="_blank">sbauza@redhat.com</a>]<br>
<b>Sent:</b> Thursday, February 21, 2019 9:28 AM<br>
<b>To:</b> Graham Hayes<br>
<b>Cc:</b> <a href="mailto:openstack-discuss@lists.openstack.org" target="_blank">openstack-discuss@lists.openstack.org</a><br>
<b>Subject:</b> Re: [tc] Questions for TC Candidates<br>
</font><br>
</div>
<div></div>
<div>
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Feb 21, 2019 at 6:14 PM Graham Hayes <<a href="mailto:gr@ham.ie" rel="noopener noreferrer" target="_blank">gr@ham.ie</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 20/02/2019 14:46, Chris Dent wrote:<br>
> <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>
> <br>
> * How do you account for the low number of candidates? Do you<br>
> consider this a problem? Why or why not?<br>
<br>
I think we are reaching a more stable space, and the people who<br>
are developing the software are comfortable in the roles they are in.<br>
<br>
As the demographic of our developers shifts east, our leadership is<br>
still very US / EU based, which may be why we are not getting the<br>
same amount of people growing into TC candidates.<br>
<br>
> * 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>
<br>
4 years ago, was just before the big tent I think? Ironically, there<br>
was a lot of the same discussion - python3, new project requirements<br>
(at that point the incubation requirements), asyncio / eventlet.<br>
<br>
The TC was also in the process of dealing with a By-Laws change, in<br>
this case getting the trademark program off the ground.<br>
<br>
We were still struggling with the "what is OpenStack?" question.<br>
<br>
Looking back on the mailing list archives is actually quite interesting<br>
and while the topics are the same, a lot of the answers have changed.<br>
<br>
<br>
> * 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>
<br>
I think things like the review culture change have been good for this.<br>
The only other thing we can do is have more people reviewing, to make<br>
that first contact nice and quick, but E_NO_TIME or E_NO_HUMANS<br>
becomes the issue.<br>
<br>
> * 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>
<br>
1: Single agent on each compute node that allows for plugins to do<br>
all the work required. (Nova / Neutron / Vitrage / watcher / etc)<br>
<br>
2: Remove RMQ where it makes sense - e.g. for nova-api -> nova-compute<br>
using something like HTTP(S) would make a lot of sense.<br>
<br>
3: Unified Error codes, with a central registry, but at the very least<br>
each time we raise an error, and it gets returned a user can see<br>
where in the code base it failed. e.g. a header that has<br>
OS-ERROR-COMPUTE-3142, which means that someone can google for<br>
something more informative than the VM failed scheduling<br>
<br>
4: OpenTracing support in all projects.<br>
<br>
5: Possibly something with pub / sub where each project can listen for<br>
events and not create something like designate did using<br>
notifications.<br>
<br>
</blockquote>
<div><br>
</div>
<div>That's the exact reason why I tried to avoid to answer about architectural changes I'd like to see it done. Because when I read the above lines, I'm far off any consensus on those.</div>
<div>To answer 1. and 2. from my Nova developer's hat, I'd just say that we invented Cells v2 and Placement.</div>
<div>To be clear, the redesign wasn't coming from any other sources but our users, complaining about scale. IMHO If we really want to see some comittee driving us about feature requests, this should be the UC and not the TC.</div>
<div><br>
</div>
<div>Whatever it is, at the end of the day, we're all paid by our sponsors. Meaning that any architectural redesign always hits the reality wall where you need to convince your respective Product Managers of the great benefit of the redesign. I'm maybe too
pragmatic, but I remember so many discussions we had about redesigns that I now feel we just need hands, not ideas.</div>
<div><br>
</div>
<div>-Sylvain<br>
</div>
<div><br>
</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 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>
<br>
This is a difficult question, especially in a community where a lot of<br>
contributors are sponsored.<br>
<br>
The most effective way would be for the TC to start directly telling<br>
projects what to do - but I feel like that would mean that everyone<br>
would be unhappy with us.<br>
<br>
> * 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>
<br>
Highlight the work done by the TC communicating with the board, guiding<br>
teams on what our vision is, and helping to pick goals. I think the<br>
goals are a great way, and we are starting to see the benifits as we<br>
continue with the practice.<br>
<br>
For some people, we will always be surplus to requirements, and they<br>
just want to dig into bugs and features, and not worry about politics.<br>
<br>
Thats fine - we just have to work with enough of the people on the teams<br>
to make sure that the project is heading in the correct direction, and<br>
as long as people can pick up what the priotities are from that process,<br>
I think we win.<br>
<br>
> That's probably more than enough. Thanks for your attention.<br>
> <br>
<br>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote></div></div></div>