Open Stack

On 10/12/15 08:21 -0600, Brant Knudson wrote:
>
>
>On Thu, Dec 10, 2015 at 7:26 AM, Sean Dague <sean at dague.net> wrote:
>
>    On 12/10/2015 01:56 AM, Joshua Harlow wrote:
>    > Shouldn't be to hard (although it's probably not on each oslo project,
>    > but on the consumers projects).
>    >
>    > The warnings module can turn warnings into raised exceptions with a
>    > simple command line switch btw...
>    >
>    > For example:
>    >
>    > $ python -Wonce
>    > Python 2.7.6 (default, Jun 22 2015, 17:58:13)
>    > [GCC 4.8.2] on linux2
>    > Type "help", "copyright", "credits" or "license" for more information.
>    >>>> import warnings
>    >>>> warnings.warn("I am not supposed to be used", DeprecationWarning)
>    > __main__:1: DeprecationWarning: I am not supposed to be used
>    >
>    > $ python -Werror
>    > Python 2.7.6 (default, Jun 22 2015, 17:58:13)
>    > [GCC 4.8.2] on linux2
>    > Type "help", "copyright", "credits" or "license" for more information.
>    >>>> import warnings
>    >>>> warnings.warn("I am not supposed to be used", DeprecationWarning)
>    > Traceback (most recent call last):
>    >   File "<stdin>", line 1, in <module>
>    > DeprecationWarning: I am not supposed to be used
>    >
>    > https://docs.python.org/2/library/warnings.html#the-warnings-filter
>    >
>    > Turn that CLI switch from off to on and I'm pretty sure usage of
>    > deprecated things will become pretty evident real quick ;)
>
>    It needs to be more targetted than that. There is a long standing
>    warning between paste and pkg_resources that would hard stop everyone.
>
>    But, yes, the idea of being able to run unit tests with fatal
>    deprecations of oslo easily is what I think would be useful.
>   
>            -Sean
>
>
>
>In keystone we set a warnings filter for the unit tests so that if keystone
>calls any deprecated function it'll raise[1]. So when the oslo timeutils
>functions were deprecated it broke keystone gate and we fixed it. It would be
>nicer to have a non-voting gate job to serve as a warning instead, but it's
>only happened a couple of times where this caused keystone to be blocked for
>the day that it took to get the fix in. Anyways, it would be easy enough for us
>to have this enabled/disabled via an environment variable and create a tox job.
>
>If we had a non-voting warning job it could also run oslo libs from master
>rather than released.
>
>[1] http://git.openstack.org/cgit/openstack/keystone/tree/keystone/tests/unit/
>core.py?id=4f8c4a7a10d85080d6db9b30ae1759d45a38a32c#n460

I like this!

Will look into what needs to be done to make it happen in Glance and
get feedback from the rest of the folks. As you said, it's really few
times when this would totally break a project's gate and I think
that's manageable. 

A non-voting gate doesn't have the same effect, FWIW, but I also see
reasons for having one instead of stopping a project.

Flavio

>
>- Brant
>

>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


-- 
@flaper87
Flavio Percoco