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