Re: [openstack-dev] [oslo] UUID sentinel needs a home
Thanks Doug. I restored [4] and moved the code to the fixture module. Enjoy. -efried On 08/27/2018 10:59 AM, Doug Hellmann wrote: > Excerpts from Eric Fried's message of 2018-08-22 09:13:25 -0500: >> 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. >> - 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 >> > > We discussed this during the Oslo team meeting today, and have settled > on the idea of placing Eric's version of the code (with the thread-safe > fix and the module-level global) in oslo_utils.fixture to allow it to > easily reuse the oslo_utils.uuidutils module and still be clearly marked > as test code. > > Doug > > __ > 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
Excerpts from Eric Fried's message of 2018-08-22 09:13:25 -0500: > 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. > - 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 > We discussed this during the Oslo team meeting today, and have settled on the idea of placing Eric's version of the code (with the thread-safe fix and the module-level global) in oslo_utils.fixture to allow it to easily reuse the oslo_utils.uuidutils module and still be clearly marked as test code. Doug __ 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
On 08/24/2018 07:51 PM, Matt Riedemann wrote: On 8/23/2018 2:05 PM, Chris Dent wrote: On Thu, 23 Aug 2018, Dan Smith wrote: ...and it doesn't work like mock.sentinel does, which is part of the value. I really think we should put this wherever it needs to be so that it can continue to be as useful as is is today. Even if that means just copying it into another project -- it's not that complicated of a thing. Yeah, I agree. I had hoped that we could make something that was generally useful, but its main value is its interface and if we can't have that interface in a library, having it per codebase is no biggie. For example it's been copied straight from nova into the placement extractions experiments with no changes and, as one would expect, works just fine. Unless people are wed to doing something else, Dan's right, let's just do that. So just follow me here people, what if we had this common shared library where code could incubate and then we could write some tools to easily copy that common code into other projects... Sounds masterful. I'm pretty sure I could get said project approved as a top-level program under The Foundation and might even get a talk or two out of this idea. I can see the Intel money rolling in now... Indeed, I'll open the commons bank account. Ciao, -jay __ 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
On Fri, Aug 24, 2018 at 8:01 PM Jeremy Stanley wrote: > On 2018-08-24 18:51:08 -0500 (-0500), Matt Riedemann wrote: > [...] > > So just follow me here people, what if we had this common shared > > library where code could incubate and then we could write some > > tools to easily copy that common code into other projects... > > If we do this, can we at least put it in a consistent place in all > projects? Maybe name the directory something like "openstack/common" > just to make it obvious. > > > I'm pretty sure I could get said project approved as a top-level > > program under The Foundation and might even get a talk or two out > > of this idea. I can see the Intel money rolling in now... > > Seems like a sound idea. Can we call it "Nostalgia" for no > particular reason? Though maybe "Recurring Nightmare" would be a > more accurate choice. > /me wakes up screaming!! > -- > Jeremy Stanley > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
On 2018-08-24 18:51:08 -0500 (-0500), Matt Riedemann wrote: [...] > So just follow me here people, what if we had this common shared > library where code could incubate and then we could write some > tools to easily copy that common code into other projects... If we do this, can we at least put it in a consistent place in all projects? Maybe name the directory something like "openstack/common" just to make it obvious. > I'm pretty sure I could get said project approved as a top-level > program under The Foundation and might even get a talk or two out > of this idea. I can see the Intel money rolling in now... Seems like a sound idea. Can we call it "Nostalgia" for no particular reason? Though maybe "Recurring Nightmare" would be a more accurate choice. -- Jeremy Stanley __ 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
On 8/23/2018 2:05 PM, Chris Dent wrote: On Thu, 23 Aug 2018, Dan Smith wrote: ...and it doesn't work like mock.sentinel does, which is part of the value. I really think we should put this wherever it needs to be so that it can continue to be as useful as is is today. Even if that means just copying it into another project -- it's not that complicated of a thing. Yeah, I agree. I had hoped that we could make something that was generally useful, but its main value is its interface and if we can't have that interface in a library, having it per codebase is no biggie. For example it's been copied straight from nova into the placement extractions experiments with no changes and, as one would expect, works just fine. Unless people are wed to doing something else, Dan's right, let's just do that. So just follow me here people, what if we had this common shared library where code could incubate and then we could write some tools to easily copy that common code into other projects... I'm pretty sure I could get said project approved as a top-level program under The Foundation and might even get a talk or two out of this idea. I can see the Intel money rolling in now... -- Thanks, Matt __ 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
On Fri, 24 Aug 2018, Doug Hellmann wrote: I guess all of the people who complained so loudly about the global in oslo.config are gone? It's a diffent context. In a testing environment where there is already a well established pattern of use it's not a big deal. Global in oslo.config is still horrible, but again: a well established pattern of use. This is part of why I think it is better positioned in oslotest as that signals its limitations. However, like I said in my other message, copying nova's thing has proven fine. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent__ 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
So... Restore the PS of the oslo_utils version that exposed the global [1]? Or use the forced-singleton pattern from nova [2] to put it in its own importable module, e.g. oslo_utils.uuidutils.uuidsentinel? (FTR, "import only modules" is a thing for me too, but I've noticed it doesn't seem to be a hard and fast rule in OpenStack; and in this case it seemed most important to emulate the existing syntax+behavior for consumers.) -efried [1] https://review.openstack.org/#/c/594179/2/oslo_utils/uuidutils.py [2] https://github.com/openstack/nova/blob/a421bd2a8c3b549c603df7860e6357738e79c7c3/nova/tests/uuidsentinel.py#L30 On 08/23/2018 11:23 PM, Doug Hellmann wrote: > > >> On Aug 23, 2018, at 4:01 PM, Ben Nemec wrote: >> >> >> >>> On 08/23/2018 12:25 PM, Doug Hellmann wrote: >>> Excerpts from Eric Fried's message of 2018-08-23 09:51:21 -0500: Do you mean an actual fixture, that would be used like: class MyTestCase(testtools.TestCase): def setUp(self): self.uuids = self.useFixture(oslofx.UUIDSentinelFixture()).uuids def test_foo(self): do_a_thing_with(self.uuids.foo) ? That's... okay I guess, but the refactoring necessary to cut over to it will now entail adding 'self.' to every reference. Is there any way around that? >>> That is what I had envisioned, yes. In the absence of a global, >>> which we do not want, what other API would you propose? >> >> If we put it in oslotest instead, would the global still be a problem? >> Especially since mock has already established a pattern for this >> functionality? > > I guess all of the people who complained so loudly about the global in > oslo.config are gone? > > If we don’t care about the global then we could just put the code from Eric’s > threadsafe version in oslo.utils somewhere. > > Doug > > __ > 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
> On Aug 23, 2018, at 4:01 PM, Ben Nemec wrote: > > > >> On 08/23/2018 12:25 PM, Doug Hellmann wrote: >> Excerpts from Eric Fried's message of 2018-08-23 09:51:21 -0500: >>> Do you mean an actual fixture, that would be used like: >>> >>> class MyTestCase(testtools.TestCase): >>> def setUp(self): >>> self.uuids = self.useFixture(oslofx.UUIDSentinelFixture()).uuids >>> >>> def test_foo(self): >>> do_a_thing_with(self.uuids.foo) >>> >>> ? >>> >>> That's... okay I guess, but the refactoring necessary to cut over to it >>> will now entail adding 'self.' to every reference. Is there any way >>> around that? >> That is what I had envisioned, yes. In the absence of a global, >> which we do not want, what other API would you propose? > > If we put it in oslotest instead, would the global still be a problem? > Especially since mock has already established a pattern for this > functionality? I guess all of the people who complained so loudly about the global in oslo.config are gone? If we don’t care about the global then we could just put the code from Eric’s threadsafe version in oslo.utils somewhere. Doug __ 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
On 08/23/2018 12:25 PM, Doug Hellmann wrote: Excerpts from Eric Fried's message of 2018-08-23 09:51:21 -0500: Do you mean an actual fixture, that would be used like: class MyTestCase(testtools.TestCase): def setUp(self): self.uuids = self.useFixture(oslofx.UUIDSentinelFixture()).uuids def test_foo(self): do_a_thing_with(self.uuids.foo) ? That's... okay I guess, but the refactoring necessary to cut over to it will now entail adding 'self.' to every reference. Is there any way around that? That is what I had envisioned, yes. In the absence of a global, which we do not want, what other API would you propose? If we put it in oslotest instead, would the global still be a problem? Especially since mock has already established a pattern for this functionality? __ 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
On Thu, 23 Aug 2018, Dan Smith wrote: ...and it doesn't work like mock.sentinel does, which is part of the value. I really think we should put this wherever it needs to be so that it can continue to be as useful as is is today. Even if that means just copying it into another project -- it's not that complicated of a thing. Yeah, I agree. I had hoped that we could make something that was generally useful, but its main value is its interface and if we can't have that interface in a library, having it per codebase is no biggie. For example it's been copied straight from nova into the placement extractions experiments with no changes and, as one would expect, works just fine. Unless people are wed to doing something else, Dan's right, let's just do that. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent__ 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
> The compromise, using the patch as currently written [1], would entail > adding one line at the top of each test file: > > uuids = uuidsentinel.UUIDSentinels() > > ...as seen (more or less) at [2]. The subtle difference being that this > `uuids` wouldn't share a namespace across the whole process, only within > that file. Given current usage, that shouldn't cause a problem, but it's > a change. ...and it doesn't work like mock.sentinel does, which is part of the value. I really think we should put this wherever it needs to be so that it can continue to be as useful as is is today. Even if that means just copying it into another project -- it's not that complicated of a thing. --Dan __ 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
The compromise, using the patch as currently written [1], would entail adding one line at the top of each test file: uuids = uuidsentinel.UUIDSentinels() ...as seen (more or less) at [2]. The subtle difference being that this `uuids` wouldn't share a namespace across the whole process, only within that file. Given current usage, that shouldn't cause a problem, but it's a change. -efried [1] https://review.openstack.org/#/c/594068/9 [2] https://review.openstack.org/#/c/594068/9/oslotest/tests/unit/test_uuidsentinel.py@22 On 08/23/2018 12:41 PM, Jay Pipes wrote: > On 08/23/2018 01:25 PM, Doug Hellmann wrote: >> Excerpts from Eric Fried's message of 2018-08-23 09:51:21 -0500: >>> Do you mean an actual fixture, that would be used like: >>> >>> class MyTestCase(testtools.TestCase): >>> def setUp(self): >>> self.uuids = >>> self.useFixture(oslofx.UUIDSentinelFixture()).uuids >>> >>> def test_foo(self): >>> do_a_thing_with(self.uuids.foo) >>> >>> ? >>> >>> That's... okay I guess, but the refactoring necessary to cut over to it >>> will now entail adding 'self.' to every reference. Is there any way >>> around that? >> >> That is what I had envisioned, yes. In the absence of a global, >> which we do not want, what other API would you propose? > > As dansmith mentioned, the niceness and simplicity of being able to do: > > import nova.tests.uuidsentinel as uuids > > .. > > def test_something(self): > my_uuid = uuids.instance1 > > is remarkably powerful and is something I would want to keep. > > Best, > -jay > > __ > 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
On 08/23/2018 01:25 PM, Doug Hellmann wrote: Excerpts from Eric Fried's message of 2018-08-23 09:51:21 -0500: Do you mean an actual fixture, that would be used like: class MyTestCase(testtools.TestCase): def setUp(self): self.uuids = self.useFixture(oslofx.UUIDSentinelFixture()).uuids def test_foo(self): do_a_thing_with(self.uuids.foo) ? That's... okay I guess, but the refactoring necessary to cut over to it will now entail adding 'self.' to every reference. Is there any way around that? That is what I had envisioned, yes. In the absence of a global, which we do not want, what other API would you propose? As dansmith mentioned, the niceness and simplicity of being able to do: import nova.tests.uuidsentinel as uuids .. def test_something(self): my_uuid = uuids.instance1 is remarkably powerful and is something I would want to keep. Best, -jay __ 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
Excerpts from Eric Fried's message of 2018-08-23 09:51:21 -0500: > Do you mean an actual fixture, that would be used like: > > class MyTestCase(testtools.TestCase): > def setUp(self): > self.uuids = self.useFixture(oslofx.UUIDSentinelFixture()).uuids > > def test_foo(self): > do_a_thing_with(self.uuids.foo) > > ? > > That's... okay I guess, but the refactoring necessary to cut over to it > will now entail adding 'self.' to every reference. Is there any way > around that? That is what I had envisioned, yes. In the absence of a global, which we do not want, what other API would you propose? Doug > > efried > > On 08/23/2018 07:40 AM, Jay Pipes wrote: > > On 08/23/2018 08:06 AM, Doug Hellmann wrote: > >> 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=nope==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. > > > > OK, thanks for the helpful explanation, Doug. Works for me. > > > > -jay > > > > __ > > 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
> Do you mean an actual fixture, that would be used like: > > class MyTestCase(testtools.TestCase): > def setUp(self): > self.uuids = self.useFixture(oslofx.UUIDSentinelFixture()).uuids > > def test_foo(self): > do_a_thing_with(self.uuids.foo) > > ? > > That's... okay I guess, but the refactoring necessary to cut over to it > will now entail adding 'self.' to every reference. Is there any way > around that? I don't think it's okay. It makes it a lot more work to use it, where merely importing it (exactly like mock.sentinel) is a large factor in how incredibly convenient it is. --Dan __ 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
Do you mean an actual fixture, that would be used like: class MyTestCase(testtools.TestCase): def setUp(self): self.uuids = self.useFixture(oslofx.UUIDSentinelFixture()).uuids def test_foo(self): do_a_thing_with(self.uuids.foo) ? That's... okay I guess, but the refactoring necessary to cut over to it will now entail adding 'self.' to every reference. Is there any way around that? efried On 08/23/2018 07:40 AM, Jay Pipes wrote: > On 08/23/2018 08:06 AM, Doug Hellmann wrote: >> 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=nope==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. > > OK, thanks for the helpful explanation, Doug. Works for me. > > -jay > > __ > 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
On 08/23/2018 08:06 AM, Doug Hellmann wrote: 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=nope==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. OK, thanks for the helpful explanation, Doug. Works for me. -jay __ 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
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=nope==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 wrote: > > > > > On Wed, Aug 22, 2018, 10:13 AM Eric Fried 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 > > > __ 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
Where exactly Eric? I can't seem to find the import: http://codesearch.openstack.org/?q=(from%7Cimport).*oslotest=nope==oslo.utils -- dims On Wed, Aug 22, 2018 at 11:24 PM Jay Pipes wrote: > > On Wed, Aug 22, 2018, 10:13 AM Eric Fried 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
+1 for oslotest Jay Pipes 于2018年8月23日周四 上午11:24写道： > > On Wed, Aug 22, 2018, 10:13 AM Eric Fried 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 > -- ChangBo Guo(gcb) Community Director @EasyStack __ 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
On Wed, Aug 22, 2018, 10:13 AM Eric Fried 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
Re: [openstack-dev] [oslo] UUID sentinel needs a home
Excerpts from Eric Fried's message of 2018-08-22 09:13:25 -0500: > 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. It also depends on whether we want it used that way. I think, given the fact that the data is not persistent or consistent across runs, I would rather have it as a test library only, and not part of the public production API of oslo.util (see below). > - 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.) That protection is necessary regardless of how it is going to be used. > - 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. A third alternative is to create a test fixture which is exposed from oslo.utils under the test package. That clearly labels the code as a test tool, but avoids the circular import problem of placing it in oslotest. > - 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-dev] [oslo] UUID sentinel needs a home
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. - 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
