Re: [openstack-dev] [ALL] Removing generate_uuid() from uuidutils

2013-11-13 Thread Russell Bryant
On 11/13/2013 08:48 AM, Gary Kotton wrote:
 I recall a few cycles ago having str(uuid.uuid4()) replaced
 by generate_uuid(). There was actually a helper function in neutron
 (back when it was called quantum) and it was replaced. So now we are
 going back… 
 I am not in favor of this change. 

I think the point is we shouldn't need a helper function at all.  I
agree with that.  The unpleasant part is having code churn over
something so trivial.

I'd say deprecate/remove it from Oslo to discourage new users of it if
you'd like, but leave existing uses alone for now.  It doesn't hurt
anything, and code churn comes at a cost.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ALL] Removing generate_uuid() from uuidutils

2013-11-13 Thread Andrew Laski

On 11/13/13 at 05:48am, Gary Kotton wrote:

I recall a few cycles ago having str(uuid.uuid4()) replaced by generate_uuid(). 
There was actually a helper function in neutron (back when it was called 
quantum) and it was replaced. So now we are going back…
I am not in favor of this change.


I'm also not really in favor of it.  Though it is a trivial method 
having it in oslo implies that this is what uuids should look like 
across OpenStack projects.  And I'm in favor of consistency for uuids 
across the projects because the same parsers and checkers can then be 
used for input validation or log parsing.




From: Zhongyue Luo zhongyue@intel.commailto:zhongyue@intel.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Wednesday, November 13, 2013 8:07 AM
To: OpenStack Development Mailing List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: [openstack-dev] [ALL] Removing generate_uuid() from uuidutils

Hi all,

We had a discussion of the modules that are incubated in Oslo.

https://etherpad.openstack.org/p/icehouse-oslo-statushttps://urldefense.proofpoint.com/v1/url?u=https://etherpad.openstack.org/p/icehouse-oslo-statusk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=3ns0o3FRyS2%2Fg%2FTFIH7waZX1o%2FHdXvrJ%2FnH9XMCRy08%3D%0As=63eaa20d8c94217d86793a24379b4391179fbfa1fb2c961fb37a5512dbdff69a

One of the conclusions we came to was to deprecate/remove uuidutils in this 
cycle.

The first step into this change should be to remove generate_uuid() from 
uuidutils.

The reason is that 1) generating the UUID string seems trivial enough to not 
need a function and 2) string representation of uuid4 is not what we want in 
all projects.

To address this, a patch is now on gerrit. 
https://review.openstack.org/#/c/56152/https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%23/c/56152/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=3ns0o3FRyS2%2Fg%2FTFIH7waZX1o%2FHdXvrJ%2FnH9XMCRy08%3D%0As=adb860d11d1ad02718e306b9408c603daa00970685a208db375a9ec011f13978

Each project should directly use the standard uuid module or implement its own 
helper function to generate uuids if this patch gets in.

Any thoughts on this change? Thanks.

--
Intel SSG/STO/DCST/CIT
880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai, China
+862161166500



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ALL] Removing generate_uuid() from uuidutils

