<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 26 January 2016 at 16:01, Ben Nemec <span dir="ltr"><<a href="mailto:openstack@nemebean.com" target="_blank">openstack@nemebean.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 01/26/2016 03:46 AM, Steven Hardy wrote:<br>
> On Mon, Jan 25, 2016 at 05:45:30PM -0600, Ben Nemec wrote:<br>
>> On 01/25/2016 03:56 PM, Steven Hardy wrote:<br>
>>> On Fri, Jan 22, 2016 at 11:24:20AM -0600, Ben Nemec wrote:<br>
>>>> So I haven't weighed in on this yet, in part because I was on vacation<br>
>>>> when it was first proposed and missed a lot of the initial discussion,<br>
>>>> and also because I wanted to take some time to order my thoughts on it.<br>
>>>>  Also because my initial reaction...was not conducive to calm and<br>
>>>> rational discussion. ;-)<br>
>>>><br>
>>>> The tldr is that I don't like it.  To explain why, I'm going to make a<br>
>>>> list (everyone loves lists, right? Top $NUMBER reasons we should stop<br>
>>>> expecting other people to write our API for us):<br>
>>>><br>
>>>> 1) We've been down this road before.  Except last time it was with Heat.<br>
>>>>  I'm being somewhat tongue-in-cheek here, but expecting a general<br>
>>>> service to provide us a user-friendly API for our specific use case just<br>
>>>> doesn't make sense to me.<br>
>>><br>
>>> Actually, we've been down this road before with Tuskar, and discovered that<br>
>>> designing and maintaining a bespoke API for TripleO is really hard.<br>
>><br>
>> My takeaway from Tuskar was that designing an API that none of the<br>
>> developers on the project use is doomed to fail.  Tuskar also suffered<br>
>> from a lack of some features in Heat that the new API is explicitly<br>
>> depending on in an attempt to avoid many of the problems Tuskar had.<br>
>><br>
>> Problem #1 is still developer apathy IMHO though.<br>
><br>
> I think the main issue is developer capacity - we're a small community and<br>
> I for one am worried about the effort involved with building and<br>
> maintaining a bespoke API - thus this whole discussion is essentially about<br>
> finding a quicker and easier way to meet the needs of those needing an API.<br>
><br>
> In terms of apathy, I think as a developer I don't need an abstraction<br>
> between me, my templates and heat.  Some advanced operators will feel<br>
> likewise, others won't.  What I would find useful sometimes is a general<br>
> purpose workflow engine, which is where I think the more pluggable mistral<br>
> based solution may have advantages in terms of developer and advanced<br>
> operator uptake.<br>
<br>
</div></div>The API is for end users, not developers.  tripleo-incubator was easily<br>
hackable for developers and power users.  It was unusable for everyone else.<br></blockquote><div><br></div><div>Doesn't it depend on what you mean by end users? I would argue that typically the CLI and UI will be for end users. Then API is for end users that are also developers. I don't imagine we are going to suggest non-developer end users directly use the API.<br></div><div> <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
><br>
>>> I somewhat agree that heat as an API is insufficient, but that doesn't<br>
>>> necessarily imply you have to have a TripleO specific abstraction, just<br>
>>> that *an* abstraction is required.<br>
>>><br>
>>>> 2) The TripleO API is not a workflow API.  I also largely missed this<br>
>>>> discussion, but the TripleO API is a _Deployment_ API.  In some cases<br>
>>>> there also happens to be a workflow going on behind the scenes, but<br>
>>>> honestly that's not something I want our users to have to care about.<br>
>>><br>
>>> How would you differentiate between "deployment" in a generic sense in<br>
>>> contrast to a generic workflow?<br>
>>><br>
>>> Every deployment I can think of involves a series of steps, involving some<br>
>>> choices and interactions with other services.  That *is* a workflow?<br>
>><br>
>> Well, I mean if we want to take this to extremes then pretty much every<br>
>> API is a workflow API.  You make a REST call, a "workflow" happens in<br>
>> the service, and you get back a result.<br>
>><br>
>> Let me turn this around: Would you implement Heat's API on Mistral?  All<br>
>> that happens when I call Heat is that a series of OpenStack calls are<br>
>> made from heat-engine, after all.  Or is that a gross oversimplification<br>
>> of what's happening?  I could argue that the same is true of this<br>
>> discussion. :-)<br>
><br>
> As Hugh has mentioned the main thing Heat does is actually manage<br>
> dependencies.  It processes the templates, builds a graph, then walks the<br>
> graph running a "workflow" to create/update/delete/etc each resource.<br>
><br>
> I could imagine a future where we interface to some external workflow tool to<br>
> e.g do each resource action (e.g create a nova server, poll until it's active),<br>
> however that's actually a pretty high overhead approach, and it'd probably<br>
> be better to move towards better use of notifications instead (e.g less<br>
> internal workflow)<br>
><br>
>>>> 3) It ties us 100% to a given implementation.  If Mistral proves to be a<br>
>>>> poor choice for some reason, or insufficient for a particular use case,<br>
>>>> we have no alternative.  If we have an API and decide to change our<br>
>>>> implementation, nobody has to know or care.  This is kind of the whole<br>
>>>> point of having an API - it shields users from all the nasty<br>
>>>> implementation details under the surface.<br>
>>><br>
>>> This is a valid argument, but building (and maintining, forever) a bespoke<br>
>>> API is a high cost to pay for this additional degree of abstraction, and<br>
>>> when you think of the target audience, I'm not certain it's entirely<br>
>>> justified (or, honestly, if our community can bear that overhead);<br>
>>><br>
>>> For example, take other single-purpose "deployment" projects, such as<br>
>>> Sahara, Magnum, perhaps Trove.  These are designed primarily as user-facing<br>
>>> API's, where the services will ultimately be consumed by public and private<br>
>>> cloud customers.<br>
>>><br>
>>> Contrast with TripleO, where our target audience is, for the most part,<br>
>>> sysadmins who deploy and maintain an openstack deployment over a long<br>
>>> period of time.  There are two main groups here:<br>
>>><br>
>>> 1. PoC "getting started" folks who need a very simple on-ramp (generalizing<br>
>>> somewhat, the audience for the opinionated deployments driven via UI's)<br>
>>><br>
>>> 2. Seasoned sysadmins who want plugability, control and flexibility above<br>
>>> all else (and, simplicity and lack of extraneous abstractions)<br>
>>><br>
>>> A bespoke API potentially has a fairly high value to (1), but a very low or<br>
>>> even negative value to (2).  Which is why this is turning out to be a tough<br>
>>> and polarized discussion, unfortunately.<br>
>><br>
>> Well, to be honest I'm not sure we can satisfy the second type of user<br>
>> with what we have today anyway.  Our Heat-driven puppet is hardly<br>
>> lightweight or simple, and there are extraneous abstractions all over<br>
>> the place (see also every place that we have a Heat template param that<br>
>> exists solely to get plugged into a puppet hiera file :-).<br>
>><br>
>> To me, this is mostly an artifact of the original intent of the Heat<br>
>> templates being _the_ abstraction that would then be translated into<br>
>> os-*-config, puppet, or [insert deployment tool of choice] by the<br>
>> templates, and I have to admit I'm not sure how to fix it for these users.<br>
><br>
> I think we fix it by giving them a choice.  E.g along the lines of the<br>
> "split stack" approach discussed at summit - allow operators to choose<br>
> either pre-defined roles with known interfaces (parameters), or deploy just<br>
> the infrastructure (servers, networking, maybe storage) then drive<br>
> configuration tooling with a much thinner interface.<br>
<br>
</div></div>I agree, I'm a big fan of the split stack idea to address this problem.<br>
 I don't see that it matters for the API though.  Those power users are<br>
going to use the API only as far as deploying the infrastructure, then<br>
they're going to do their own thing from there.<br>
<div><div class="h5"><br>
><br>
>> So I guess the question is, how does having an API hurt those power<br>
>> users?  They'll still be able/have to edit Heat templates to deploy<br>
>> additional services.  They'll still have all the usual openstack clients<br>
>> to customize their Ironic or Nova setups.  They're already using an API<br>
>> today, it's just one written entirely in the client.<br>
><br>
> There's already a bunch of opaque complexity inside the client and TripleO<br>
> common, adding a very rigid API makes it more opaque, and harder to modify.<br>
><br>
>> On the other hand, an API that can help guide a user through the deploy<br>
>> process (You say you want network isolation enabled?  Well here are the<br>
>> parameters you need to configure...) could make a huge difference for<br>
>> the first type of user, as would _any_ API usable by the GUI (people<br>
>> just like pretty GUIs, whether it's actually better than the CLI or not :-).<br>
>><br>
>> I guess it is somewhat subjective as you say, but to me the API doesn't<br>
>> significantly affect the power user experience, but it would massively<br>
>> improve the newbie experience.  That makes it a win in my book.<br>
><br>
> I agree 100% that we need to massively improve the newbie experience - I<br>
> think everybody does.  I also think we also all agree there must be a<br>
> stable, versioned API that a UI/CLI can interact with.<br>
><br>
> The question in my mind is, can we address that requirement *and* provide<br>
> something of non-negative value for developers and advanced operators.<br>
><br>
> Ryan already commented earlier in this thread (and I agree having seen<br>
> Dan's most recent PoC in action) that it doesn't make a lot of difference<br>
> from a consumer-of-api perspective which choice we make in terms of APi<br>
> impelementation, either approach can help provide the stable API surface<br>
> that is needed.<br>
<br>
</div></div>The problem is I don't see this being true.  We're apparently already<br>
having to change our API and add steps to accommodate the limitations of<br>
the Mistral approach.  This is just trying to duplicate the<br>
functionality we have today, never mind improving on it.<br>
<span class=""><br>
><br>
> The main difference is, only one choice provides any flexibility at all wrt<br>
> operator customization (unless we reinvent a similar action plugin mechanism<br>
> inside a TripleO API).<br>
<br>
</span>Handing people our code and saying "go ahead and make any changes you<br>
want to this, and don't worry we'll still support your upgrade path when<br>
the next release comes out" doesn't seem like a sustainable model to me.<br>
 The more ad-hoc customization we allow, the worse our encapsulation is<br>
and the more difficult it becomes to guarantee people's cloud will still<br>
work from version to version.  Honestly, we _do_ need a well-defined set<br>
of extension points that people can attach to and that we guarantee will<br>
still be there and functional from release to release.<br>
<br>
If we're incapable of doing that as a community then I think we've<br>
failed anyway.  There's too much ongoing cost to exposing all of your<br>
implementation details the way we do today.<br>
<div><div class="h5"><br>
><br>
>>>> 4) It raises the bar even further for both new deployers and developers.<br>
>>>>  You already need to have a pretty firm grasp of Puppet and Heat<br>
>>>> templates to understand how our stuff works, not to mention a decent<br>
>>>> understanding of quite a number of OpenStack services.<br>
>>><br>
>>> I'm not really sure if a bespoke WSGI app vs an existing one (mistral)<br>
>>> really makes much difference at all wrt raising the bar.  I see it<br>
>>> primarily as in implementation detail tbh.<br>
>><br>
>> I guess that depends.  Most people in OpenStack already know at least<br>
>> some Python, and if you've done any work in the other projects there's a<br>
>> fair chance you are familiar with the Python clients.  How many people<br>
>> know Mistral YAML?<br>
><br>
> So, I think you're conflating the OpenStack developer community (who,<br>
> mostly, know python), with end-users and Operators, where IME the same is<br>
> often not true.<br>
><br>
> Think of more traditional enterprise environments - how many sysadmins on<br>
> the unix team are hardcore python hackers?  Not that many IME (ignoring<br>
> more devops style environments here).<br>
><br>
>> Maybe I'm overestimating the Python knowledge in the community, and<br>
>> underestimating the Mistral knowledge, but I would bet we're talking<br>
>> order(s?) of magnitude in terms of the difference.  And I'm not saying<br>
>> learning Mistral is a huge task on its own, but it's one more thing in a<br>
>> project full of one more things.<br>
><br>
> It's one more thing, which is already maintained and has an active<br>
> community, vs yet-another-bespoke-special-to-tripleo-thing.  IMHO we have<br>
> *way* too many tripleo specific things already.<br>
><br>
> However, lets look at the "python knowledge" thing in a bit more detail.<br>
><br>
> Let's say, as an operator I want to wire in a HTTP call to an internal asset<br>
> management system.  The requirement is to log an HTTP call with some<br>
> content every time an overcloud is deployed or updated.  (This sort of<br>
> requirement is *very* common in enterprise environments IME)<br>
><br>
> In the mistral case[1], the modification would look something like:<br>
><br>
> http_task:<br>
>   action: std.http url='<a href="http://assets.foo.com" rel="noreferrer" target="_blank">assets.foo.com</a>' <some arguments><br>
<br>
</div></div>requests.get('<a href="http://assets.foo.com" rel="noreferrer" target="_blank">assets.foo.com</a>', data={'some':'arguments'})<br>
<br>
Either way you have to go look up the exact API to figure out how to<br>
make the call the way you need.<br>
<span class=""><br>
><br>
> You'd simply add two lines to your TripleO deployment workflow yaml[2]:<br>
><br>
> Now, consider the bespoke API case.  You have to do some or all of the<br>
> following:<br>
><br>
> - Find the python code which handles deployment and implements the workflow<br>
<br>
</span>-Find the Mistral YAML which handles deployment and implements the workflow.<br>
<span class=""><br>
> - Pull and fork the code base, resolve any differences between the upstream<br>
>   version and whatever pacakged version you're running<br>
<br>
</span>-I'm not sure why you would rebase on upstream.<br>
<span class=""><br>
> - Figure out how to either hack in your HTTP calls via a python library, or<br>
>   build a new plugin mechanism to enable out-of-tree deployment hooks<br>
<br>
</span>-As noted above, it's not exactly difficult.  If you know neither<br>
Mistral nor Python, you're learning a new API either way.  Except one is<br>
way more broadly useful.<br>
<span class=""><br>
> - Figure out a bunch of complex stuff to write unit tests, battle for<br>
>   weeks/months to get your code accepted upstream (or, maintain the fork<br>
>   forever and deal with rebasing, packaging, and the fact that your entire<br>
>   API is no longer supported by your vendor because you hacked on it)<br>
<br>
</span>-Or we could design a decent API where users don't have to hack up our<br>
"code" to do what they need.  If this is so common, why isn't it just<br>
part of the deployment API?<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Which of these is most accessible to a traditional non-python-ninja<br>
> sysadmin?<br>
><br>
> [1] <a href="http://docs.openstack.org/developer/mistral/dsl/dsl_v2.html#std-http" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/mistral/dsl/dsl_v2.html#std-http</a><br>
> [2] <a href="https://github.com/dprince/tripleo-common/blob/mistral/workflows/overcloud_deploy.yaml" rel="noreferrer" target="_blank">https://github.com/dprince/tripleo-common/blob/mistral/workflows/overcloud_deploy.yaml</a><br>
><br>
<br>
<br>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>