On Wed, Aug 22, 2018, 10:13 AM Eric Fried <openst...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
