Open Stack

On Tue, May 23, 2017 at 8:52 AM, Jay Pipes <jaypipes at gmail.com> wrote:
>
> 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?
>
>
 (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.

 Also, i'm pretty sure my users would mostly hate needing to pass a file to
boot a single instance.

 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.

 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.

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

 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.

 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.

-James
[1] Insert choir of angels sound here
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170523/8c2e8a06/attachment.html>