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

/me missed this in his previous reply

Its both.

For the latter we want our architecture to be something that users can
"contribute" to. All edits aren't bad. One example: There are some
cases today where we designed our templates as examples (potentially
needing edits). The network configuration templates are an example
here. No harm in adding an extra NIC to a bond or this sort of thing if
the operator/user knows that is how they need to manage their physical
hardware. The smart operator would perhaps build an automatic tool to
help generate these sorts of templates. And perhaps we need a tool to
help generate/validate these templates... but today the lay of the land
is it is okay to customize some of these templates because they were in
fact designed to be customized (os-net-config, etc.)

Dan

> 
>  
> >  >
> > > 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
> --
> _____________________________________________________________________
> _____
> 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