[Openstack-devel] Rename of Quantum to Neutron and transition packages

[Thomas Goirand]

Dear FTP masters,

Sorry for the length of this email, though I believe it's needed so that
everyone understand and can answer my question a the end of this message.

Currently in Debian, we have Quantum, which is doing OpenStack network.

Unfortunately, it was renamed to Neutron upstream, due to a trademark
issue from the "Quantum" company (bought by Seagate IIRC).

The source package generates a lot of quantum-plugin-* packages, which I
removed. Currently, the Neutron source package only generates the
following binaries:

Package: python-neutron
Package: neutron-server
Package: neutron-common
Package: neutron-plugin-nec-agent
Package: neutron-l3-agent
Package: neutron-dhcp-agent
Package: neutron-metadata-agent
Package: neutron-lbaas-agent
Package: neutron-plugin-openvswitch-agent
Package: neutron-plugin-linuxbridge-agent

The *-agent packages are needed, because they will be deployed in
different physical computers than the central neutron-server package,
and they have multiple ways to scale. For example, the openvswitch-agent
and the linuxbridge-agent would be deployed on the compute nodes, and on
the neutron-server node, while typically, there would be a single
neutron-server running on a given OpenStack deployment. The l3-agent
could be running on more than a server to provide HA.

Currently, in Quantum, we have the following packages:
Package: python-quantum
Package: quantum-server
Package: quantum-common
Package: quantum-plugin-cisco
Package: quantum-plugin-nec
Package: quantum-plugin-nec-agent
Package: quantum-plugin-bigswitch
Package: quantum-plugin-hyperv
Package: quantum-plugin-brocade
Package: quantum-plugin-plumgrid
Package: quantum-plugin-metaplugin
Package: quantum-plugin-nicira
Package: quantum-l3-agent
Package: quantum-dhcp-agent
Package: quantum-metadata-agent
Package: quantum-lbaas-agent
Package: quantum-plugin-openvswitch
Package: quantum-plugin-openvswitch-agent
Package: quantum-plugin-linuxbridge
Package: quantum-plugin-linuxbridge-agent

While writing the Neutron package, I removed all the plugin packages
(for example, quantum-plugin-cisco, quantum-plugin-nec,
quantum-plugin-bigswitch, etc. are gone). The user would simply select
which plugin to use using debconf, or configure the core_plugin
directive in /etc/neutron/neutron.conf. Then the init script
/etc/init.d/neutron-server looks at that directive, and loads the
/etc/neutron/plugin/<plugin-name>/<plugin-name>.ini accordingly when
starting the neutron-server daemon (and others).

In Ubuntu, I saw that they provided some transitional packages this way:

Package: quantum-server
Depends: neutron-server, ${misc:Depends}
Architecture: all
Section: oldlibs
description: transitional dummy package
 This is a transitional dummy package. It can safely be removed.

Package: quantum-common
Depends: neutron-common, ${misc:Depends}
Architecture: all
Section: oldlibs
Description: transitional dummy package
 This is a transitional dummy package. It can safely be removed.

Package: quantum-plugin-cisco
Depends: neutron-plugin-cisco, ${misc:Depends}
Architecture: all
Section: oldlibs
Description: transitional dummy package
 This is a transitional dummy package. It can safely be removed.

So my question is:
It is not desirable to have so many packages in the archive, and Nova
has been blocked on that ground for more than 6 months. Since I would
like to avoid it again, could the FTP Masters tell me if it is
acceptable to create all these "transitional dummy package"? I for sure
think it's a needed feature, though if it is the view of the FTP masters
that it shouldn't happen, then I will avoid doing it and add 20 packages
to the archive. Of course, this would happen only for a release cycle,
and the transitional packages would be remove in Jessie+1.

Please let me know ASAP. In the mean time, I will write it with the
transitional packages and upload to Experimental, but will remove them
if needed.

Cheers,

Thomas Goirand (zigo)