Open Stack

On Mon, 2016-01-25 at 15:08 -0500, James Slagle wrote:
> 
> 
> 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.

Its the former. YAML is primarily a benefit for us as developers. And
to go back to my original statement my preference would be that we
develop them as a set of smaller more focused workflows that are more
transparent to the end user such that they know what will happen when
they get executed.

> 
> 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)?

What I was agreeing to was the desire to maintain a set of stable
workflows that we support. Be it in the form of a generic workflow API
(my preference) or an API that we build up from scratch. Regardless of
choice the goal would be to create stable workflows that could be
versioned so as not to pull the rug on previous implementations.

> 
> 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
> --
> _____________________________________________________________________
> _____
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubs
> cribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev