Re: [Openstack-devel] Bug#704949: Bug#704949: cinder: [debconf_rewrite] Debconf templates and debian/control review proposal
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
Reply to: