Open Stack

I'd be open to a patch that standardizes on using the openstack-common
mechanism for uuid generation.  I suspect most of the other users were
created before openstack-common, or were added by people who were not aware
of the openstack common mechanism.

dan

On Mon, Nov 19, 2012 at 6:43 AM, Zhongyue Luo <zhongyue.luo at gmail.com>wrote:

> I've recently submitted a patch of removing UUID helper functions and
> directly using the standard uuid module for Quantum.
> https://review.openstack.org/#/c/16143/
> I know this subject is a bit off track from the efforts that the team is
> currently focusing, however I wish to raise this issue in the early cycles
> of Grizzly and hear what others think.
>
> Currently there are four different ways to create an UUID in Quantum.
> 1) quantum.common.utils.str_uuid()
> 2) The quantum.openstack.common.uuidutils.generate_uuid()
> 3) quantum.tests.unit.test_api_v2._uuid()
> 4) (the standard uuid module) str(uuid.uuid4())
>
> Other projects have recently resolved this type of inconsistency. Glance
> choose to use the generate_uuid module from oslo, while Nova/Cinder is now
> calling uuid4() directly at the standard uuid module.
>
> Now my question is whether this freedom in UUID generation is considered
> as a problem in Quantum? If it is a problem, what policy should we choose?
> If we choose that path, how are we going to enforce it?
>
> I personally think this a problem in Quantum since allowing any kind of
> inconsistency should be prohibited within a project.
> Then would using a wrapper function help resolving this situation? I
> personally think allowing uuid helper functions in the first place was the
> cause of the problem. The fact that there exists various versions of these
> wrapper functions indicate that they are of no use and only create
> confusion to newcomers. Instead, I suggest we should directly use the
> standard uuid module wherever an UUID is generated and forcing this policy
> should prevent any kind of diversion in the future.
>
> Any thoughts?
>
> --
> *Intel SSG/SSD/SOTC/PRC/CITT*
> 880 Zixing Road, Zizhu Science Park, Minhang District, Shanghai, 200241,
> China
> +862161166500
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dan Wendlandt
Nicira, Inc: www.nicira.com
twitter: danwendlandt
~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121119/a075fc0b/attachment.html>