Open Stack

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 <sean at dague.net> 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141114/20db6723/attachment.html>