2013-11-13 Thread John Griffith
On Wed, Nov 13, 2013 at 7:21 AM, Andrew Laski
andrew.la...@rackspace.com wrote:
 On 11/13/13 at 05:48am, Gary Kotton wrote:

 I recall a few cycles ago having str(uuid.uuid4()) replaced by
 generate_uuid(). There was actually a helper function in neutron (back when
 it was called quantum) and it was replaced. So now we are going back…
 I am not in favor of this change.


 I'm also not really in favor of it.  Though it is a trivial method having it
 in oslo implies that this is what uuids should look like across OpenStack
 projects.  And I'm in favor of consistency for uuids across the projects
 because the same parsers and checkers can then be used for input validation
 or log parsing.


 From: Zhongyue Luo zhongyue@intel.commailto:zhongyue@intel.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org

 Date: Wednesday, November 13, 2013 8:07 AM
 To: OpenStack Development Mailing List
 openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org

 Subject: [openstack-dev] [ALL] Removing generate_uuid() from uuidutils

 Hi all,

 We had a discussion of the modules that are incubated in Oslo.


 https://etherpad.openstack.org/p/icehouse-oslo-statushttps://urldefense.proofpoint.com/v1/url?u=https://etherpad.openstack.org/p/icehouse-oslo-statusk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=3ns0o3FRyS2%2Fg%2FTFIH7waZX1o%2FHdXvrJ%2FnH9XMCRy08%3D%0As=63eaa20d8c94217d86793a24379b4391179fbfa1fb2c961fb37a5512dbdff69a


 One of the conclusions we came to was to deprecate/remove uuidutils in
 this cycle.

 The first step into this change should be to remove generate_uuid() from
 uuidutils.

 The reason is that 1) generating the UUID string seems trivial enough to
 not need a function and 2) string representation of uuid4 is not what we
 want in all projects.

 To address this, a patch is now on gerrit.
 https://review.openstack.org/#/c/56152/https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%23/c/56152/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=3ns0o3FRyS2%2Fg%2FTFIH7waZX1o%2FHdXvrJ%2FnH9XMCRy08%3D%0As=adb860d11d1ad02718e306b9408c603daa00970685a208db375a9ec011f13978


 Each project should directly use the standard uuid module or implement its
 own helper function to generate uuids if this patch gets in.

 Any thoughts on this change? Thanks.

 --
 Intel SSG/STO/DCST/CIT
 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai,
 China
 +862161166500


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Trivial or not, people use it and frankly I don't see any value at all
in removing it.  As far as the some projects want a different format
of UUID that doesn't make a lot of sense to me but if that's what
somebody wants they should write their own method.  I strongly agree
with others with respect to the comments around code-churn.  I see
little value in this.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ALL] Removing generate_uuid() from uuidutils

2013-11-13 Thread Mark Washenberger
On Wed, Nov 13, 2013 at 8:02 AM, Julien Danjou jul...@danjou.info wrote:

 On Wed, Nov 13 2013, John Griffith wrote:

  Trivial or not, people use it and frankly I don't see any value at all
  in removing it.  As far as the some projects want a different format
  of UUID that doesn't make a lot of sense to me but if that's what
  somebody wants they should write their own method.  I strongly agree
  with others with respect to the comments around code-churn.  I see
  little value in this.

 The thing is that code in oslo-incubator is supposed to be graduated to
 standalone Python library.

 We see little value in a library providing a library for a helper doing
 str(uuid.uuid4()).


For the currently remaining function in uuidutils, is_uuid_like, could we
potentially just add this functionality to the standard library?
Something like:

 uuid.UUID('----')
UUID('----')
 uuid.UUID('----'.replace('-', ''))
UUID('----')
 uuid.UUID('----'.replace('-', ''),
strict=True)
Traceback (most recent call last):
  File stdin, line 1, in module
  File
/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Versions/2.7/lib/python2.7/uuid.py,
line 134, in __init__
raise ValueError('badly formed hexadecimal UUID string')
ValueError: badly formed hexadecimal UUID string

I've had a few situations where UUID's liberal treatment of what it
consumes has seemed a bit excessive, anyway. Not sure if this approach is a
bit too naive, however.




 --
 Julien Danjou
 /* Free Software hacker * independent consultant
http://julien.danjou.info */

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ALL] Removing generate_uuid() from uuidutils

2013-11-13 Thread John Griffith
On Wed, Nov 13, 2013 at 9:02 AM, Julien Danjou jul...@danjou.info wrote:
 On Wed, Nov 13 2013, John Griffith wrote:

 Trivial or not, people use it and frankly I don't see any value at all
 in removing it.  As far as the some projects want a different format
 of UUID that doesn't make a lot of sense to me but if that's what
 somebody wants they should write their own method.  I strongly agree
 with others with respect to the comments around code-churn.  I see
 little value in this.

 The thing is that code in oslo-incubator is supposed to be graduated to
 standalone Python library.

 We see little value in a library providing a library for a helper doing
 str(uuid.uuid4()).

