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

[Thomas Goirand]

On 04/09/2013 02:36 AM, Justin B Rye wrote:
>> 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.

How about:

"Cinder re-implements the features of nova-volume, which it directly
replaces, in a project separated from Nova."

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

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

Can you write a better long description now?

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

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

Your thoughts?

Thomas