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.<div>

<br></div><div>dan<br><br><div class="gmail_quote">On Mon, Nov 19, 2012 at 6:43 AM, Zhongyue Luo <span dir="ltr"><<a href="mailto:zhongyue.luo@gmail.com" target="_blank">zhongyue.luo@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><span></span></div><div>I've recently submitted a patch of removing UUID helper functions and directly using the standard uuid module for Quantum. <a href="https://review.openstack.org/#/c/16143/" target="_blank">https://review.openstack.org/#/c/16143/</a><br>



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.<br clear="all"><br>Currently there are four different ways to create an UUID in Quantum.<br>



1) quantum.common.utils.str_uuid()<br>2) The quantum.openstack.common.uuidutils.generate_uuid()<br>3) quantum.tests.unit.test_api_v2._uuid()</div><div>4)<span> (the standard uuid module) str(uuid.uuid4())</span><br><br>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.<br>


<br>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?<br>
<br>I personally think this a problem in Quantum since allowing any kind of inconsistency should be prohibited within a project.</div><div>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.</div>

<div><br></div><div>Any thoughts?<span class="HOEnZb"><font color="#888888"><br><br>-- <br><div><b>Intel SSG/SSD/SOTC/PRC/CITT</b></div>

<div>880 Zixing Road, Zizhu Science Park, Minhang District, Shanghai, 200241, 
China<br></div>
<div><a href="tel:%2B862161166500" value="+862161166500" target="_blank">+862161166500</a></div><br>
</font></span></div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>Dan Wendlandt <div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br><div>twitter: danwendlandt<br>

~~~~~~~~~~~~~~~~~~~~~~~~~~~<br></div></div><br>
</div>