Well I see your point, probably should've never been there in the
first place :)  Although I suppose it is good to have some form of
standarization for something no matter how trivial.  Anyway, my
opinion is it seems like unnecessary churn but I do see your point.  I
can modify it in Cinder easy enough and won't complain (too much
more), but I'm also wondering how many *other* things might fall in to
this category.


 --
 Julien Danjou
 /* Free Software hacker * independent consultant
http://julien.danjou.info */

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ALL] Removing generate_uuid() from uuidutils

2013-11-13 Thread Dolph Mathews
On Wed, Nov 13, 2013 at 9:47 AM, John Griffith
john.griff...@solidfire.comwrote:

 On Wed, Nov 13, 2013 at 7:21 AM, Andrew Laski
 andrew.la...@rackspace.com wrote:
  On 11/13/13 at 05:48am, Gary Kotton wrote:
 
  I recall a few cycles ago having str(uuid.uuid4()) replaced by
  generate_uuid(). There was actually a helper function in neutron (back
 when
  it was called quantum) and it was replaced. So now we are going back…
  I am not in favor of this change.
 
 
  I'm also not really in favor of it.  Though it is a trivial method
 having it
  in oslo implies that this is what uuids should look like across OpenStack
  projects.

And I'm in favor of consistency for uuids across the projects
  because the same parsers and checkers can then be used for input
 validation
  or log parsing.


Parsers? UUID's should be treated as opaque strings once they're generated.


 
 
  From: Zhongyue Luo zhongyue@intel.commailto:
 zhongyue@intel.com
  Reply-To: OpenStack Development Mailing List (not for usage questions)
  openstack-dev@lists.openstack.orgmailto:
 openstack-dev@lists.openstack.org
 
  Date: Wednesday, November 13, 2013 8:07 AM
  To: OpenStack Development Mailing List
  openstack-dev@lists.openstack.orgmailto:
 openstack-dev@lists.openstack.org
 
  Subject: [openstack-dev] [ALL] Removing generate_uuid() from uuidutils
 
  Hi all,
 
  We had a discussion of the modules that are incubated in Oslo.
 
 
  https://etherpad.openstack.org/p/icehouse-oslo-status
 https://urldefense.proofpoint.com/v1/url?u=https://etherpad.openstack.org/p/icehouse-oslo-statusk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=3ns0o3FRyS2%2Fg%2FTFIH7waZX1o%2FHdXvrJ%2FnH9XMCRy08%3D%0As=63eaa20d8c94217d86793a24379b4391179fbfa1fb2c961fb37a5512dbdff69a
 
 
 
  One of the conclusions we came to was to deprecate/remove uuidutils in
  this cycle.
 
  The first step into this change should be to remove generate_uuid() from
  uuidutils.
 
  The reason is that 1) generating the UUID string seems trivial enough to
  not need a function and 2) string representation of uuid4 is not what we
  want in all projects.


There's room for long term improvement such as decreasing string length,
increasing entropy, linearly distributed output, etc. I agree that the
current implementation is useless/trivial, but the work to build upon it
should happen in oslo to benefit all projects.


 
  To address this, a patch is now on gerrit.
  https://review.openstack.org/#/c/56152/
 https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%23/c/56152/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=3ns0o3FRyS2%2Fg%2FTFIH7waZX1o%2FHdXvrJ%2FnH9XMCRy08%3D%0As=adb860d11d1ad02718e306b9408c603daa00970685a208db375a9ec011f13978
 
 
 
  Each project should directly use the standard uuid module or implement
 its
  own helper function to generate uuids if this patch gets in.
 
  Any thoughts on this change? Thanks.
 
  --
  Intel SSG/STO/DCST/CIT
  880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai,
  China
  +862161166500
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 Trivial or not, people use it and frankly I don't see any value at all
 in removing it.  As far as the some projects want a different format
 of UUID that doesn't make a lot of sense to me but if that's what
 somebody wants they should write their own method.  I strongly agree
 with others with respect to the comments around code-churn.  I see
 little value in this.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 

-Dolph
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ALL] Removing generate_uuid() from uuidutils

2013-11-13 Thread Andrew Laski

On 11/13/13 at 12:01pm, Dolph Mathews wrote:

On Wed, Nov 13, 2013 at 9:47 AM, John Griffith
john.griff...@solidfire.comwrote:


