[Openstack-devel] nova_2013.1-1_amd64.changes REJECTED

[Thomas Goirand]

On 04/11/2013 06:04 AM, Joerg Jaspert wrote:
> Adding lots of tiny packages where the metadata has
> more size than the actual use data of the package is bad enough that it
> warrants a reject. Independent of our knowledge of the package -
> thats why you can just explain stuff if its really needed.

Ok, I will try once more then. But this means explaining how OpenStack
works, and as it is a complex software, it will not be a small explanation.

First of all, the split in these binaries is the same on other
distributions. So out of consistency, and because our users are
expecting things to work the same way on multiple distributions, I think
it isn't a good idea to have things made a special way in Debian.

Also, integrators already run puppet / crobar / you-name-it scripts
which are taking into account these package names. Switching to a single
binary that would hold all of the daemon and init scripts would simply
break badly this kind of setup scripts, and I don't want to do that.

That's for the first part (eg: standardization across distributions).
Now, let me explain the logic behind it, for which I need to explain
what package does what.

First, the compute package, which is the part that start and stops
virtual machines, works with a deamon. This daemon init script is
installed in the "nova-compute" package. This package depends on
compute-<whatever>, with <whatever> being kvm, lxc, qemu, uml, or xen,
with each of these packages conflicting each other, to make sure that
only one of them is installed at a time. Each of the nova-compute-*
package holds a configuration file named /etc/nova/nova-compute.conf
which defines what type of hypervisor is in use. With this setup, it
makes it possible to have nova-compute working out of the box, without
further manual configuration (which is always nice to avoid).

Then you have nova-common. This one contains the configuration files,
and the Debconf setup. All other package depends on that one. I think
this is pretty standard.

Then you have nova-xcp-network and nova-xcp-plugins. These are to be
installed in a Xen dom0 running XCP (Xen Cloud Platform, which I also
maintain in Debian), and act as plugins, as the name suggest. No other
nova package would be needed in this server.

Then we have nova-api, which runs ... (suspense) the nova API. This
could be setup in a server which would run no other task. Again, having
a separate package helps to ease the setup. There is already a debconf
system so that I could avoid to have nova-api-metadata, nova-api-ec2,
and nova-api as separate packages, as this is already configurable in
the /etc/nova/nova.conf file, and that I thought it was better to avoid
to add even more binaries. Note that this is different from what they
did in Ubuntu, and that I might at some point revert this choice.

We also have nova-cells, which isn't mandatory. It is there to do a kind
of compartmentalization of compute nodes, so that in a given region, you
have multiple "cells", which also adds high availability. Not everyone
would need that service (only big providers).

The nova-network package is something of the past, used only for more
simple setups. Networking virtualization is now handled by Quantum, but
some users might still want to run the older system which was integrated
in Nova at the beginning of the project. It is a bit the same situation
for nova-objectstore (it is advised to use Swift instead). Nova-volume
is also something of the past, currently replaced by Cinder, which is
also now a separate project. Still, some users might wish to use it also.

The nova-network daemon could be run once (eg: one for all of your
cloud), or on each compute nodes. Nova-objectstore or nova-volume would
typically run alone on a single server, but they could also run on the
same server running the compute load. These choices are left to the
administrators.

The nova-conductor daemon is there to forward the SQL requests of the
nova-compute daemons to the MySQL server. It is something new. Without
this daemon, nova-compute cannot report itself to the system.

Nova-scheduler is the part that decides where VMs should be started (eg:
in which compute node).

Then you have nova-console, nova-consoleauth, and nova-spicehtml5
nova-xvpvncproxy. These aren't mandatory as well (you could well just
ssh into your VMs), and would run in compute nodes.

As you can see, we really have many types of services, which are used
for very different tasks. It would be possible to use a configuration
file to select which one to start, but it wouldn't be as nice, as it
would make it harder to select which service to install. Note that it is
well possible to use dedicated servers for a single workload. Someone
might want to run nova-api on 2 servers, using haproxy as a load
balancer, for example, or with heartbeat to add high availability.

Also, having less binary package would make it impossible to write a
meta package which would select which service to run, depending on a
given use case (which is what I tried to do with the
openstack-meta-packages, still pending in the NEW queue).

Note that the openstack-meta-packages is implementing a single use case,
and doesn't pretend to cover all use cases. Its goal is to make it
possible to simply do "apt-get install openstack", and then it just
works, so that it is possible for newbies to have a working system with
either a single node (if you install openstack-toaster), or with a
single controler (apt-get install openstack-proxy-node) and multiple
compute servers (apt-get install openstack-compute-node).

> And with what we got yet *I* still don't buy it that we need one package
> per script, or worse - for one file in /etc.

Probably you should try OpenStack, and be dizzy for a whole year about
its complexity, and then learn how to love its modular design! :)  I
would be happy to work with the DSA if they would like to experiment
with OpenStack as well. I'm sure there are many use cases where it could
be useful.

>> Please limit yourself to what you are supposed to do: license checks.
> 
> Please limit yourself to statements about things you know. Thanks.

The only thing which I was saying was that I thought the BTS, or the PKG
OpenStack list (eg: openstack-devel at lists.alioth.debian.org) was a much
more appropriate mean to discuss this issue. OpenStack is all but simple
to understand, and the timing, plus the way you decided to discuss this
subject (eg: through a REJECT), is far from the best way to solve this.
I hope that next time, this can be the way to do it.

I took note of your remarks, and I will also raise your concern in the
OpenStack summit, and see what the Ubuntu team, and other distribution
maintainers think about it.

I truly hope you will find the above a satisfying answer. Please do not
leave this message rot. I am really expecting a timely answer (that is,
within 24 hours, considering the deadlines that I have). And I thank you
in advance for it, as I am convince you will find the above convincing.

Cheers,

Thomas