Open Stack

On Mon, Jan 25, 2016 at 1:09 PM, Dan Prince <dprince at redhat.com> wrote:

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

​I think it has a lot less to do with that then it may appear on the
surface. Even if we had 100% functional test coverage of upgrade paths,
that does nothing to solve for scenarios where the templates have been so
heavily customized that stack updates can not be guaranteed to work, or
worse, destroy the cloud.

The most we could do in those scenarios is better detection around what
stack changes are going to be done by an update before anything is actually
applied. And if something is going to be destructive or is not expected, we
refuse to proceed. That would definitely help us as developers to know if
our own changes are breaking upgrades.

But, that doesn't really help the user get their cloud upgraded if they've
customized templates themselves, other than they know that they must undo
whatever custom changes they made, and if they made those for valid reasons
and can't undo, then they are stuck.

They've taken what may appear as a "feature" of the system -- customizing
templates to add support for new things -- and turned it into an
anti-feature, now they can't upgrade without writing upgrade support for
whatever they added themself. Perhaps having to undo new features we as
TripleO developers added for users in the first place.

I don't think that's a supportable path for users of TripleO, nor
sustainable as a community, so editing templates should be advertised as
unsupported.
​


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


Agreed, we can't deter anyone from editing python anymore than we could
yaml.

But it's not about dictating what people do. It's about what we support as
a project for users and operators. This is something we can define very
clearly so that users aren't surprised. At least they would have some way
of knowing if they are using the system as intended.

I don't think we should support/encourage editing the yaml workflows by end
users if ​we choose a yaml based workflow tool, any more than we should
support editing python code by users if we wrote our own REST API.

It's not clear to me in this discussion when the argument about yaml files
being easier to edit so Mistral/Ansible is a better choice...if we're
talking about developers editing yaml files, or users editing yaml files.

If it's the former (developers), I agree it's a benefit for us.

If it's the latter (users), then personally I don't see that as a valid
argument at all since I view it as something we should never do.



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


​To be clear, are you saying we should have a stable API, and then support
users in editing the implementation of that API (yaml workflows)?​

For example, we have a stable API such as:

POST /workbooks/deploy-cloud/executions

that might do totally different things across deployed TripleO clouds of
the same released version, depending on how the user has customized the
deploy-cloud workbook?

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