All neutron binaries are delivered by neutron-common

[Bartosz Kupidura]

Currently all binaries from neutron are delivered by neutron-common package:

# dpkg -L neutron-common|grep '^/usr/bin/'
/usr/bin/neutron-usage-audit
/usr/bin/neutron-rootwrap-xen-dom0
/usr/bin/neutron-debug
/usr/bin/neutron-bgp-dragent
/usr/bin/neutron-rootwrap
/usr/bin/neutron-keepalived-state-change
/usr/bin/neutron-rootwrap-daemon
/usr/bin/neutron-db-manage
/usr/bin/neutron-linuxbridge-agent
/usr/bin/neutron-l3-agent
/usr/bin/neutron-metadata-agent
/usr/bin/neutron-dhcp-agent
/usr/bin/neutron-metering-agent
/usr/bin/neutron-server
/usr/bin/neutron-macvtap-agent
/usr/bin/neutron-sriov-nic-agent
/usr/bin/neutron-openvswitch-agent
/usr/bin/neutron-ipset-cleanup
/usr/bin/neutron-netns-cleanup
/usr/bin/neutron-sanity-check
/usr/bin/neutron-pd-notify
/usr/bin/neutron-ns-metadata-proxy
/usr/bin/neutron-linuxbridge-cleanup
/usr/bin/neutron-ovs-cleanup
/usr/bin/neutron-rpc-server

In vanilla neutron packages, each service (ex. neutron-openvswitch-agent) delivers own binary.
Please check http://packages.ubuntu.com/trusty/all/neutron-common/filelist

This will lead to package manager conflicts in case you want to override some services with custom implementation (ex. change neutron-openvswitch).

[Roman Vyalov (r0mikiam)]

Reassign to mos-packaging team, because this bug related to the neutron spec file

[Thomas Goirand (thomas-goirand)]

I don't agree that this is a bug in itself. In fact, these should live in the python-neutron package, since this is dependent on the Python implementation (ie: Python 2 vs Python 3). In *no way* moving these binaries to individual services is the way to fix this problem.

There are 2 ways to solve the problem:
- Using update-alternatives
- Using dpkg-divert

I tend to believe that using update-alternatives is the way to go, as it really is alternatives to the same service.

However, in fact, the solution should even be more simple: since the alternative implementation of neutron-openvswitch-agent has its own daemon and startup file, the way to fix it should simply be to rename the /usr/bin binary into something else for another implementation, and fix the init script. This way, we don't need to hack around.

I will open a thread on the mailing list about this, hoping that upstream will go into the correct direction.

Also, I'm available to anyone who would like to fix the issue, as I think it should be addressed in Debian first, then synced to MOS.

[Bartosz Kupidura (zynzel)]

In upstream each binary is delivered by dedicated package:
http://packages.ubuntu.com/trusty/all/neutron-plugin-openvswitch-agent/filelist
http://packages.ubuntu.com/trusty/all/neutron-metadata-agent/filelist
http://packages.ubuntu.com/trusty/all/neutron-l3-agent/filelist

And not by neutron-common.

[Sergey Kolekonov (skolekonov)]

Bartosz, we do not use Ubuntu packages. Instead we re-use work done by Thomas in Debian, and package structure is the same as in Debian - https://packages.debian.org/sid/neutron-common.

[Bug Checker Bot (bug-checker)]

(This check performed automatically)
Please, make sure that bug description contains the following sections filled in with the appropriate data related to the bug you are describing:

actual result

expected result

steps to reproduce

For more detailed information on the contents of each of the listed sections see https://wiki.openstack.org/wiki/Fuel/How_to_contribute#Here_is_how_you_file_a_bug

[Igor Yozhikov (iyozhikov)]

Bartosz, we are using Debian as the source of package specifications since mos7.0 and that is normal practice. Canonical do almost the same but they are modifying packages.
Please let me know how this bug report affects deployment.

[Bartosz Kupidura (zynzel)]

Use case:
We want to deliver plugin for networking-sfc (https://github.com/openstack/networking-sfc)
But nSFC required own neutron-openvswitch-agent.

So currently we have neutron-openvswitch-agent from neutron-common and from python-networking-sfc.

And there is no easy way to uninstall neutron-openvswitch-agent delivered by neutron-common

[Thomas Goirand (thomas-goirand)]

Bartosz,

What should be done is having the networking-sfc package to produce /usr/bin/sfc-neutron-openvswitch-agent, and have the sysv-rc/upstart/systemd startup stuff use that binary instead of /usr/bin/neutron-openvswitch-agent. I wrote the full explanation here:

http://lists.openstack.org/pipermail/openstack-dev/2016-June/097956.html

This way, there would be no reason to deinstall neutron-openvswitch-agent.

If you really don't want to do this way, then the way to do it is to dpkg-divert the file (see the man page for dpkg-divert), but I wouldn't recommend it.

[Thomas Goirand (thomas-goirand)]

FYI: https://bugs.launchpad.net/networking-sfc/+bug/1595211

[Bartosz Kupidura (zynzel)]

I already created issue in networking-sfc https://bugs.launchpad.net/networking-sfc/+bug/1593693

I ask to mark #1595211 as duplicate of #1593693

FYI:
For now we will use dpkg-divert, when community will choose other approach to deliver "same" daemons, we will fix plugin.

[Thomas Goirand (thomas-goirand)]

You really don't need dpkg-divert. In neutron-fwaas in Newton I renamed /usr/bin/neuton-l3-agent as neutron-fwaas-l3-agent and fixed the startup script accordingly and it worked perfectly. Please use that approach.

[Vitaly Sedelnik (vsedelnik)]

Invalid per comment #6