FYI, I've forwarded this thread to the operators mailing list as I feel they will be very much interested by this discussion. BR Simon
On Fri, Nov 14, 2014 at 1:37 AM, Sean Dague <[email protected]> wrote: > On 11/13/2014 06:56 PM, Clint Byrum wrote: > > Excerpts from Ben Nemec's message of 2014-11-13 15:20:47 -0800: > >> On 11/10/2014 05:00 AM, Daniel P. Berrange wrote: > >>> On Mon, Nov 10, 2014 at 09:45:02AM +0000, Derek Higgins wrote: > >>>> Tl;dr oslo.config wasn't logging warnings about deprecated config > >>>> options, do we need to support them for another cycle? > >>> AFAIK, there has not been any change in olso.config behaviour > >>> in the Juno release, as compared to previous releases. The > >>> oslo.config behaviour is that the generated sample config file > >>> contain all the deprecation information. > >>> > >>> The idea that olso.config issue log warnings is a decent RFE > >>> to make the use of deprecated config settings more visible. > >>> This is an enhancement though, not a bug. > >>> > >>>> A set of patches to remove deprecated options in Nova was landed on > >>>> Thursday[1], these were marked as deprecated during the juno dev cycle > >>>> and got removed now that kilo has started. > >>> Yes, this is our standard practice - at the start of each release > >>> cycle, we delete anything that was marked as deprected in the > >>> previous release cycle. ie we give downstream users/apps 1 release > >>> cycle of grace to move to the new option names. > >>> > >>>> Most of the deprecated config options are listed as deprecated in the > >>>> documentation for nova.conf changes[2] linked to from the Nova upgrade > >>>> section in the Juno release notes[3] (the deprecated cinder config > >>>> options are not listed here along with the allowed_direct_url_schemes > >>>> glance option). > >>> The sample nova.conf generated by olso lists all the deprecations. > >>> > >>> For example, for cinder options it shows what the old config option > >>> name was. > >>> > >>> [cinder] > >>> > >>> # > >>> # Options defined in nova.volume.cinder > >>> # > >>> > >>> # Info to match when looking for cinder in the service > >>> # catalog. Format is: separated values of the form: > >>> # <service_type>:<service_name>:<endpoint_type> (string value) > >>> # Deprecated group/name - [DEFAULT]/cinder_catalog_info > >>> #catalog_info=volume:cinder:publicURL > >>> > >>> Also note the deprecated name will not appear as an option in the > >>> sample config file at all, other than in this deprecation comment. > >>> > >>> > >>>> My main worry is that there were no warnings about these options being > >>>> deprecated in nova's logs (as a result they were still being used in > >>>> tripleo), once I noticed tripleo's CI jobs were failing and discovered > >>>> the reason I submitted 4 reverts to put back the deprecated options in > >>>> nova[4] as I believe they should now be supported for another cycle > >>>> (along with a fix to oslo.config to log warnings about their use). > The 4 > >>>> patches have now been blocked as they go "against our deprecation > policy". > >>>> > >>>> I believe the correct way to handle this is to support these options > for > >>>> another cycle so that other operators don't get hit when upgrading to > >>>> kilo. While at that same time fix oslo.config to report the deprecated > >>>> options in kilo. > >>>> I have marked this mail with the [all] tag because there are other > >>>> projects using the same "deprecated_name" (or "deprecated_group") > >>>> parameter when adding config options, I think those projects also now > >>>> need to support their deprecated options for another cycle. > >>> AFAIK, there's nothing different about Juno vs previous release cycles, > >>> so I don't see any reason to do anything different this time around. > >>> No matter what we do there is always a possibility that downstream > >>> apps / users will not notice and/or ignore the deprecation. We should > >>> certainly look at how to make deprecation more obvious, but I don't > >>> think we should change our policy just because an app missed the fact > >>> that these were deprecated. > >> So the difference to me is that this cycle we are aware that we're > >> creating a crappy experience for deployers. In the past we didn't have > >> anything in the CI environment simulating a real deployment so these > >> sorts of issues went unnoticed. IMHO telling deployers that they have > >> to troll the sample configs and try to figure out which deprecated opts > >> they're still using is not an acceptable answer. > >> > > I don't know if this is really fair, as all of the deprecated options do > > appear here: > > > > > http://docs.openstack.org/juno/config-reference/content/nova-conf-changes-juno.html > > > > So the real bug is that in TripleO we're not paying attention to the > > appropriate stream of deprecations. Logs on running systems is a mighty > > big hammer when the documentation is being updated for us, and we're > > just not paying attention in the right place. > > > > BTW, where SHOULD continuous deployers pay attention for this stuff? > > > >> Now that we do know, I think we need to address the issue. The first > >> step is to revert the deprecated removals - they're not hurting > >> anything, and if we wait another cycle we can fix oslo.config and then > >> remove them once deployers have had a reasonable chance to address the > >> deprecation. > >> > > In this case, we can just fix the templates. Are we broken? Yes. Can we > > fix it? YES! I would definitely appreciate the reverts preceding that, > > so that we can land other things without having to pin Nova, but we can > > deal if that isn't an option. > > > > If we can ask that projects use 'check experimental' whenever they remove > > anything deprecated and take the failures seriously, that will help with > > this. We're trying our best to come up with good policies to keep up, > > but sometimes we fall behind or, in this case, had no good policy for > > keeping up. > > > >> This is one of the big reasons we want to have a deployment program > >> upstream. It surfaces these sorts of shortcomings in a way that > >> probably wouldn't have happened before. I think it would be a shame if > >> we ignore that because "we've always done it that way." > >> > > Thanks Ben, that is indeed why we are still very much interested in > > having TripleO in the integrated gate some day. That said, if we can't > > keep up with the stream of config changes needed, we'll just be a thorn > > in the side of each project that wants to move forward. So we need to > > get better at keeping up with the times. > I also think that there was a fall through the cracks with deprecation > functionality moving into oslo. I know when I wrote a lot of that for > Nova we were really verbose about deprecations (some times too much so). > Testing that anything using deprecation functionality in oslo generates > log streams would be really good. > > -Sean > > -- > Sean Dague > http://dague.net > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
