
<!DOCTYPE html>

<html>

<head>

<title></title>

</head>

<body><div> </div>

<div> </div>

<div> </div>

<div>On Tue, May 17, 2016, at 03:00 PM, Dolph Mathews wrote:<br></div>

<blockquote type="cite"><div dir="ltr"><div>I think the metadata_manager is one of many terrible examples of deprecated configuration options. The documentation surrounding a deprecation should *always* tell you why something is being deprecated, and what you should be using instead to achieve the same, or better, result moving forward. But instead, we get "you don't need to see any documentation... these aren't the configs you're looking for."<br></div>

</div>

</blockquote><div> </div>

<div>In this case there is no replacement to point towards, Nova is just removing a plug point. But it is fair to say that the reasoning behind the removal should be captured in the comment there.</div>

<div> </div>

<blockquote type="cite"><div dir="ltr"><div> </div>

<div>If all our deprecated config options provided useful pointers in their descriptions, there would be tremendous value in retaining deprecated configuration options in sample config files -- in which case, I don't believe we would be having this conversation which questions their value in the first place.<br></div>

</div>

</blockquote><div> </div>

<div>If config sample files are being used as a living document then that would be a reason to leave the deprecated options in there. In my experience as a cloud deployer I never once used them in that manner so it didn't occur to me that people might, hence my question to the list.<br></div>

<div> </div>

<div>This may also indicate that people aren't checking release notes as we hope they are. A release note is where I would expect to find this information aggregated with all the other changes I should be aware of. That seems easier to me than aggregating that data myself by checking various sources.<br></div>

<div> </div>

<div>Anyways, I have no strong cause for removing the deprecated options. I just wondered if it was a low hanging fruit and thought I would ask.<br></div>

<div> </div>

<div> </div>

<div> </div>

<blockquote type="cite"><div> </div>

<div defang_data-gmailquote="yes"><div dir="ltr">On Tue, May 17, 2016 at 1:49 PM Andrew Laski <<a href="mailto:andrew@lascii.com">andrew@lascii.com</a>> wrote:<br></div>

<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;" defang_data-gmailquote="yes"><div><div> <br></div>

<div> <br></div>

<div> <br></div>

<div>On Tue, May 17, 2016, at 02:36 PM, Matt Fischer wrote:<br></div>

<blockquote type="cite"><div dir="ltr"><div><div><div>On Tue, May 17, 2016 at 12:25 PM, Andrew Laski <span dir="ltr"><<a href="mailto:andrew@lascii.com">andrew@lascii.com</a>></span> wrote:<br></div>

<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div>I was in a discussion earlier about discouraging deployers from using<br></div>

<div>deprecated options and the question came up about why we put deprecated<br></div>

<div>options into the sample files generated in the various projects. So, why<br></div>

<div>do we do that?<br></div>

<div> <br></div>

<div>I view the sample file as a reference to be used when setting up a<br></div>

<div>service for the first time, or when looking to configure something for<br></div>

<div>the first time. In neither of those cases do I see a benefit to<br></div>

<div>advertising options that are marked deprecated.<br></div>

<div> <br></div>

<div>Is there some other case I'm not considering here? And how does everyone<br></div>

<div>feel about modifying the sample file generation to exclude options which<br></div>

<div>are marked with "deprecated_for_removal"?<br></div>

<div> <br></div>

</blockquote><div> <br></div>

<div> <br></div>

<div>Can you clarify what you mean by having them? The way they are now is great for deployers I think and people (like me) who work on things like puppet and need to update options sometimes. For example, I like this way, example from keystone:<br></div>

<div> <br></div>

<div><div># Deprecated group/name - [DEFAULT]/log_config<br></div>

<div>#log_config_append = <None><br></div>

</div>

<div> <br></div>

<div>Are you proposing removing that top line?<br></div>

</div>

</div>

</div>

</blockquote><div> <br></div>

</div>

<div><div>That is a different type of deprecation which I didn't do a great job of distinguishing.<br></div>

<div> <br></div>

<div>There is deprecation of where a config option is defined, as in your example. I am not proposing to touch that at all. That simply indicates that a config option used to be in a different group or used to be named something else. That's very useful.<br></div>

<div> <br></div>

<div>There is deprecation of a config option in the sense that it is going away completely. An example would be:<br></div>

<div> <br></div>

<div># DEPRECATED: OpenStack metadata service manager (string value)<br></div>

<div># This option is deprecated for removal.<br></div>

<div># Its value may be silently ignored in the future.<br></div>

<div>#metadata_manager = nova.api.manager.MetadataManager<br></div>

<div> <br></div>

<div>I'm wondering if anyone sees a benefit to including that in the sample file when it is clearly not meant for use.<br></div>

</div>

<div><div> <br></div>

<div> <br></div>

<blockquote type="cite"><div><u>__________________________________________________________________________</u><br></div>

<div>OpenStack Development Mailing List (not for usage questions)<br></div>

<div>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br></div>

<div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div>

</blockquote><div> <br></div>

</div>

<div>__________________________________________________________________________<br></div>

<div> OpenStack Development Mailing List (not for usage questions)<br></div>

<div> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br></div>

<div> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div>

</blockquote></div>

<div dir="ltr">-- <br></div>

<div dir="ltr">-Dolph<br></div>

<div><u>__________________________________________________________________________</u><br></div>

<div>OpenStack Development Mailing List (not for usage questions)<br></div>

<div>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br></div>

<div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div>

</blockquote><div> </div>

</body>

</html>