[tc] Questions for TC Candidates

Sylvain Bauza sbauza at redhat.com
Thu Feb 21 18:04:37 UTC 2019


On Thu, Feb 21, 2019 at 6:47 PM Graham Hayes <gr at ham.ie> wrote:

>
>
> On 21/02/2019 17:28, Sylvain Bauza wrote:
> >
> >
> > On Thu, Feb 21, 2019 at 6:14 PM Graham Hayes <gr at ham.ie
> > <mailto:gr at ham.ie>> wrote:
> >
>
> <snip>
>
> >
> >     > * 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.
>
> Sure - this was if *I* had a magic wand - I have a completely different
> viewpoint to others. No community really ever has a full agreement.
>
>
Fair point, we work with consensus, not full agreements. It's always good
to keep that distinction in mind.

>From a TC perspective we have to look at these things from an
> overall view. My suggestions above were for *all* projects, specifically
> for #2 - I used a well known pattern as an example, but it can apply to
> Trove talking to DB instances, Octavia to LBaaS nodes (they already do
> this, and it is a good pattern), Zun, possibly Magnum (this is not an
> exaustive list, and may not suit all listed projects, I am taking them
> from the top of my head).
>
>
I'd be interested in discussing the use cases requiring such important
architectural splits.
The main reason why Cells v2 was implemented was to address the MQ/DB
scalability issue of 1000+ compute nodes.  The Edge thingy came after this,
so it wasn't the main driver for change.
If the projects you mention have the same footprints at scale, then yeah
I'm supportive of any redesign discussion that would come up.

That said, before stepping in into major redesigns, I'd wonder : could the
inter-services communication be improved in terms of reducing payload ?


> From what I understand there was even talk of doing it for Nova so that
> a central control plane could manage remote edge compute nodes without
> having to keep a RMQ connection alive across the WAN, but I am not sure
> where that got to.
>
>
That's a separate usecase (Edge) which wasn't the initial reason why we
started implementing Cells V2. I haven't heard any request from the Edge WG
during the PTGs about changing our messaging interface because $WAN but I'm
open to ideas.

-Sylvain

> 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.
>
> It should be a combination - UC and TC should be communicating about
> these requests - UC for the feedback, and the TC to see hwo they fit
> with the TCs vision for the direction of OpenStack.
>
> > 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.
>
> I fully agree, and it has been an issue in the community for as long as
> I can remember. It doesn't mean that we should stop pushing the project
> forward. We have already moved the needle with the cycle goals, so we
> can influence what features are added to projects. Lets continue to do
> so.
>
>
> <snip>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190221/b1965834/attachment-0001.html>


More information about the openstack-discuss mailing list