[openstack-dev] [TripleO] Should we have a TripleO API, or simply use Mistral?
dprince at redhat.com
Mon Jan 25 18:09:42 UTC 2016
On Mon, 2016-01-25 at 09:32 -0500, James Slagle wrote:
> On Mon, Jan 25, 2016 at 9:09 AM, Jiri Tomasek <jtomasek at redhat.com>
> > 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.
Here is an example of a versioned YAML workflow in Mistral:
Basically what I'm suggesting is that we name our workflows like this:
I would actually call this a stable API that is implemented within a
generic workflow tool (which also has its own stable API).
As for tripleo-heat-templates... sure it hasn't been an entirely smooth
ride. I think a lot of the pain has to do with a lack of CI coverage on
proper upgrade paths upstream. I think this has less to do with the
architecture (certainly not the fact that it uses YAML) and more to do
with the fact that we may have cut corners, jammed a bunch of features
in really fast, and don't have CI to cover proper upgrades jobs.
The fact that projects like Heat, Mistral, and Ansible use YAML is to
our advantage as developers. I think it allows us to work faster by
avoiding rather large amounts of code to represent the same sorts of
things. Please, lets not argue that by writing things in Python we
deter end users from editing things we don't want them too. Instead let
the choice be ours... not as Python developers... but as TripleO
deployment developers who choose the write tools for the right jobs.
> 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.
We do totally agree on the stable API part. :)
> 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".
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
More information about the OpenStack-dev