Open Stack

On Fri, Aug 3, 2012 at 1:35 PM, Monty Taylor <mordred at inaugust.com> wrote:

>
>
> On 08/03/2012 12:32 PM, Doug Hellmann wrote:
> >
> >
> > On Fri, Aug 3, 2012 at 11:24 AM, Mark McLoughlin <markmc at redhat.com
> > <mailto:markmc at redhat.com>> wrote:
> >
> >     On Fri, 2012-08-03 at 10:16 -0500, Monty Taylor wrote:
> >     > On 08/03/2012 09:57 AM, Kevin L. Mitchell wrote:
> >     > > On Fri, 2012-08-03 at 17:48 +0300, Gary Kotton wrote:
> >     > >> Will you also be fixing the pep8 issues in the common code?
> >     > >
> >     > > When the pep8 running in openstack-common reports the issue,
> yes, it
> >     > > will make sense to fix it.  Since I have already synchronized
> >     nova and
> >     > > glance, I'm highly reluctant to make the necessary change.  I'll
> >     also
> >     > > point out that the particular condition that pep8 is reporting
> >     here is
> >     > > all over the place in nova and probably also in glance…
> >     >
> >     > If we keep openstack-common testing against latest pep8 (even when
> >     it's
> >     > a pita) it should allow us to drop that code into any of the
> projects
> >     > without worrying about which version they've caught up to.
> >
> >     Yeah, I'm fine with us using latest pep8.
> >
> >     > Also - I hear that one of these days we're going to make a library
> out
> >     > of openstack common ... how's that coming Mark?
> >
> >     There are two parts - figuring out which APIs are ready for the
> >     backwards compat commitment and sorting out the pure mechanics of
> doing
> >     the library release.
> >
> >     I was mostly blocked on the first part and this week took a look at
> the
> >     RPC API to see if it's ready:
> >
> >
> https://blueprints.launchpad.net/openstack-common/+spec/rpc-api-review
> >
> >     The summary from a first review is that it's not too far away, but
> does
> >     need more work. Just doing a thorough review is pretty time
> consuming,
> >     though, nevermind fixing the issues themselves.
> >
> >     Talking it over with Russell, we thought it might make sense to
> tackle
> >     the second part of the problem first - if e.g. we're happy with the
> >     state of cfg, we could do an initial library release with just that
> and
> >     be happy we have the mechanics sorted out. Then we can iterate
> through
> >     reviews of the other APIs and add them to future releases.
> >
> >
> > Are we still planning to have a single monolithic library? I would
> > really like for us to consider releasing smaller reusable chunks that
> > might be usable/useful in projects other than OpenStack.
>
> I'm fine with supporting either, depending on how interdependent they
> are. Main thing is one library == one repo. As long as we stick to that,
> it should be a piece of cake. If we want these to be things like
> "openstack-common-config" which provides openstack.common.config, then
> we'll probably want to hit-it with some namespace packages.
>

I was thinking a single namespace package "openstack" with single-level
nested packages such as openstack.config, openstack.messaging (to include
rpc and notifications), openstack.server (service and manager-related
stuff, maybe also the wsgi stuff). The "common" feels a little redundant.

OTOH, it would be even better if we came up with names that didn't include
"openstack" in the distro or package name. That would help avoid the
Zope-branding issue that keeps other projects from adopting a lot of the
useful components that came out of the Zope project just because they are
apparently tied to Zope. Of course, naming is one of the hard problems in
compsci. :-)

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120803/fa72e0c5/attachment-0001.html>