Open Stack

Excerpts from Davanum Srinivas (dims)'s message of 2018-08-23 06:46:38 -0400:
> Where exactly Eric? I can't seem to find the import:
> 
> http://codesearch.openstack.org/?q=(from%7Cimport).*oslotest&i=nope&files=&repos=oslo.utils
> 
> -- dims

oslo.utils depends on oslotest via test-requirements.txt and oslotest is
used within the test modules in oslo.utils.

As I've said on both reviews, I think we do not want a global
singleton instance of this sentinal class. We do want a formal test
fixture.  Either library can export a test fixture and olso.utils
already has oslo_utils.fixture.TimeFixture so there's precedent to
adding it there, so I have a slight preference for just doing that.

That said, oslo_utils.uuidutils.generate_uuid() is simply returning
str(uuid.uuid4()). We have it wrapped up as a function so we can
mock it out in other tests, but we hardly need to rely on that if
we're making a test fixture for oslotest.

My vote is to add a new fixture class to oslo_utils.fixture.

Doug

> 
> On Wed, Aug 22, 2018 at 11:24 PM Jay Pipes <jaypipes at gmail.com> wrote:
> 
> >
> > On Wed, Aug 22, 2018, 10:13 AM Eric Fried <openstack at fried.cc> wrote:
> >
> >> For some time, nova has been using uuidsentinel [1] which conveniently
> >> allows you to get a random UUID in a single LOC with a readable name
> >> that's the same every time you reference it within that process (but not
> >> across processes). Example usage: [2].
> >>
> >> We would like other projects (notably the soon-to-be-split-out placement
> >> project) to be able to use uuidsentinel without duplicating the code. So
> >> we would like to stuff it in an oslo lib.
> >>
> >> The question is whether it should live in oslotest [3] or in
> >> oslo_utils.uuidutils [4]. The proposed patches are (almost) the same.
> >> The issues we've thought of so far:
> >>
> >> - If this thing is used only for test, oslotest makes sense. We haven't
> >> thought of a non-test use, but somebody surely will.
> >> - Conversely, if we put it in oslo_utils, we're kinda saying we support
> >> it for non-test too. (This is why the oslo_utils version does some extra
> >> work for thread safety and collision avoidance.)
> >> - In oslotest, awkwardness is necessary to avoid circular importing:
> >> uuidsentinel uses oslo_utils.uuidutils, which requires oslotest. In
> >> oslo_utils.uuidutils, everything is right there.
> >>
> >
> > My preference is to put it in oslotest. Why does oslo_utils.uuidutils
> > import oslotest? That makes zero sense to me...
> >
> > -jay
> >
> > - It's a... UUID util. If I didn't know anything and I was looking for a
> >> UUID util like uuidsentinel, I would look in a module called uuidutils
> >> first.
> >>
> >> We hereby solicit your opinions, either by further discussion here or as
> >> votes on the respective patches.
> >>
> >> Thanks,
> >> efried
> >>
> >> [1]
> >>
> >> https://github.com/openstack/nova/blob/17b69575bc240ca1dd8b7a681de846d90f3b642c/nova/tests/uuidsentinel.py
> >> [2]
> >>
> >> https://github.com/openstack/nova/blob/17b69575bc240ca1dd8b7a681de846d90f3b642c/nova/tests/functional/api/openstack/placement/db/test_resource_provider.py#L109-L115
> >> [3] https://review.openstack.org/594068
> >> [4] https://review.openstack.org/594179
> >>
> >> __________________________________________________________________________
> >> 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
> >>
> > __________________________________________________________________________
> > 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
> >
>