On Mon, Jan 25, 2016 at 9:09 AM, Jiri Tomasek <jtoma...@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 --
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
