Hello, Stackers.
I’d like to propose policy for configuration option deprecation taking into account all requirements related to production deployment. As you all know, there are a lot patches that are proposing modifications to existing configuration. And options are being modified without any(not always) documentation that reflects differences behaviour with old and new options. What we’re doing right now doesn’t seems to be the most valid way, we shouldn’t delete options without any signs (DocImpact section, at least). We should find more appropriate way to handle such cases, the most appropriate way to handle given case is to use oslo-config abilities - mark option as “Deprecated”. Here’s proposed workflow for modifications. Once option is being modified: 1. Leave option that is going to be modified as is, add Deprecated flag. Clean-up code from usage from deprecated option. 2. Add new option. Add usage to existing code as substitution to previous option. 3. Add documentation that reflects differences between options: new and deprecated one. 4. Add documentation that reflects behaviour of existing code with new option. Thoughts? Best regards, Denis Makogon
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev