openstack team mailing list archive

["Kevin L. Mitchell" <kevin.mitchell@xxxxxxxxxxxxx>]

On Tue, 2012-06-12 at 15:50 -0400, Sean Dague wrote:
> Here's my current suggested path forward, which I'd like comments on:
>   * keep the existing nova.utils deprecation functions (don't remove them)

As the author of nova.utils.deprecated, I approve :)

>   * add the fatal config option, and associated unit tests to make sure 
> it works correctly. This would be helpful for people to ensure they 
> weren't depending on deprecated functions towards the end of a release.

That makes sense to me.

>   * possibly move them to nova.common as they might make for good 
> openstack-common material down the road

I created the @deprecated decorator just as openstack-common was getting
started, and I always considered it a perfect candidate for
openstack-common.  I wonder if this is an interface that should skip the
"incubation" state, though, and be used as a library?

>   * use this instead of the direct LOG.error in get_connection
> 
> This would have the side effect of making the message warning level, 
> instead of error level, which I think is fine at this point.

*nod*

I'll take an opportunity to comment on the motivation behind adding
@deprecated.  I was doing some extensive changes to the openstack API
infrastructure at the time, and the old calls were used all over the
place.  I wanted the old interface to continue to function, but to
generate warnings that would be easy to find in the logs, so that I
could change out one piece at a time without totally breaking
everything.  This seemed like something that others would also need to
do, probably regularly.

I also had considered the N/N+1 issue with releases: one of the
disadvantages of a plugin-supporting system like nova is that the
primary developers don't have control of all the code.  We need to have
a way to warn third party developers that the interfaces they use are
about to go away, before they actually do.  That unfortunately means
we'll be looking at even more complex code in the future, to cover all
the N/N+1 issues, but I don't really think we can avoid that if we want
people to actually use nova.
-- 
Kevin L. Mitchell <kevin.mitchell@xxxxxxxxxxxxx>