[MIR] quantum

[Chuck Short]

Rationale: Part of the server-o-openstack-folsom specification.
Security: No known security history, however it needs to have a security review by the security team.
Quality Assurance: Package works out of the box but it needs to be configured for your specific setup. There is no major bugs in Ubuntu and the is no major bugs in Debian.
Standards Compliance: FHS and Debian Policy compliant.
Maintenance: Python package that the Ubuntu Server Team will maintain.
Dependencies: The majorify of the build dependencies are already in main, but there is still some outstanding like openvswitch.

[Jamie Strandboge (jdstrand)]

MIR review:
 * It builds with only main enabled
 * Has a test suite. There are two type of tests, functional and unit. TESTING
   says that unit can always be run. The testsuite currently fails with 9 errors
 * uses python2, but it is a server package so that is ok
 * The package does carry an Ubuntu delta
 * It has a watch file
 * It is mostly up to date (will be once this MIR is concluded)
 * Has some lintian warnings/errors:
quantum_2012.2~f2-0ubuntu1.dsc:
 W: quantum source: build-depends-on-python-dev-with-no-arch-any
 W: quantum source: out-of-date-standards-version 3.9.2 (current is 3.9.3)
quantum-common_2012.2~f2-0ubuntu1_all.deb:
W: quantum-common: empty-binary-package
W: quantum-common: maintainer-script-needs-depends-on-adduser postinst
uantum-plugin-linuxbridge_2012.2~f2-0ubuntu1_all.deb:
W: quantum-plugin-linuxbridge: empty-binary-package
quantum-plugin-linuxbridge-agent_2012.2~f2-0ubuntu1_all.deb:
E: quantum-plugin-linuxbridge-agent: postrm-does-not-call-updaterc.d-for-init.d-script etc/init.d/quantum-plugin-linuxbridge-agent
W: quantum-plugin-linuxbridge-agent: binary-without-manpage usr/bin/quantum-linuxbridge-agent
quantum-plugin-openvswitch-agent_2012.2~f2-0ubuntu1_all.deb:
E: quantum-plugin-openvswitch-agent: postrm-does-not-call-updaterc.d-for-init.d-script etc/init.d/quantum-plugin-openvswitch-agent
W: quantum-plugin-openvswitch-agent: binary-without-manpage usr/sbin/quantum-openvswitch-agent
quantum-plugin-ryu-agent_2012.2~f2-0ubuntu1_all.deb:
E: quantum-plugin-ryu-agent: postrm-does-not-call-updaterc.d-for-init.d-script etc/init.d/quantum-plugin-ryu-agent
W: quantum-plugin-ryu-agent: binary-without-manpage usr/sbin/quantum-ryu-agent
quantum-server_2012.2~f2-0ubuntu1_all.deb:
E: quantum-server: postrm-does-not-call-updaterc.d-for-init.d-script etc/init.d/quantum-server
W: quantum-server: binary-without-manpage usr/sbin/quantum-rootwrap
W: quantum-server: binary-without-manpage usr/sbin/quantum-server
 * debian/rules is clean
 * Errors/warnings during the build:
running build_py
WARNING: quantum is a namespace package, but its __init__.py does
not declare_namespace(); setuptools 0.7 will REQUIRE this!
(See the setuptools manual under "Namespace Packages" for details.)
 * Important bugs (crashers, etc) in Debian or Ubuntu
  * several important bugs which I'm told are known and should be fixed soon: 1023066, 1025203, 988999, 1021921
 * fix-namespace.patch does not have DEP-3 comments (not a blocker)

[Jamie Strandboge (jdstrand)]

Security review:
This review proved to be fairly difficult due to several bugs in OpenStack on 12.10 and also in quantum. That said, Quantum implements NaaS (network as a service) which is meant to overcome the shortcomings of networking in Nova directly. Overview at: http://www.slideshare.net/danwent/openstack-quantum-intro-os-meetup-32612

"Quantum is focused on managing the connectivity between interfaces of other OpenStack services"

No CVE history, no dbus services, no setuid, no use of fscaps and no cron jobs. Plugins and quantum-server installs initscripts. No listening services by default (quantum must be configured for your specific setup).

Quantum supports a rootwrapper like other parts of OpenStack, however none of the agents are setup to use it. Eg, from /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini:
# Change to "sudo quantum-rootwrap" to limit commands that can be run
# as root.
root_helper = sudo

The rootwrap functionality looks sane and it is implemented in a similar fashion as nova-rootwrap.

Spot checking other parts of the code, they look ok, but quantum/openstack/common/setup.py bypasses subprocess.Popen's shell meta injection protections in its _run_shell_command() implementation, but this file shouldn't be run by an attacker and the arguments are mostly filtered (though they could be improved).

[Jamie Strandboge (jdstrand)]

Conditional ACK provided the following are fixed:
- quantum-rootwrap is enabled everywhere
- the package is lintian clean
- the open bugs I mentioned are fixed

[Chuck Short (zulcss)]

This was taken care of in the last upload.

[Jamie Strandboge (jdstrand)]

Seeing some different lintian issues and I filed bug #1052702 for these. Most are not critical so I won't block the MIR on this. It is interesting that the quantum-rootwrap manpage is shipped in quantum-server but quantum-rootwrap itself is shipped in quantum-common.

I noticed that quantum is now configured to use quantum-rootwrap for dhcp and l3, and most of its plugins are too (linuxbridge, nec, openvswitch and ryu. However, cisco and nicira are not. Is quantum-rootwrap supported for these plugins?

[Chuck Short (zulcss)]

quantum-rootwrap is not supported for these plugins.

[Jamie Strandboge (jdstrand)]

Ah bummer. Please keep an eye on upstream changes in this area cause we definitely want to use the rootwrap is possible. ACK, please feel free to seed or add as a dependency/recommends for something in main.

[Matthias Klose (doko)]

again, this MIR was missing the check for depending packages, adding pyudev ...
component_mismatches should show this pretty well.

[Matthias Klose (doko)]

no, not fixed unless it is promoted (please do this together with pyudev)

[Matthias Klose (doko)]

pyudev was in main, then demoted. see bug #718774

[Matthias Klose (doko)]

both packages promoted