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.car...@gmail.com> 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.la...@rackspace.com> 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@lists.launchpad.net >>> 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@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp