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

[Justin B Rye]

Thomas Goirand wrote:
> On 04/09/2013 02:36 AM, Justin B Rye wrote:
>> 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.
> 
> How about:
> 
> "Cinder re-implements the features of nova-volume, which it directly
> replaces, in a project separated from Nova."

Saying they're "separate" just means they aren't the same thing;
saying they're "separated" makes it sound as there was some sort of
air-gap between their git repositories.

It's probably not worth saying any more than "It re-implements the
features of nova-volume, which it directly replaces."  If B replaces
A, it's obvious that B isn't the same as A.
 
>>>> 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.
> 
> Hum... it wasn't clear for me either, it seems...
> 
> Maybe it will be more clear with a small drawing:
> 
> client ------> heat-api ------------> Nova / Quantum / Glance / etc.
>        CFN API          OpenStack API
>           or
>       CloudWatch
>           or
>       OpenStack
>       ReST API

The package description's only talking about the first arrow, though,
isn't it?
 
> Both CFN and CloudWatch are APIs from AWS. But for CloudWatch, the
> authors just told me on IRC: "i'd suggest just ignoring cloudwatch for
> the moment since we don't really implement cloudwatch".

Not even in heat-api-cloudwatch?

> Can you write a better long description now?

If we don't need to worry about CloudWatch being skipped from the list
of client-side APIs then there's nothing to fix.

>> (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?)
> 
> We're talking about ReSTfull API here. So it's all queries over HTTP, a
> bit comparable to SOAP yes. Though I'm not sure it's "Access Protocol"
> that we are talking about.

I was just suggesting (not entirely seriously) that these run-time
interfaces between OpenStack components are more reminiscent of the
Simple Object Access Protocol than of a literal Application
Programming Interface.  After all, software APIs operate at the level
of source code development, not even at compile-time!  So maybe "web
APIs" should be reinterpreted as involving a different sort of AP...
 
>>  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.
> 
> How about:
> 
>   Package: quantum-plugin-openvswitch-agent
>   [...]
>   This package provides the Open vSwitch agent. If you choose to use
>   the Open vSwitch plugin on quantum-server, this agent should run on
>   each compute node.
> 
>   Package: quantum-plugin-linuxbridge-agent
>   [...]
>   This package provides the Linux bridge agent. If you choose to use
>   the Linux bridge plugin on quantum-server, this agent should run on
>   each compute node.
>
> It's also to be noted that we have put Provides: quantum-plugin in each
> plugin, and a Depends: quantum-plugin in quantum-server just in order to
> make sure that a plugin will be installed on the quantum-server (which
> is the API server for Quantum). Though the agent on the compute nodes
> has to match the plugin on the quantum-server, and I believe the above
> makes it more clear.

I spent a while trying to find a good way of expressing that and then
realised that your version above did it better.
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package