[tc] Questions for TC Candidates

Graham Hayes gr at ham.ie
Thu Feb 21 17:43:12 UTC 2019



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.

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

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.

> 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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190221/7a1e9fa8/attachment-0001.sig>


More information about the openstack-discuss mailing list