Open Stack

On Thu, Dec 10, 2015 at 11:10 AM, Flavio Percoco <flavio at redhat.com> wrote:

> 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
>
>
If other projects are interested (and since we already copy-pasted it to
other keystone projects), I've got a pull request in to fixtures to add a
fixture that does the same thing, see
https://github.com/testing-cabal/fixtures/pull/19 .

 - Brant


>
>> - 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
>
>
> __________________________________________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151210/3b946660/attachment.html>