Open Stack

Hi,

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.

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

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


Regards,
Salvatore

On 19 November 2012 16:21, Dan Wendlandt <dan at nicira.com> wrote:

> 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
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20121121/52071442/attachment.html>