[Openstack-devel] Bug#704949: Bug#704949: cinder: [debconf_rewrite] Debconf templates and debian/control review proposal

Thomas Goirand zigo at debian.org
Mon Apr 8 15:53:24 UTC 2013

On 04/08/2013 09:20 PM, Justin B Rye wrote:
> I hope you don't mind if I pass the time by looking at your package
> descriptions.

Much appreciated indeed!

>> Source: ceilometer
>> Section: python
> Aren't people more likely to look for ceilometer-collector and so on
> under "net"?

While python is certainly not the correct section, I admit, "net"
doesn't fit either. I've set it to "web", although I think it's quite
not correct either. I wish there was "cloud"...

>> Description: OpenStack efficient metering counters system (Python libraries)
> That sounds a bit odd (is it a counters system or a counter system?),

Well, it really is a system of working on having multiple counters that,
together, does metering...

>>  Ceilometer aims to deliver a unique point of contact for billing systems to 
> s/unique/Single/ - SPOC is a standard piece of business jargon, but
> make it "a Single Point Of Contact for cloud service billing systems",
> since otherwise there's a serious shortage of context.

I did that, though I removed "cloud", since Ceilometer is generic enough
so that it could well one day work for something else than Openstack.

> slightly rephrasing the next sentence: "It is a direct replacement for
> the separate nova-volume project".

Quite not. The "nova" source package used to include "nova-volume"
(which is now removed from Nova Grizzly released last week). It was
decided to detach nova-volume from nova, and create cinder instead. The
way you phrase it, it looks like nova-volume is a separate standalone
project, which is not the case.

>> Description: service to orchestrate multiple composite cloud applications (python files)
> Shorten that and capitalise "Python":
>   Description: OpenStack orchestration service - Python files
>>  Heat is a service to orchestrate multiple composite cloud applications using
>>  templates, through both an OpenStack-native ReST API and a
>>  CloudFormation-compatible Query API.
> s/Query/jQuery/g, right?

No. Just query. There's nothing related to jQuery here. The
CloudFormation API is something from Amazon AWS to do auto-scalling (eg:
start VMs automatically when you need them). Heat is compatible with it.

> Oh, and what about heat-api-cloudwatch?  Isn't that a third API?  I
> suspect the boilerplate should avoid trying to count them.  But I've
> left it for now.

Well, all together, they form a single query API. At least, that's my

>> Description: OpenStack Virtual network service - server
> Any particular reason for capitalising "Virtual"?

Nop. Good catch.

>>  This package provides a Linux bridge plugin to work with.
> Again I'm not sure what "to work with" is trying to imply.

This is already gone from the Grizzly package which I will upload
"soon", so do not worry.

>> Package: quantum-plugin-openvswitch-agent
> [...]
>>  This package provides the openvswitch-agent which should run on each compute
>>  node
> [...]
>> Package: quantum-plugin-linuxbridge-agent
> [...]
>>  This package provides the linuxbridge-agent which should run on each compute
>>  node
> What, so all compute nodes should run both openvswitch-agent and
> linuxbridge-agent?  Or should this say something about "This package
> provides the agent which should run on each compute node connected
> via {Open vSwitch,Linux bridge}"?

Well, you choose between Open vSwitch, or Linux bridge, then depending
on what you choose, you would install either OVS on each compute nodes,
or Linux bridge on each compute nodes. You can never have both... It's a
plugin thing.

> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> WhyTheName appendix: these names are great.
>  * ceilometer: an instrument for measuring cloud coverage.
>  * cinder: as in cinderblock - though n.b. the en_GB is "breezeblock"!
>  * glance: just arbitrary?
>  * heat: as in atmospheric dynamics.

Yeah... Because heat is what is needed to create cloud (eg: cloud
formation API, etc.).

>  * keystone: crucial, and sounds security-related...

Keystone does the Auth, and has a catalog of all OpenStack services, so
yes, it's crucial, and security related.

>  * nova: named after NASA's "Nebula".

Also, Nebula (the company) has remained the biggest contributor to
OpenStack over the years, and was the first to create Nova, which was
the first project started in OpenStack.

>  * quantum: I can only assume it's because it's unintelligible!

I'm not sure about that one.

I have applied all of your suggestions, apart from those I commented
above. Note that most descriptions where taken from upstream, so I'd say
something like this:

Q: What is the nicest thing with Debian package description?
A: They are even better than upstream!

Note that I have applied your changes to the latest version of
OpenStack, namely Grizzly, which I haven't uploaded yet into Debian, and
not to OpenStack Folsom, which you may find currently in Experimental.
That's because I intend to "soon" replace Folsom by Grizzly...

Same for the templates, I think best would be to work it out with what's
on Alioth, though I'm pretty sure they are currently exactly the same,
so there's nothing to worry about.

Thanks a lot for all your great work,


Thomas Goirand (zigo)

More information about the Openstack-devel mailing list