On Wed, Nov 13, 2013 at 7:21 AM, Andrew Laski
andrew.la...@rackspace.com wrote:
 On 11/13/13 at 05:48am, Gary Kotton wrote:

 I recall a few cycles ago having str(uuid.uuid4()) replaced by
 generate_uuid(). There was actually a helper function in neutron (back
when
 it was called quantum) and it was replaced. So now we are going back…
 I am not in favor of this change.


 I'm also not really in favor of it.  Though it is a trivial method
having it
 in oslo implies that this is what uuids should look like across OpenStack
 projects.


And I'm in favor of consistency for uuids across the projects

 because the same parsers and checkers can then be used for input
validation
 or log parsing.



Parsers? UUID's should be treated as opaque strings once they're generated.


Right, I meant log parsers not UUID parsers.  If they're consistently 
formatted it's easier to pick them out.








 From: Zhongyue Luo zhongyue@intel.commailto:
zhongyue@intel.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.orgmailto:
openstack-dev@lists.openstack.org

 Date: Wednesday, November 13, 2013 8:07 AM
 To: OpenStack Development Mailing List
 openstack-dev@lists.openstack.orgmailto:
openstack-dev@lists.openstack.org

 Subject: [openstack-dev] [ALL] Removing generate_uuid() from uuidutils

 Hi all,

 We had a discussion of the modules that are incubated in Oslo.


 https://etherpad.openstack.org/p/icehouse-oslo-status
https://urldefense.proofpoint.com/v1/url?u=https://etherpad.openstack.org/p/icehouse-oslo-statusk=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=3ns0o3FRyS2%2Fg%2FTFIH7waZX1o%2FHdXvrJ%2FnH9XMCRy08%3D%0As=63eaa20d8c94217d86793a24379b4391179fbfa1fb2c961fb37a5512dbdff69a



 One of the conclusions we came to was to deprecate/remove uuidutils in
 this cycle.

 The first step into this change should be to remove generate_uuid() from
 uuidutils.

 The reason is that 1) generating the UUID string seems trivial enough to
 not need a function and 2) string representation of uuid4 is not what we
 want in all projects.



There's room for long term improvement such as decreasing string length,
increasing entropy, linearly distributed output, etc. I agree that the
current implementation is useless/trivial, but the work to build upon it
should happen in oslo to benefit all projects.




 To address this, a patch is now on gerrit.
 https://review.openstack.org/#/c/56152/
https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%23/c/56152/k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0Ar=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0Am=3ns0o3FRyS2%2Fg%2FTFIH7waZX1o%2FHdXvrJ%2FnH9XMCRy08%3D%0As=adb860d11d1ad02718e306b9408c603daa00970685a208db375a9ec011f13978



 Each project should directly use the standard uuid module or implement
its
 own helper function to generate uuids if this patch gets in.

 Any thoughts on this change? Thanks.

 --
 Intel SSG/STO/DCST/CIT
 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai,
 China
 +862161166500


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Trivial or not, people use it and frankly I don't see any value at all
in removing it.  As far as the some projects want a different format
of UUID that doesn't make a lot of sense to me but if that's what
somebody wants they should write their own method.  I strongly agree
with others with respect to the comments around code-churn.  I see
little value in this.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





--

-Dolph



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ALL] Removing generate_uuid() from uuidutils

2013-11-13 Thread Doug Hellmann
On Wed, Nov 13, 2013 at 1:07 AM, Zhongyue Luo zhongyue@intel.comwrote:

 Hi all,

 We had a discussion of the modules that are incubated in Oslo.

 https://etherpad.openstack.org/p/icehouse-oslo-status

 One of the conclusions we came to was to deprecate/remove uuidutils in
 this cycle.

 The first step into this change should be to remove generate_uuid() from
 uuidutils.

 The reason is that 1) generating the UUID string seems trivial enough to
 not need a function and 2) string representation of uuid4 is not what we
 want in all projects.

 To address this, a patch is now on gerrit.
 https://review.openstack.org/#/c/56152/

 Each project should directly use the standard uuid module or implement its
 own helper function to generate uuids if this patch gets in.

 Any thoughts on this change? Thanks.


