Open Stack

Oh, agreed. I'm not asking if these things should be in common, I think they should. Only if "because something is in common it *must* be used"...

    - Gabriel

> -----Original Message-----
> From: Joshua Harlow [mailto:harlowja at yahoo-inc.com]
> Sent: Friday, September 07, 2012 12:25 PM
> To: OpenStack Development Mailing List; Gabriel Hurley
> Subject: Re: [openstack-dev] When to use openstack-common
> 
> Seems like a case where if its useful for 2/3 projects than maybe it should be
> in common.
> 
> I think it might be hard/impossible to always get 3/3 (or 100%) usefulness for
> everyone.
> 
> On 9/7/12 12:09 PM, "Gabriel Hurley" <Gabriel.Hurley at nebula.com> wrote:
> 
> >In response to https://review.openstack.org/#/c/12413/ I'm faced with
> >the following question: should openstack common modules be included in
> >cases where they're not providing any benefit other than standardization?
> >
> >In particular, there are 3 points around that review:
> >
> >  1. The jsonutils code is designed to solve problems Horizon doesn't
> >have.
> >  2. The timeutils code duplicates functionality already built into
> >Django (which Horizon is built on) and is only included because
> >jsonutils now requires it.
> >  3. The timeutils code is now adding external dependencies (iso8601
> >python module) which *again* is duplicating built-in function in Django.
> >
> >This seems like a really bad approach. It's a long dependency chain
> >that adds nothing other than saying "we're using openstack-common".
> >
> >I'm inclined to remove jsonutils from Horizon (the "setup" module from
> >openstack-common is still quite useful) and just go back to using the
> >built-in python json.
> >
> >Alternatively, we need to introduce some constraints around introducing
> >dependency chains in common...
> >
> >Thoughts?
> >
> >    - Gabriel
> >
> >
> >_______________________________________________
> >OpenStack-dev mailing list
> >OpenStack-dev at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>