Open Stack

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/20190221/87fda211/attachment.html>