openstack team mailing list archive

[Glen Campbell <glen.campbell@xxxxxxxxxxxxx>]

Would it better to break it down even further? I.e., instead of trying to
put ALL the common code into one project, create mini projects for
common-logging, common-configuration, etc. That would permit other
projects to adopt what they need, when they need it, rather than trying to
integrate the entire common project at once.

For example, we're working on converting Glance to use the
logging/notification mechanism defined by Nova. The first step in the
project was, however, "cut and paste notification code" from one to the
other. That's disturbing to me, because it doubles the amount of effort
required to implement changes to the notification system in the future. It
would be much better IMHO to have a refactored common-logging module that
could be included by multiple projects, with a standard interface each
project could rely upon.

There's no requirement, then, to implement common-rpc when you integrate
common-logging, which lowers the barrier to entry for each project.






On 7/25/11 12:11 PM, "Brian Lamar" <brian.lamar@xxxxxxxxxxxxx> wrote:

>All,
>
>I love the idea of having an openstack-common project. However, the
>prospect of creating such a project is daunting and quite difficult.
>
>It's my belief that standardizing/collecting common logic into a single
>module will be beneficial to our current code-base and allow for future
>projects to be created more quickly/easily.
>
>Currently the behemoth in the room is OpenStack Compute (aka Nova). The
>Compute project contains much more code than all other OpenStack projects
>(combined), and rightly so...virtualization is a pretty darn complex
>thing to do in a flexible way. This might be why other projects have been
>spawned to take away some of the logic from a single massive project and
>place that logic into smaller, more focused projects.
>
>However, I would argue that the barrier of entry is too high for this
>strategy to work. Projects such as Quantum, Burrow, Lunr, and Keystone
>suffer from the lack of a single cohesive strategy in the following areas:
>
>-Logging
>-Configuration
>-WSGI
>-RPC
>-Database
>-Testing
>-Deployment/Distribution of code
>
>These are the building blocks which most projects will require, yet every
>project has to create their own implementations? Sure, it's not going to
>be easy, and maybe some categories I've labeled won't make the final cut,
>but I would like to start a conversation with the community as to the
>feasibility of such an endeavor.
>
>This is not the first time such a project has been brought up. Much
>earlier in the year, a number of people suggested moving "lazy loading"
>code into a common project. I would like to think that project died due
>to complexity rather than the community rejecting the idea.
>
>To create a common library of this nature requires a bit of pushing aside
>one's partisan blinders and the abandonment of ideological
>entrenchments*, so hopefully this won't deteriorate into a FLAGS vs.
>argparse flame-war.
>
>TLDR: No
>
>* - Shamelessly stolen from The West Wing (tm)
>
>
>
>
>_______________________________________________
>Mailing list: https://launchpad.net/~openstack
>Post to     : openstack@xxxxxxxxxxxxxxxxxxx
>Unsubscribe : https://launchpad.net/~openstack
>More help   : https://help.launchpad.net/ListHelp

This email may include confidential information. If you received it in error, please delete it.