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

[Thomas Goirand]

Hi,

First, sorry that it took me a long time to write this and do the work
(as lots of thoughts have been put to it, it unfortunately couldn't be
done faster). Hoping that what is written below will satisfy all partie
involved...

The view of the FTP masters is that having too many binary packages in
the archive adds effort on the Debian infrastructure as a whole. So if
possible, it is desirable to reduce the amount of binaries. I do agree
with this view, though there are functionality and use cases in Nova who
imposes a big number of binary packages. I will try below to explain
why, and tell what has been done to reduce the number of packages.

Here is the (admittedly, impressive) list of binary packages produced
currently by the source package in the NEW queue (so, this is prior to
some rework to remove a few binary packages, as we tried to do what was
asked):

Package: python-nova
Package: nova-common
Package: nova-compute
Package: nova-compute-lxc
Package: nova-compute-uml
Package: nova-compute-xen
Package: nova-compute-qemu
Package: nova-compute-kvm
Package: nova-xcp-plugins
Package: nova-xcp-network
Package: nova-conductor
Package: nova-cert
Package: nova-scheduler
Package: nova-volume
Package: nova-xvpvncproxy
Package: nova-novncproxy
Package: nova-api
Package: nova-network
Package: nova-objectstore
Package: nova-console
Package: nova-consoleauth
Package: nova-doc
Package: nova-cells
Package: nova-baremetal
Package: nova-spicehtml5proxy

Just FYI, I have attached the list of packages available in Ubuntu built
out of the nova source package. They provide 12 more binaries than the
Debian version.

The following work has already happen:

1/ Console proxies
Package: nova-xvpvncproxy
Package: nova-novncproxy
Package: nova-spicehtml5proxy

have already been merged into:

Package: nova-consoleproxy

using a /etc/default/nova-consoleproxy configuration file and a debconf
interface to select which daemon should start.

2/ Nova XCP plugins
Package: nova-xcp-plugins
Package: nova-xcp-network

have been merged into:

Package: nova-xcp-plugins

3/ Nova objectstore
This package was removed completely, because from the view point of the
team, it isn't essential (since Ceph and Swift provide the same
functionality with better implementations). We also believe there is
only a very limited number of users.

I will here explain why we need each of the remaining binary packages,
once more, in the hope to be more convincing this time. In order to make
it easier to understand, I have separated the argumentation below into
categories of binary packages.

Common packages
===============
Package: python-nova
Package: nova-common

Python-nova contains all the python files and modules needed by Nova.
Any daemon depends on that. It would be very surprising if the FTP
Masters think that package may go (this is a very common practice in
Debian), so I will not comment much.

nova-common contains all the installation logic, including Debconf and
postinst, so that any instance of daemon may run once the software is
configured.

Xen-API plugins
===============
Package: nova-xcp-plugins
Package: nova-xcp-network
-> merged into nova-xcp-plugins

Package to interface with Xen-xcp, one of the many hypervisor
supported by OpenStack.  As it is an option, it needs to remain a
separate package. It also needs to be installed in a complete different
context as the rest of OpenStack. Though it is truth that only a single
binary package could be used, so therefore the 2 binaries were merged
into a single "nova-xcp-plugins" package.

Backward compatibility
======================
Package: nova-volume

is a meta package which depends on Cinder. It is there for backward
compatibility and "upgradability", and it is a transition package.

Package: nova-network

Same reason (eg backward compatibility reasons), though nova-network is
still in use by many users (it is slowly being replaced by Quantum, but
it is still a workable package, and it's not a meta package like
nova-volume). Sooner or later, it will simply go away (when Quantum will
support all of Nova-network use cases). I expect it to be removed form
upstream on the next release in October, or maybe in April 2014 at most.

Package: nova-objectstore

This daemon provides an S3 API compatibility. One day, it might go away
upstream, since both Swift and Ceph can do that in a better way. Rather
than having a /etc/default file to decide to start it or not, the choice
has been made to completely kill this binary package.

Doc package
===========
Package: nova-doc

