<div>Hi,</div><div><br></div>I am all in favour of healthy refactoring aimed at improving maintainability. I tend to do the same every time I have a few spare cycles. Thank you very much for doing this.<div><br></div><div>
While I see the point of your claim about using the standard library's uuid module, I would encourage you to use the wrapper function in openstack.common. This is for two reasons: 1) doing the same thing as the other Openstack Projects (for instance don't you find strange Keystone uses different uuids?), and 2) ensure every contributor generates uuids in the same way (the uuid module has different generators).</div>
<div><br></div><div>To the risk of appearing extremely boring and pedant, I would also encourage you to always associate a bug report or blueprint to every patch you push to gerrit; even if it is just a refactoring, and not a real malfunctioning in the software. This will help us to keep track of what goes in each release (milestone, RC, official release).</div>
<div><br></div><div><br></div><div>Regards,</div><div>Salvatore<br><br><div class="gmail_quote">On 19 November 2012 16:21, Dan Wendlandt <span dir="ltr"><<a href="mailto:dan@nicira.com" target="_blank">dan@nicira.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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"><div><div class="h5">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>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><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><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></div></div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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><span class="HOEnZb"><font color="#888888"><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>
</font></span></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></div>