Open Stack

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.

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.

Dan


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