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

[Justin B Rye]

Thomas Goirand wrote:
[...]
>>> 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...

I'm still not sure which that makes it, but I'm hoping it's one of
those cases where either will do.

>>>  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.

So what it's trying to say is that Cinder "is a separate project from
nova-volume, which it directly replaces"?  In the original it wasn't
clear what it was that was separate; it still isn't entirely clear
what it's saying it's separate *from*, since after all they're all
part of OpenStack.
 
[...]
>>>  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.
[...] 
>> 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
> understanding.

That's not what it's saying, though.  It's claiming to support both
API 1 and API 2, which is a bit baffling for people reading this in
the package description for the plugin handling API 3!

Maybe it should be something more along the lines of

  Heat is a service to orchestrate multiple composite cloud applications
  using templates. It supports several API plugins including an
  OpenStack-native ReST API and a CloudFormation-compatible Query API.

(Why "API", anyway?  I don't see any Application Programming going on
here - should I perhaps be thinking of it as standing for "Access
Protocol", as in SOAP?)

[...]
>>> 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.

Yes, and my point is that at present both of them claim they should
run on every compute node (i.e. you should always have both).  Instead
I was suggesting it should be something like:

 Package: quantum-plugin-openvswitch-agent
 [...]
 This package provides the agent which should run on each compute node
 connected via Open vSwitch.

 Package: quantum-plugin-linuxbridge-agent
 [...]
 This package provides the agent which should run on each compute node
 connected via Linux bridge.

>> WhyTheName appendix: these names are great.
[...]
>>  * 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.

Sure, but literal keystones are just blocks of masonry, with no
cryptographic features.  So in effect it's a pun.
 
>>  * 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.

(And "Nebula" of course is Latin for "cloud".  It's a bit
disappointing that nobody's used "OpenCluster".)
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package