Open Stack

I think its good for the TC to discuss architectural shortcomings... Someone really needs to do it.

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.

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. 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. 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.

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?

Thanks,
Kevin

________________________________
From: Sylvain Bauza [sbauza at redhat.com]
Sent: Thursday, February 21, 2019 9:28 AM
To: Graham Hayes
Cc: openstack-discuss at lists.openstack.org
Subject: Re: [tc] Questions for TC Candidates



On Thu, Feb 21, 2019 at 6:14 PM Graham Hayes <gr at ham.ie<mailto:gr at ham.ie>> wrote:
On 20/02/2019 14:46, Chris Dent 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!
>
> * How do you account for the low number of candidates? Do you
>   consider this a problem? Why or why not?

I think we are reaching a more stable space, and the people who
are developing the software are comfortable in the roles they are in.

As the demographic of our developers shifts east, our leadership is
still very US / EU based, which may be why we are not getting the
same amount of people growing into TC candidates.

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

4 years ago, was just before the big tent I think? Ironically, there
was a lot of the same discussion - python3, new project requirements
(at that point the incubation requirements), asyncio / eventlet.

The TC was also in the process of dealing with a By-Laws change, in
this case getting the trademark program off the ground.

We were still struggling with the "what is OpenStack?" question.

Looking back on the mailing list archives is actually quite interesting
and while the topics are the same, a lot of the answers have changed.


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

I think things like the review culture change have been good for this.
The only other thing we can do is have more people reviewing, to make
that first contact nice and quick, but E_NO_TIME or E_NO_HUMANS
becomes the issue.

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

1: Single agent on each compute node that allows for plugins to do
   all the work required. (Nova / Neutron / Vitrage / watcher / etc)

2: Remove RMQ where it makes sense - e.g. for nova-api -> nova-compute
   using something like HTTP(S) would make a lot of sense.

3: Unified Error codes, with a central registry, but at the very least
   each time we raise an error, and it gets returned a user can see
   where in the code base it failed. e.g. a header that has
   OS-ERROR-COMPUTE-3142, which means that someone can google for
   something more informative than the VM failed scheduling

4: OpenTracing support in all projects.

5: Possibly something with pub / sub where each project can listen for
   events and not create something like designate did using
   notifications.


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.
To answer 1. and 2. from my Nova developer's hat, I'd just say that we invented Cells v2 and Placement.
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.

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.

-Sylvain


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

This is a difficult question, especially in a community where a lot of
contributors are sponsored.

The most effective way would be for the TC to start directly telling
projects what to do - but I feel like that would mean that everyone
would be unhappy with us.

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

Highlight the work done by the TC communicating with the board, guiding
teams on what our vision is, and helping to pick goals. I think the
goals are a great way, and we are starting to see the benifits as we
continue with the practice.

For some people, we will always be surplus to requirements, and they
just want to dig into bugs and features, and not worry about politics.

Thats fine - we just have to work with enough of the people on the teams
to make sure that the project is heading in the correct direction, and
as long as people can pick up what the priotities are from that process,
I think we win.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190221/b3c91e9a/attachment-0001.html>