<div dir="ltr">><span style="font-size:12.8px">Don't even get me started on Neutron.[2]</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">It seems to me the conclusion to that thread was that the majority of your issues stemmed from the fact that we had poor documentation at the time.  A major component of the complaints resulted from you misunderstanding the difference between networks/subnets in Neutron. </span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">There are some legitimate issues in there about the extra routes extension being replace-only and the routers API not accepting a list of interfaces in POST.  However, i</span>t hardly seems that those are worthy of "Don't even get me started on Neutron."</div><div><br></div><div>It would be nice if you could write up something about current gaps that would make Heat's life easier, because a large chunk of that initial email is incorrect and linking to it as a big list of "issues" is counter-productive.</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 19, 2017 at 7:36 AM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 18/05/17 20:19, Matt Riedemann wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I just wanted to blurt this out since it hit me a few times at the<br>
summit, and see if I'm misreading the rooms.<br>
<br>
For the last few years, Nova has pushed back on adding orchestration to<br>
the compute API, and even define a policy for it since it comes up so<br>
much [1]. The stance is that the compute API should expose capabilities<br>
that a higher-level orchestration service can stitch together for a more<br>
fluid end user experience.<br>
</blockquote>
<br></span>
I think this is a wise policy.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
One simple example that comes up time and again is allowing a user to<br>
pass volume type to the compute API when booting from volume such that<br>
when nova creates the backing volume in Cinder, it passes through the<br>
volume type. If you need a non-default volume type for boot from volume,<br>
the way you do this today is first create the volume with said type in<br>
Cinder and then provide that volume to the compute API when creating the<br>
server. However, people claim that is bad UX or hard for users to<br>
understand, something like that (at least from a command line, I assume<br>
Horizon hides this, and basic users should probably be using Horizon<br>
anyway right?).<br>
</blockquote>
<br></span>
As always, there's a trade-off between simplicity and flexibility. I can certainly understand the logic in wanting to make the simple stuff simple. But users also need to be able to progress from simple stuff to more complex stuff without having to give up and start over. There's a danger of leading them down the garden path.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
While talking about claims in the scheduler and a top-level conductor<br>
for cells v2 deployments, we've talked about the desire to eliminate<br>
"up-calls" from the compute service to the top-level controller services<br>
(nova-api, nova-conductor and nova-scheduler). Build retries is one such<br>
up-call. CERN disables build retries, but others rely on them, because<br>
of how racy claims in the computes are (that's another story and why<br>
we're working on fixing it). While talking about this, we asked, "why<br>
not just do away with build retries in nova altogether? If the scheduler<br>
picks a host and the build fails, it fails, and you have to<br>
retry/rebuild/delete/recreate from a top-level service."<br>
</blockquote>
<br></span>
(FWIW Heat does this for you already.)<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But during several different Forum sessions, like user API improvements<br>
[2] but also the cells v2 and claims in the scheduler sessions, I was<br>
hearing about how operators only wanted to expose the base IaaS services<br>
and APIs and end API users wanted to only use those, which means any<br>
improvements in those APIs would have to be in the base APIs (nova,<br>
cinder, etc). To me, that generally means any orchestration would have<br>
to be baked into the compute API if you're not using Heat or something<br>
similar.<br>
</blockquote>
<br></span>
The problem is that orchestration done inside APIs is very easy to do badly in ways that cause lots of downstream pain for users and external orchestrators. For example, Nova already does some orchestration: it creates a Neutron port for a server if you don't specify one. (And then promptly forgets that it has done so.) There is literally an entire inner platform, an orchestrator within an orchestrator, inside Heat to try to manage the fallout from this. And the inner platform shares none of the elegance, such as it is, of Heat itself, but is rather a collection of cobbled-together hacks to deal with the seemingly infinite explosion of edge cases that we kept running into over a period of at least 5 releases.<br>
<br>
The get-me-a-network thing is... better, but there's no provision for changes after the server is created, which means we have to copy-paste the Nova implementation into Heat to deal with update.[1] Which sounds like a maintenance nightmare in the making. That seems to be a common mistake: to assume that once users create something they'll never need to touch it again, except to delete it when they're done.<br>
<br>
Don't even get me started on Neutron.[2]<br>
<br>
Any orchestration that is done behind-the-scenes needs to be done superbly well, provide transparency for external orchestration tools that need to hook in to the data flow, and should be developed in consultation with potential consumers like Shade and Heat.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am I missing the point, or is the pendulum really swinging away from<br>
PaaS layer services which abstract the dirty details of the lower-level<br>
IaaS APIs? Or was this always something people wanted and I've just<br>
never made the connection until now?<br>
</blockquote>
<br></span>
(Aside: can we stop using the term 'PaaS' to refer to "everything that Nova doesn't do"? This habit is not helping us to communicate clearly.)<br>
<br>
cheers,<br>
Zane.<br>
<br>
[1] <a href="https://review.openstack.org/#/c/407328/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/407328/</a><br>
[2] <a href="http://lists.openstack.org/pipermail/openstack-dev/2014-April/032098.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pip<wbr>ermail/openstack-dev/2014-Apri<wbr>l/032098.html</a><div class="m_-711258134843823880HOEnZb"><div class="m_-711258134843823880h5"><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div></div>