Re: [openstack-dev] [TripleO] Removing unused/deprecated template parameters?

2016-01-14 Thread Steven Hardy 
On Wed, Jan 13, 2016 at 02:16:44PM -0500, Dan Prince wrote:
> On Tue, 2016-01-12 at 20:47 +, 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

__
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

Re: [openstack-dev] [TripleO] Removing unused/deprecated template parameters?

2016-01-13 Thread Jiri Tomasek 

On 01/13/2016 10:33 AM, Juan Antonio Osorio wrote:

IIRC some of them were already marked (via a comment) as deprecated.

+1 to cleaning up the parameters. I think it should be done as soon as 
possible, as the existence of some of them makes the usage of the 
templates quite confusing.


BR

On Tue, Jan 12, 2016 at 10:47 PM, 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?

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?

Steve

__
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




--
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com 



__
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


+1 IUC this will reduce the number of parameters returned by nested heat 
validate, which is a good thing as those parameters confuse user.


Jirka
__
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

Re: [openstack-dev] [TripleO] Removing unused/deprecated template parameters?

2016-01-13 Thread Juan Antonio Osorio 
IIRC some of them were already marked (via a comment) as deprecated.

+1 to cleaning up the parameters. I think it should be done as soon as
possible, as the existence of some of them makes the usage of the templates
quite confusing.

BR

On Tue, Jan 12, 2016 at 10:47 PM, 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?
>
> 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?
>
> Steve
>
> __
> 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
>



-- 
Juan Antonio Osorio R.
e-mail: jaosor...@gmail.com
__
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

Re: [openstack-dev] [TripleO] Removing unused/deprecated template parameters?

2016-01-13 Thread Dan Prince 
On Tue, 2016-01-12 at 20:47 +, 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

[openstack-dev] [TripleO] Removing unused/deprecated template parameters?

2016-01-12 Thread Steven Hardy 
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?

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?

Steve

__
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