Open Stack

On Wed, Jan 13, 2016 at 02:16:44PM -0500, Dan Prince wrote:
> On Tue, 2016-01-12 at 20:47 +0000, Steven Hardy wrote:
> > Hi all,
> > 
> > I've noticed that we have a fairly large number of unused parameters
> > in
> > t-h-t, some of which are marked deprecated, some aren't.
> > 
> > Since we moved tripleoclient to use parameter_defaults everywhere, I
> > think
> > it should be safe to remove these unused parameters, even in
> > overcloud.yaml.
> > 
> > See:
> > 
> > https://review.openstack.org/#/c/227057/
> > 
> > https://review.openstack.org/#/c/227057/
> > 
> > Since those, we can pass removed/deprecated parameters from the
> > client and
> > they will be ignored, even if they're removed from the template
> > (unlike if
> > you use "parameters", where a validation error would occur.
> > 
> > I'd like to go ahead and clean these up (only on the master branch),
> > is
> > that reasonable?  We can document the change via a mitaka release
> > note?
> 
> This sounds fine to me.
> 
> > 
> > Ideally, we'd have user-visible warnings for a deprecation period,
> > but
> > there's no way to output such warnings atm via heat, so we'd need to
> > wire
> > them in via tripleoclient or tripleo-common, which seems a bit
> > backwards
> > given that we can just remove the parameters there instead.
> > 
> > Thoughts?
> 
> Adding some sort of deprecation mechanism to Heat proper, perhaps an
> async way to communicate back to the end users that the parameters
> being used are deprecated would be the nicest option I think.

Yeah, this was discussed at summit and is definitely something we should
look into.

> Give lack of that would could design something into tripleo-common to
> do this, but it would require parsing all of the parameters, and
> environments before sending them off to Heat which seems to duplicate
> things. Not my favorite place for the functionality to live but it
> could be doable in tripleo-common I think as an additional deployment
> workflow step.
> 
> Perhaps one thing that might make sense is to create a
> deprecated_params.txt file somewhere to track these for each release
> cycle? Maybe this lives in t-h-t? I'm not sure we get a lot of value
> out of maintaining this though unless we intend to test for deprecated
> parameters in some fashion and display them during the deployment
> workflow.

Another option would be to add deprecated parameters to a parameter group
in the template, then it becomes easy for any client/common code to output
a warning when these are passed in parameter_defaults?

Regardless, it sounds like we have a consensus that it's OK to remove the
currently unused parameters (because we're pretty confident the only
consumer of these is tripleoclient atm), but in future we need to put in
place a more robust deprecation method?

If that's correct, I'll go ahead and propose a series of patches which
removes the currently unused parameters.

Thanks,

Steve