openstack team mailing list archive

[Soren Hansen <soren@xxxxxxxxxx>]

2011/4/4 Thomas Goirand <zigo@xxxxxxxxxx>:
> I'm Cc:-ing the list (and changed this silly subject that I used), if
> you don't mind.

Sure. We usually do this through merge proposals, though, but whatever
works.

> On 04/04/2011 08:42 PM, Soren Hansen wrote:
>>  * You refer to a "cloud controller". There's no such thing.
> Then the docs in docs.openstack.org are wrong!!!

Easy now. Ok. The docs are wrong. It happens.

If you've got all of api, scheduler, objectstore, and network installed
on one machine, people tend to refer to that machine as their "cloud
controller", but Nova has no component called "the cloud controller", so
you can't really say that anything "communicates with a cloud
controller", because it's not a "thing".

>>  * In nova-objectstore.logrotate, you've replaced the upstart style
>>    "restart" with "invoke-rc.d restart".  Please don't do that.
> I thought that was a bug, but it was intended. YADAUD (yet another
> debian and ubuntu difference). I corrected and did:
>
>        if dpkg-vendor --derives-from ubuntu ; then
>            restart nova-objectstore
>        else
>            invoke-rc.d restart nova-objectstore
>        fi

Ideally, we'd apply this at build time, but this is fine.

>>  * In all the package descriptions, you changed the the part about our
>> mission to read: "OpenStack produces an ubiquitous and reliable [...]".
>> Whether it's reliable is debatable, but ubiquitous it certainly isn't.
>> Please change it back to read "The OpenStack mission is to produce..."
> A package description doesn't describe a "mission", or the future
> intended goals, but a software in its actual state.

Says who, exactly?

A quick glance at Debian repository reveals numerous examples of this
sort of thing. Apache, for instance, has this in its long description:

 The Apache Software Foundation's goal is to build a secure, efficient and
 extensible HTTP server as standards-compliant open source software. The
 result has long been the number one web server on the Internet.

Automake has this:

 The goal of Automake is to remove the burden of Makefile maintenance
 from the back of the individual GNU maintainer (and put it on the back
 of the Automake maintainer).

awffull has this:

 As a base, weblizer has a stated goal of producing web server analysis.
 AWFFull on the other hand, will gradually focus more on the business
 intelligence contained within those logs - and not specifically limited just to
 web server logs.

..and I didn't even make it to the end of the packages beginning with
'a' to find these examples.

miniupnpc, which you maintain, says "Miniupnpc aims at the simplest
library possible, with the smallest footprint[...]". :)

I think it's useful information about the package, and there's plenty
of prior art.

> So I think we have to think about it more and do a better, more
> relevant description.

I think it's perfectly relevant to sum up what the point of OpenStack
is. It helps set expectations.

>>  * I'd also like to keep "nova" in the short description.
> It's redundant with the package name itself! We don't need it.

That's a good point. Ok, let's ditch it.

I just want to mention, though, that there's plenty of prior art to
this, too.  Every single apache packages says "apache" in its short
description. Several of your dtc packages also say "dtc" in both short
description and package name. :) It's not exactly unheard of.

>>  * The short description for the adminclient seems to have been cut off?
> Ah? I don't think so...

To my eye, "Python adminclient library for the OpenStack Compute cloud
computing" either lacks a word at the end, or has a superfluous "the" in
the middle. It's moot, though, since the adminclient package is history
as of an hour or so ago.

>>  * Don't make xen-linux-system preferred over kvm.
> Is that important since Xen isn't available in Ubuntu?

It probably will be, but Ubuntu's preferred hypervisor is still KVM.

> Also, it's my understanding that people in Rackspace do prefer Xen,
> like I do. Anyway, I did as you asked, but I'd be happy to have your
> thoughts, and the ones of others about this.

Ubuntu's preferred hypervisor is not up for discussion (in this forum,
at least).

>>  * I don't understand the change you made to some of the packages'
>>    descriptions about a Service object?
> Which one? Where?

nova-compute, nova-volume and nova-network all say stuff about loading
"a Service object which exposes the public methods[...]".

>> The reason I've explicity only done sqlite so far is because the upgrade
>> scenarios with a shared data store is impossible to automate from
>> maintainer scripts. Upgrades that require schema changes so far need to
>> be synchronised across all components on all nodes in the
>> infrastructure, so if people aren't using sqlite, I'd rather just not do
>> anything at all. For now.
> The point is not only to have a choice with sqlite, but also to be able
> to choose the credentials for contacting the MySQL db. It should be
> possible to set only postgress and mysql as possible choices in
> dbconfig-common.

Fine. As long as you make sure that under no circumstances will we
attempt to run a db sync against a shared data store.

> I also worked on swift. Can you have a look? I'm not so sure what I did
> is fully correct yet, because I didn't succeed in running everything
> fully. It seems that swift doesn't like using device-mapper as
> partitions, is that correct? Which leads me to reinstall my test server
> from scratch, leaving some empty partitions for swift then. Or do you
> think this could be fixed, somehow?

I'll have to defer to the honourable Swift devs on this list on this.

-- 
Soren Hansen
Ubuntu Developer    http://www.ubuntu.com/
OpenStack Developer http://www.openstack.org/