openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #03346
Re: OpenStack Common
Thats a better direction. Another way to think about this is to consider this an extensible service framework. If we agree on lightweight code wrappers (apis/modules) first with whatever "backend" each project uses, and then migrate each of those areas to a common implementation, we can inject uniformity and expected levels of instrumentation/capabilities across the projects. Example: log4j extender model...
Jan
On Jul 25, 2011, at 10:27 AM, "Brian Lamar" <brian.lamar@xxxxxxxxxxxxx> wrote:
> I don't see it as multiple projects, just as a set of modules:
>
> openstack.common.config
> openstack.common.deployment
> openstack.common.logging
> ...
> etc.
>
> These are purely modules which help you create you're own OpenStack-compatible project...all available through a single openstack-common project.
>
> -----Original Message-----
> From: "Glen Campbell" <glen.campbell@xxxxxxxxxxxxx>
> Sent: Monday, July 25, 2011 1:20pm
> To: "Brian Lamar" <brian.lamar@xxxxxxxxxxxxx>, "openstack@xxxxxxxxxxxxxxxxxxx" <openstack@xxxxxxxxxxxxxxxxxxx>
> Subject: Re: [Openstack] OpenStack Common
>
> 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.
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help : https://help.launchpad.net/ListHelp
>
References