This is a normal -doc package. No comments.

Compute modules
===============
Package: nova-compute
Package: nova-compute-lxc
Package: nova-compute-uml
Package: nova-compute-xen
Package: nova-compute-qemu
Package: nova-compute-kvm
Package: nova-xcp-plugins
Package: nova-xcp-network

It seems one of the packages that have been contested is the
nova-compute* series. However, for OpenStack users, that's the part
which makes the most sense.

- Each and every binary package in Nova may carry additional dependency.
This isn't the case for all of them, because the team lacks expertise in
some of the hypervisors supported by Nova so we could write some
sensitive dependencies. But it is expected that, in the near future, we
will have more dependencies added (I'm namely thinking about the LXC
support, for which I don't know any user ATM). Here is a few examples
though:
  * nova-compute-uml depends on user-mode-linux
  * nova-compute-xen depends on python-xenapi
  * nova-compute-qemu depends on qemu
  * nova-compute-kvm depends on kvm
  * etc.

Since it is not realistic to make our users resolve dependencies by
hand, this is designed as a helper for our users so that packages are
installed automatically, and the list of dependencies don't have to be
documented.

Now, depending on which nova-compute-*, we have some postinst script.
For example:

if [ "$1" = "configure" ]; then
    adduser --quiet nova libvirt
fi

This happens only for those hypervisor that are using libvirt. For
example, nova-compute-xen, which doesn't use libvirt, has a different
postinst script which doesn't manipulate the nova user groups.

Also, every nova-compute-* package carries a
/etc/nova/nova-compute.conf, which holds hypervisor specific
configuration. For example nova-compute.conf, in the case of
nova-compute-kvm, looks like this:

[DEFAULT]
compute_driver=libvirt.LibvirtDriver
libvirt_type=kvm
libvirt_ovs_bridge=br-int
libvirt_vif_type=ethernet
libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver
libvirt_use_virtio_for_bridges=True

For all nova-compute-* using libvirt, there is a different value for
libvirt_type=.

When it is nova-compute-xen, we have:

[DEFAULT]
compute_driver=xenapi.XenAPIDriver
xenapi_connection_url=http://www.example.com
xenapi_connection_username=root
xenapi_connection_password=PASSWORD

and the above are maintained by debconf. Shipping all nova-compute-* as
a unique binary would prevent from doing this. Sure, we could maintain
all of that using debconf only, but it would be harder to maintain.

For Package: nova-baremetal
we have the same issue. Eg: default setup of nova-compute.conf, and pull
of some dependencies, even though dependencies (IPMI and pxe) haven't
been worked out yet. Please note that upstream is currently working
toward having nova-baremetal as a separate project, so it may go away
when this is done upstream.

API package
===========
Package: nova-api

This package already holds debconf, so it is possible to select which
API server will run. There was normally 4 daemon (Ubuntu does that), and
I've stripped-down to a single one, editing the configuration directive
in /etc/nova/nova.conf. This is a key component, which we believe needs
to stay as a standalone package, because it may be needed to run either
on a compute node (using the metadata API service only), or on a proxy
node (where it could run alone, or together with other services).

Console package
===============
Package: nova-console
Package: nova-consoleauth

Package: nova-spicehtml5proxy
Package: nova-novncproxy
Package: nova-xvpvncproxy

-> merged into nova-consoleproxy

There are 3 types of console in Nova. First, there's one for Xen-API,
then there's 2 types of console package available for KVM: the NoVNC
one, and the SpiceHTML5. The later only works with modern browsers which
support web sockets, while NoVNC will work with only HTML5 support (so
it should work with older browsers, but should also be slower).

If someone is running Xen-API, then every compute node would run
nova-console, which also provides auth. nova-console has a Provides:
nova-consoleauth. So, it is my understanding that with Xen-API, one
doesn't need to run nova-consoleauth at all (though I'm not an OpenStack
+ XCP user anymore).

If running with KVM, then one must choose to run either
nova-spicehtml5proxy or nova-novncproxy on each compute nodes, which are
"plugged" as video cards for each virtual machines.

Then nova-consoleauth is setup once only, to provide the authentication
system (using keystone tokens, I believe).

The problem with merging these, is that spicehtml5proxy needs to depend
on the spice-html5 package, and that novncproxy needs to depend on
websockify and novnc. Merging it forces to either add these 3 packages
as dependency (so, uselessly installed package), or force the user to
manually resolve the dependencies. The former has been done.

While it is ok to merge the *proxy packages, it isn't desirable to merge
them with the consoleauth, because they scale in a different way. For
the console daemons, you need to run with HAproxy, while the console
auth doesn't need it. So for large deployments, that would be problematic.

Other packages
==============
Package: nova-conductor

Nova-compute nodes connect to that package which acts as a proxy to the
MySQL server. It is there as a security component. It would typically be
setup only once, next to the MySQL server.

Package: nova-scheduler

Nova-scheduler is the daemon which decides where a given VM is started
when "nova boot" is called. A single instance of this package is
necessary, and it can be instantiated multiple time for scaling purposes.

Package: nova-cells

Nova-cells handles availability zones inside a single region, and relays
the nova-api central daemon (eg: the "one per region" nova-api daemon)
queries to that availability zone. There is no logic at all to mix this
with another binary package (that would also be very confusing).

Package: nova-cert

Nova-cert would typically run on each compute node, to handle X.509
certificates management, used to access the platform. Though it doesn't
have to run there, a single instance setup is also possible (at least,
that is my understanding). So mixing it with another daemon isn't
desirable: it would remove the possibility to hardwire the installation
of this package in openstack-compute-node, which is a meta package
provided by the openstack-meta-packages source package.

The 4 packages above run in very different context. Merging them would
make deployments more complicated, and there would be no logic from a
user point of view to have them together (in other words: it would be
very confusing).

Other non-technical reasons
===========================

These are the technical justification for why we need to keep the binary
package layout as it is right now. But there are also social parts which
are involved.

- This layout makes it easier to understand each and every component.
And as OpenStack is all but simple to install, it isn't desirable to
make it even more complicated, with some /etc/default things to tweak on
each install.

- Ubuntu users are used to this layout, and if they wish to switch to
Debian, it would be best to keep what they are used to, and which works
already.

- A lot of users have already written some puppet or chef setup scripts
that currently work for both Debian and Ubuntu. Changing the layout
would break their scripts. We would like to avoid that.

- Running with a single binary would force to have more debconf screens
and/or more configuration file editing. There is already too much of
that in OpenStack, so we would like to avoid it if possible.

And the most important of the non-technical argument:

- There is an ongoing effort to add support for Debian inside the
OpenStack documentation. Currently, there is a single Git repositories,
with xml files that are used to generate the docs. In there, there are
things to select if the documentation is relevant to Fedora/CentOS, or
to Debian/Ubuntu. It is the view of the whole OpenStack community that
it is best if we can keep a single documentation for all operating
system. The more the Debian packages are different from the ones in
Ubuntu, the more this becomes difficult to use a single documentation.
Scrapping the current binary layout and make it radically different from
what is in Ubuntu doesn't go in the good direction, and will make it
harder to keep a unified doc. Anne Gentle, who is the "doc-master"
already told me that she wishes to keep one doc only.

For the above reasons, the team would like to keep the current binary
package layout, minus the changes that have already been done (eg:
merging the consoleproxy daemon packages and the XCP plugins).

Following the FTP master advices, everything that could possibly be
merged was done, some time at a high expense. Other changes would go
even more against the logic of our users, breaking the modularity and
ease of setup in a scalable way, which is why it is not desirable to go
further and merge/kill more binary packages.

For the OpenStack packaging team,
Thomas Goirand (zigo)

P.S: Note that I haven't uploaded (yet) the latest version of Nova in
Sid, as I am waiting for your approval of the above.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ubuntu-package-listing.txt
URL: <http://lists.alioth.debian.org/pipermail/openstack-devel/attachments/20130530/9fa226d4/attachment.txt>