Open Stack

On Mon, Jan 25, 2016 at 9:09 AM, Jiri Tomasek <jtomasek at redhat.com> wrote:

> On 01/25/2016 12:42 AM, Clint Byrum wrote:
>
>> Excerpts from Dan Prince's message of 2016-01-22 16:19:07 -0800:
>>
>
>> I actually think rather than shielding users we should be more
>>> transparent about the actual workflows that are driving deployment.
>>> Smaller more focused workflows that we string together to drive the
>>> deployment.
>>>
>>> I tend to agree, especially when your workflows may need to be
>> customized.
>>
>
> Customizing underlining deployment workflows is IMO potentially very
> dangerous regarding updates etc. and should be avoided as much as possible.


​+1 to Jiri.

I was in the process of replying about the same point :).

It should not be the intent that TripleO *users* or *operators* are
encouraged or supported to edit the implementation, whether it be yaml
workflows or python code. If it is, then we've failed at building a stable
interface.

If we go with a workflow tool that is backed by yaml defined workflows,
then those workflows are implementations of an abstraction. In the same way
that python code is an implementation of a Restful API if we did a new
TripleO API. As a user, no one would have the expectation that editing that
python code is encouraged or supported. It ought to be the same with the
yaml workflows if we go that route -- they aren't meant to be modified by
users/operators.

We have direct experience with this already...tripleo-heat-templates. We
have kind of tried to define a "stable" interface around a pile of yaml
files already, and more or less failed. We know that we can't provide
reliable updates/upgrades if we don't know how the templates have been
modified. There could be many reasons for this: we weren't disciplined
enough in code reviews to keep from breaking ourselves, we lack the
knowledge to recognize a breaking change in the templates, or just
generally that it's really not well known/accepted how to even build a
stable interface around yaml files. Whereas, it's quite universally well
known and understood how to build stable REST API's.

So whether the API is a new TripleO Rest API, or the Mistral Rest API, I
hope we can agree that the API is the stable part, and the implementation
is not meant to be edited by users.

If we can't agree on that, then we aren't even really discussing the same
point IMO. As it's not really a question of which is the better tool,
TripleO API / Mistral / Ansible, it's actually a question of "how is
TripleO meant to be used".


-- 
-- James Slagle
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160125/fabceee1/attachment.html>