Open Stack

On Thu, Feb 21, 2019 at 7:28 PM Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:

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

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 ?
Doing Cells V2 was actually what you said "fixing the underlying
architectural issue". See
https://docs.openstack.org/nova/latest/user/cells.html#manifesto for
details.

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

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

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

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

-Sylvain

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> 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/20190222/1d24684a/attachment-0001.html>