openstack team mailing list archive

[Todd Willey <xtoddx@xxxxxxxxx>]

One thing that might be added would be dynamic module and class
loading.  This has implications for flags/options and help output as
well.  It is something nova does, and I suspect keystone and others
will need to do as well.

On Mon, Jul 25, 2011 at 2:59 PM, Devin Carlen <devin.carlen@xxxxxxxxx> wrote:
> If by mini-projects you mean small and separate projects, then I don't think that makes sense.
>
> All we need for this is a single project that contains submodules that don't contain unnecessary dependencies on other submodules within the common project.  So lots of bite size pieces that can be used or not used.
>
> Devin
>
> On Jul 25, 2011, at 10:20 AM, Glen Campbell wrote:
>
>> 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
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>