<div dir="ltr"><div><div><br></div></div><div class="gmail_extra"><div class="gmail_quote">On Tue, May 23, 2017 at 8:52 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If Heat was more widely deployed, would you feel this way? Would you reconsider having Heat as one of those "basic compute services" in OpenStack, then?<br>
<br></blockquote><div><br></div><div> (Caveat: I haven't looked at Heat in at least a year) I haven't deployed heat in my environment yet, because as a template based orchestration system it requires that you pass the correct template to construct or tear down a stack. If you were to come along and remove part of that stack in the interim, you throw everything into disarray, which then requires cleanup.</div><div><br></div><div> Also, i'm pretty sure my users would mostly hate needing to pass a file to boot a single instance. </div><div><br></div><div> As an example: In my environment I allows users to request a custom disk layout for baremetal hosts, by passing a yaml file as metadata (yeah, yeah I know). The result? They hate that they have to pass a file. To them disk layout should be a first class object, similar to flavors. I've pushed back hard against this: It's not clean, disk profiles should be the exception to the norm, just keep the profile in a code repo. But the truth is i'm coming around to their way of thinking. </div><div><br></div><div> I'm forced to choose between Architectural Purity[1] and what my customers actually need. In the end the people who actually use my product define it inasmuch as I do. At some point i'll probably give in and implement the thing they want, because from a broad perspective it makes sense to me, even though it doesn't align with the state of Nova right now.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is, unfortunately, one of the main problems stemming from OpenStack not having a *single* public API, with projects implementing parts of that single public API. You know, the thing I started arguing for about 6 years ago.<br>
<br>
If we had one single public porcelain API, we wouldn't even need to have this conversation. People wouldn't even know we'd changed implementation details behind the scenes and were doing retries at a slightly higher level than before. Oh well... we live and learn (maybe).<br>
<br></blockquote><div><br></div><div> I agree that a single entry point to OpenStack would be fantastic. If it existed, scheduling, quota, etc would have moved out of Nova a long time ago, and Nova at this point would be just a small VM driver. Unfortunately such a thing does not yet exist, and Nova has the momentum and mind share as -The- entry point for all things Compute in OpenStack.</div><div><br></div><div> If the community aligns behind a new porcelain API, great! But until it's ready, deployers, operators, and users need to run their businesses. Removing functionality that impedes our ability to provide a stable IaaS experience isn't acceptable to us. If the expectation is that deployers will hack around this, then that's putting us in the position of struggling even more to keep up with, or move to a current version of OpenStack. Worse, that's anathema to cloud interop.</div><div><br></div><div> Perhaps this is a place where the TC and Foundation should step in and foster the existence of a porcelain API. Either by constructing something new, or by growing Nova into that thing.</div><div><br></div><div>-James</div><div>[1] Insert choir of angels sound here</div></div></div></div>