<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 27 févr. 2019 à 01:44, Zane Bitter <<a href="mailto:zbitter@redhat.com">zbitter@redhat.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 21/02/19 12:28 PM, Sylvain Bauza wrote:<br>
>      > * If you had a magic wand and could inspire and make a single<br>
>      >   sweeping architectural or software change across the services,<br>
>      >   what would it be? For now, ignore legacy or upgrade concerns.<br>
>      >   What role should the TC have in inspiring and driving such<br>
>      >   changes?<br>
> <br>
>     1: Single agent on each compute node that allows for plugins to do<br>
>         all the work required. (Nova / Neutron / Vitrage / watcher / etc)<br>
> <br>
>     2: Remove RMQ where it makes sense - e.g. for nova-api -> nova-compute<br>
>         using something like HTTP(S) would make a lot of sense.<br>
> <br>
>     3: Unified Error codes, with a central registry, but at the very least<br>
>         each time we raise an error, and it gets returned a user can see<br>
>         where in the code base it failed. e.g. a header that has<br>
>         OS-ERROR-COMPUTE-3142, which means that someone can google for<br>
>         something more informative than the VM failed scheduling<br>
> <br>
>     4: OpenTracing support in all projects.<br>
> <br>
>     5: Possibly something with pub / sub where each project can listen for<br>
>         events and not create something like designate did using<br>
>         notifications.<br>
> <br>
> <br>
> That's the exact reason why I tried to avoid to answer about <br>
> architectural changes I'd like to see it done. Because when I read the <br>
> above lines, I'm far off any consensus on those.<br>
> To answer 1. and 2. from my Nova developer's hat, I'd just say that we <br>
> invented Cells v2 and Placement.<br>
> To be clear, the redesign wasn't coming from any other sources but our <br>
> users, complaining about scale. IMHO If we really want to see some <br>
> comittee driving us about feature requests, this should be the UC and <br>
> not the TC.<br>
> <br>
> Whatever it is, at the end of the day, we're all paid by our sponsors. <br>
> Meaning that any architectural redesign always hits the reality wall <br>
> where you need to convince your respective Product Managers of the great <br>
> benefit of the redesign. I'm maybe too pragmatic, but I remember so many <br>
> discussions we had about redesigns that I now feel we just need hands, <br>
> not ideas.<br>
<br>
C'mon, the question explicitly stipulated use of a magic wand, ignoring <br>
path dependence and throwing out backwards compat, but you're worried <br>
about the practicalities of convincing product managers??!?<br>
<br>
We need to stop reflexively stifling these discussions. An 'open' <br>
community where nobody is allowed to so much as spitball ideas in case <br>
somebody disagrees with them is unworthy of the name.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">We are post the campaign period so I won't argue but see my other emails after this one, hopefully you will see that I'm not against discussing about architectural concerns, just not here and not by only the TC members.</div><div dir="auto"><br></div><div dir="auto">Sylvain (stopping now the campaign)</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- ZB<br>
<br>
</blockquote></div></div></div>