Unfortunately it looks like that change went through before I caught up on
email. Shouldn't we have removed its use in the downstream projects (at
least integrated projects) before removing it from Oslo?

Doug




 --
 *Intel SSG/STO/DCST/CIT*
 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai,
 China
 +862161166500

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ALL] Removing generate_uuid() from uuidutils

2013-11-13 Thread Joe Gordon
On Wed, Nov 13, 2013 at 12:44 PM, Doug Hellmann doug.hellm...@dreamhost.com
 wrote:




 On Wed, Nov 13, 2013 at 1:07 AM, Zhongyue Luo zhongyue@intel.comwrote:

 Hi all,

 We had a discussion of the modules that are incubated in Oslo.

 https://etherpad.openstack.org/p/icehouse-oslo-status

 One of the conclusions we came to was to deprecate/remove uuidutils in
 this cycle.

 The first step into this change should be to remove generate_uuid() from
 uuidutils.

 The reason is that 1) generating the UUID string seems trivial enough to
 not need a function and 2) string representation of uuid4 is not what we
 want in all projects.

 To address this, a patch is now on gerrit.
 https://review.openstack.org/#/c/56152/

 Each project should directly use the standard uuid module or implement
 its own helper function to generate uuids if this patch gets in.

 Any thoughts on this change? Thanks.


 Unfortunately it looks like that change went through before I caught up on
 email. Shouldn't we have removed its use in the downstream projects (at
 least integrated projects) before removing it from Oslo?


++, good think gerrit has a revert button.


 Doug




 --
 *Intel SSG/STO/DCST/CIT*
 880 Zixing Road, Zizhu Science Park, Minhang District, 200241, Shanghai,
 China
 +862161166500

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ALL] Removing generate_uuid() from uuidutils

2013-11-13 Thread Flavio Percoco

On 13/11/13 12:49 -0800, Joe Gordon wrote:




On Wed, Nov 13, 2013 at 12:44 PM, Doug Hellmann doug.hellm...@dreamhost.com
wrote:




   On Wed, Nov 13, 2013 at 1:07 AM, Zhongyue Luo zhongyue@intel.com
   wrote:

   Hi all,

   We had a discussion of the modules that are incubated in Oslo.

   https://etherpad.openstack.org/p/icehouse-oslo-status

   One of the conclusions we came to was to deprecate/remove uuidutils in
   this cycle.

   The first step into this change should be to remove generate_uuid()
   from uuidutils.

   The reason is that 1) generating the UUID string seems trivial enough
   to not need a function and 2) string representation of uuid4 is not
   what we want in all projects.

   To address this, a patch is now on gerrit. https://review.openstack.org
   /#/c/56152/

   Each project should directly use the standard uuid module or implement
   its own helper function to generate uuids if this patch gets in.

   Any thoughts on this change? Thanks.


   Unfortunately it looks like that change went through before I caught up on
   email. Shouldn't we have removed its use in the downstream projects (at
   least integrated projects) before removing it from Oslo?
  



++, good think gerrit has a revert button.



Yeah, plus we should've let this discussion warm up a little bit more.
My bad there.

Revert patch here:

https://review.openstack.org/#/c/56286/


Cheers,
FF




   Doug


  
  
   --

   Intel SSG/STO/DCST/CIT
   880 Zixing Road, Zizhu Science Park, Minhang District, 200241,
   Shanghai, China
   +862161166500
  
   ___

   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev






___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
@flaper87
Flavio Percoco

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ALL] Removing generate_uuid() from uuidutils

2013-11-13 Thread Eric Windisch
 Each project should directly use the standard uuid module or implement its
 own helper function to generate uuids if this patch gets in.

 Any thoughts on this change? Thanks.


 Unfortunately it looks like that change went through before I caught up on
 email. Shouldn't we have removed its use in the downstream projects (at
 least integrated projects) before removing it from Oslo?

I don't think it is a problem to remove the code in oslo first, as
long as no other oslo-incubator code uses it. Projects don't have to
sync the code and could always revert should that they do.

However, like Mark, I'm inclined to consider the value of
is_uuid_like. While undoubtedly useful, is one method sufficient to
warrant creating a new top-level module. Waiting for it to hit the
standard library will take quite a long time...

There are other components of oslo that are terse and questionable as
standalone libraries. For these, it might make sense to aggressively
consider rolling some modules together?

One clear example would be log.py and log_handler.py, another would be
periodic_task.py and loopingcall.py

-- 
Regards,
Eric Windisch

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ALL] Removing generate_uuid() from uuidutils

2013-11-13 Thread Doug Hellmann
On Wed, Nov 13, 2013 at 4:20 PM, Eric Windisch e...@cloudscaling.comwrote:

  Each project should directly use the standard uuid module or implement
 its
  own helper function to generate uuids if this patch gets in.
 
  Any thoughts on this change? Thanks.
 
 
  Unfortunately it looks like that change went through before I caught up
 on
  email. Shouldn't we have removed its use in the downstream projects (at
  least integrated projects) before removing it from Oslo?

 I don't think it is a problem to remove the code in oslo first, as
 long as no other oslo-incubator code uses it. Projects don't have to
 sync the code and could always revert should that they do.


Well, I wanted to avoid having projects decide that merging Oslo code was a
hassle or risky, because that breaks the promise of the project. We talked
at the summit about providing patches to consuming projects when we break
Oslo APIs, and I think that's a reasonable approach. When we do break an
API, we want to ensure that we at least have a plan for how consumers could
be updated. WIP patches for the consumers show that we've thought through
the changes sufficiently to at least continue to cover our existing use
cases.



 However, like Mark, I'm inclined to consider the value of
 is_uuid_like. While undoubtedly useful, is one method sufficient to
 warrant creating a new top-level module. Waiting for it to hit the
 standard library will take quite a long time...

 There are other components of oslo that are terse and questionable as
 standalone libraries. For these, it might make sense to aggressively
 consider rolling some modules together?

 One clear example would be log.py and log_handler.py, another would be
 periodic_task.py and loopingcall.py


I like having the modules separate, and don't think each top-level module
implies a standalone library after graduation. For example, there are some
other modules related to string formatting that we could combine into an
oslo.text library, when they are ready to graduate.

Doug



 --
 Regards,
 Eric Windisch

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ALL] Removing generate_uuid() from uuidutils

2013-11-13 Thread Doug Hellmann
On Wed, Nov 13, 2013 at 4:24 PM, Michael Still mi...@stillhq.com wrote:

 On Thu, Nov 14, 2013 at 8:20 AM, Eric Windisch e...@cloudscaling.com
 wrote:

  I don't think it is a problem to remove the code in oslo first, as
  long as no other oslo-incubator code uses it. Projects don't have to
  sync the code and could always revert should that they do.

 I strongly disagree. It stops projects from syncing with oslo until
 they go through the code churn to remove the method.

  However, like Mark, I'm inclined to consider the value of
  is_uuid_like. While undoubtedly useful, is one method sufficient to
  warrant creating a new top-level module. Waiting for it to hit the
  standard library will take quite a long time...
 
  There are other components of oslo that are terse and questionable as
  standalone libraries. For these, it might make sense to aggressively
  consider rolling some modules together?
 
  One clear example would be log.py and log_handler.py, another would be
  periodic_task.py and loopingcall.py

 I'm not sure I see the harm in leaving small but widely used modules
 in oslo incubator. If we really want to release everything as a
 library, can't we just have a generic catchall one for the small
 things? oslo.therest perhaps?


Every project eventually grows a utils module, right? :-)

Seriously, we'll release things in large enough chunks that they are worth
maintaining on their own, while sticking to a logical grouping of features.
Not everything is going to be as big as oslo.messaging, but most of the
libraries won't be as small as oslo.version either.

Doug



 Michael

 --
 Rackspace Australia

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [ALL] Removing generate_uuid() from uuidutils

2013-11-12 Thread Julien Danjou
On Wed, Nov 13 2013, Zhongyue Luo wrote:

 Any thoughts on this change? Thanks.

+2'ed. I'm pretty sure that helping other projects to help get rid of it
would be nice, if your time allows it. :)

-- 
Julien Danjou
// Free Software hacker / independent consultant
// http://julien.danjou.info


signature.asc
Description: PGP signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev