Bug#685251: Fixing Debian bug #685251 for the ryu plugin in Openstack
Hi Julien (or anyone else in the release team)
Would it be possible for you to review the following proposed patch?
It solves the bug and it would be good to have that resolved for the
release.
It is a minimal fix for the problem.
Thanks in advance,
// Ola
On Tue, Nov 13, 2012 at 12:08:03PM +0100, Julien Cristau wrote:
On Fri, Nov 9, 2012 at 05:03:58 +0800, Thomas Goirand wrote:
Please let me know if the attached patch would be accepted by the
release team and avoid Quantum to be removed.
Sigh. If you want to be sure it'll be accepted then just upload the
minimal fix for the RC bug and leave it at that (2012.1-6 doesn't seem
to list a bug number, so without more explanations it doesn't qualify).
I'm not going to review every single one of your uploads 5 times.
Cheers,
Julien
--
--- Inguza Technology AB --- MSc in Information Technology
/ o...@inguza.comAnnebergsslingan 37\
| o...@debian.org 654 65 KARLSTAD|
| http://inguza.com/Mobile: +46 (0)70-332 1551 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---
diff -uNr quantum-2012.1-olaorig/debian/changelog quantum-2012.1/debian/changelog
--- quantum-2012.1-olaorig/debian/changelog 2012-06-12 18:15:41.0 +
+++ quantum-2012.1/debian/changelog 2012-12-29 08:50:07.943438606 +
@@ -1,3 +1,12 @@
+quantum (2012.1-5wheezy1) testing-proposed-updates; urgency=high
+
+ * Non-maintainer upload.
+ * Backport of the removal of ryu app from 2012.1-7. Closes: #685251.
+This needs to go directly to testing as the changes in 2012.1-6 is
+too excessive.
+
+ -- Ola Lundqvist o...@debian.org Sat, 29 Dec 2012 08:38:07 +
+
quantum (2012.1-5) unstable; urgency=low
* Really fix upgrade from version lt 2012.1-2. Closes: #672170
diff -uNr quantum-2012.1-olaorig/debian/control quantum-2012.1/debian/control
--- quantum-2012.1-olaorig/debian/control 2012-06-12 18:15:41.0 +
+++ quantum-2012.1/debian/control 2012-12-29 08:49:14.371441333 +
@@ -150,35 +150,6 @@
node
-Package: quantum-plugin-ryu
-Architecture: all
-Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}, quantum-common,
- python-quantum
-Provides: quantum-plugin
-Conflicts: quantum-plugin
-Replaces: python-quantum ( 2012.1-3)
-Breaks: python-quantum ( 2012.1-3)
-Description: OpenStack Virtual network service - ryu plugin
- Quantum provides an API to dynamically request and configure virtual networks.
- These networks connect interfaces from other OpenStack services (e.g., vNICs
- from Nova VMs). The Quantum API supports extensions to provide advanced network
- capabilities (e.g., QoS, ACLs, network monitoring, etc).
- .
- This package provides a plugin to use with Ryu Network Operating Ssytem
-
-Package: quantum-plugin-ryu-agent
-Architecture: all
-Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends},
- python-quantum
-Description: OpenStack Virtual network service - ryu agent
- Quantum provides an API to dynamically request and configure virtual networks.
- These networks connect interfaces from other OpenStack services (e.g., vNICs
- from Nova VMs). The Quantum API supports extensions to provide advanced network
- capabilities (e.g., QoS, ACLs, network monitoring, etc).
- .
- This package provides the ryu-agent which should run on each compute
- node
-
Package: python-quantum
Architecture: all
Section: python
diff -uNr quantum-2012.1-olaorig/debian/quantum-plugin-ryu-agent.init quantum-2012.1/debian/quantum-plugin-ryu-agent.init
--- quantum-2012.1-olaorig/debian/quantum-plugin-ryu-agent.init 2012-06-12 18:15:41.0 +
+++ quantum-2012.1/debian/quantum-plugin-ryu-agent.init 1970-01-01 00:00:00.0 +
@@ -1,92 +0,0 @@
-#!/bin/sh
-### BEGIN INIT INFO
-# Provides: quantum-plugin-ryu-agent
-# Required-Start:$network $local_fs $remote_fs $syslog
-# Required-Stop: $remote_fs
-# Default-Start: 2 3 4 5
-# Default-Stop: 0 1 6
-# Short-Description: Quantum LinuxBridge Agent
-# Description: Agent to use within quantum ryu client
-### END INIT INFO
-
-# Author: Ghe Rivero ghe.riv...@stackops.com
-
-# PATH should only include /usr/* if it runs after the mountnfs.sh script
-PATH=/sbin:/usr/sbin:/bin:/usr/bin
-DESC=Openstack Quantum LinuxBridge Plugin Agent
-NAME=quantum-ryu-agent
-DAEMON=/usr/bin/quantum-ryu-agent
-PIDFILE=/var/run/$NAME.pid
-SCRIPTNAME=/etc/init.d/$NAME
-CONF_FILE=/etc/quantum/plugins/ryu/ryu_conf.ini
-
-# Exit if the package is not installed
-[ -x $DAEMON ] || exit 0
-
-# Read configuration variable file if it is present
-[ -r /etc/default/$NAME ] . /etc/default/$NAME
-
-. /lib/lsb/init-functions
-
-do_start()
-{
- start-stop-daemon --start --background --quiet --chuid root:root --make-pidfile --pidfile $PIDFILE --startas $DAEMON --test /dev/null \
- || return 1
- start-stop-daemon --start
Bug#685251: [Openstack-devel] Bug#685251: Fixing Debian bug #685251 for the ryu plugin in Openstack
On 12/29/2012 09:22 PM, Ola Lundqvist wrote: * I don't think there's the need to use testing-proposed-updates. Uploading to SID will be just fine, as anyway, we haven't uploaded anything newer in SID which would pose a problem, and that we use Experimental for Folsom. (in other words: nothing prevents uploading to SID, and when we upload there it's in the hope it migrates to testing) No that won't work because the changes in -6 should remain. We will *not* maintain -6 in SID. It will go away and will be replaced by the Folsom packaging as soon as Wheezy is released. So why would you keep it in SID? And no I do not want to first upload a -7 version and than a new -8 with the changes in -6 because then I have to have a very complicated replaces rules in the control file which we really should avoid. Ah, that makes sense!!! :) But I don't think this cuts it. The changes will be necessary in Folsom anyway, because we should provide an upgrade path in SID. So we're doomed to the replaces+breaks it here. Note that we already have a Replaces: in the alioth for the Folsom release Quantum which I plan to upload soon. Should I add a Breaks: too? (I think so) Same answer as above. I have followed the instructions in http://www.debian.org/doc/manuals/developers-reference/pkgs.html chapter 5.13.3. Version numbers are usually selected by adding the codename of the testing distribution and a running number, like 1.2squeeze1 for the first upload through testing-proposed-updates of package version 1.2. This is just as valid for testing uploads as for stable uploads. Yeah, I wasn't debating this, I was questioning the relevance of using t-p-u instead of SID. * Our Git already contains entries for -6 and -7. Please use that, modifying the candidate version -7, and do not get out of sync with our Git please, otherwise it's going to be a nightmare! The -7 version is what I have used to backport from. I have taken your changes and re-done them for testing only. Then you should create a debian/wheezy branch in the Git! I was planning on doing that just right after the release of wheezy for all of our packages, but it will be needed now for Quantum if you want the package to have a Wheezy and a SID branch now. As much as I can see, Alioth doesn't have a debian/wheezy branch, does it? Also, this issue has been pending for 6 months! I do appreciate that you finally decide to work on it, even that late. But I continue to refuse to take the responsibility for it. The main mistake, IMO, was to leave the issue as-is, doing nothing to fix it. So you and Loic should really take the responsibility for the upload, and make sure it's in a correct shape *in time* for the release. I surely would feel bad if Quantum had to be removed from Wheezy. Please don't leave this pending again. I do not want to start a flamewar It wasn't my intention. I just wanted to highlight that this needs to be fixed soon. I do hope you don't take it personally. First of all it is 3.5 months (not 6) My count started on the 2012-07-06, when Quantum -6 was uploaded by Loic in SID. After such an upload, action should have been taken to have the package unblock (or that upload should have been made in experimental). secondly I have asked about your opintion on this matter without response and that explains more than 2 months. Well, the problem is that I might agree with the changes, *BUT*, I'm not a member of the release team, and therefore, I don't have any decision power. Also, I didn't really understand what was done at the time, and I probably still don't get why everything all of the code isn't stored in the python-* package. The only reason why I've been asking you, was to provide information to the release team for an unblock. But now I see that discussing it with me didn't help. :( I'm sorry that it seems you've been waiting on me. (As a rule, if I don't answer within 5 days, consider that either I don't know what to answer, or that your mail is stuck on my huge mail queue and that I had no time to answer. In which case, either send me another mail, or try to deal without my answer.) Again, I'm not trying to put the blame on you, just trying to push you to solve the current problem. Thanks again for working on it. Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685251: Fixing Debian bug #685251 for the ryu plugin in Openstack
On Fri, Nov 9, 2012 at 05:03:58 +0800, Thomas Goirand wrote: Please let me know if the attached patch would be accepted by the release team and avoid Quantum to be removed. Sigh. If you want to be sure it'll be accepted then just upload the minimal fix for the RC bug and leave it at that (2012.1-6 doesn't seem to list a bug number, so without more explanations it doesn't qualify). I'm not going to review every single one of your uploads 5 times. Cheers, Julien signature.asc Description: Digital signature
Bug#685251: Fixing Debian bug #685251 for the ryu plugin in Openstack
On 11/13/2012 07:08 PM, Julien Cristau wrote: On Fri, Nov 9, 2012 at 05:03:58 +0800, Thomas Goirand wrote: Please let me know if the attached patch would be accepted by the release team and avoid Quantum to be removed. Sigh. If you want to be sure it'll be accepted then just upload the minimal fix for the RC bug and leave it at that (2012.1-6 doesn't seem to list a bug number, so without more explanations it doesn't qualify). As I wrote, these changes were not mine. I don't think it's appropriate to write sigh or to be pissed *at me*. The only thing I did was working on the issue the release team cared about, and fixing it, I'm not responsible for the other changes, and I don't intend to assume responsibility for them regarding the unblock. It wasn't nice that these changes were uploaded without caring about the SID to Wheezy migration. Numerous times, I wrote about it to both Ola and Loic. I'm not surprised about the resulting conversation with the release team. But since that's not my work, and that I would like to respect what the others do, I still want to leave them the job to answer about it. So please, Ola and Loic, explain and deal with the release team. If you guys think the changes are necessary, tell why. If you think they should be removed, please do the necessary git revert (or at the very least, let me know that you would agree if I was to do it). And finally, I hope this is a lesson and that it wont happen again, and that you will bare with me and the rest of the PKG Openstack team. I'm not going to review every single one of your uploads 5 times. You don't have to, you can accept it the first time! :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685251: Fixing Debian bug #685251 for the ryu plugin in Openstack
Hi Thomas and Julien The 2012.1-6 upload was done before the freeze and the plan was to have it included in testing before the freeze. Apparently that did not happen. I was under the impression that the freeze would be to uploads after the freeze, not to the packages that had not yet done the transition. Apparently I was wrong, and if that have cause this problem, I'm sorry for that. We did not have any bug report about the issues for that change. Instead I did those changes in order to solve problems that were similar to issues in other packages. It was more of a cleanup work in order to avoid bug reports in the future. We did have issues with the conflicts, replaces, breaks in other packages and if I remember correctly they were important also for this package. It is some time since I did this so I do not remember all the details. I think the 2012.1-6 upload was a good thing for the package, especially for upgrade from earlier versions. That is however not such a big problem for this release as it has not been part of stable before. It may be an issue for later releases though. From a release team perspective I understand that you do not want large last minute changes to packages. I can not motivate the change to be that strong to be forced in. If you want I can make a proposed patch based on the changes Thomas made for 2012.1-7 and void the changes for 2012.1-6. I do however think the changes done in 2012.1-6 was good and we should have them in for next release (after the one that is frozen now). This means that I do not think we should revert them for next release, but I do not have a big problem to do it for testing. I hope this clarifies the situation a bit. Cheers, // Ola tis 2012-11-13 klockan 20:16 +0800 skrev Thomas Goirand: On 11/13/2012 07:08 PM, Julien Cristau wrote: On Fri, Nov 9, 2012 at 05:03:58 +0800, Thomas Goirand wrote: Please let me know if the attached patch would be accepted by the release team and avoid Quantum to be removed. Sigh. If you want to be sure it'll be accepted then just upload the minimal fix for the RC bug and leave it at that (2012.1-6 doesn't seem to list a bug number, so without more explanations it doesn't qualify). As I wrote, these changes were not mine. I don't think it's appropriate to write sigh or to be pissed *at me*. The only thing I did was working on the issue the release team cared about, and fixing it, I'm not responsible for the other changes, and I don't intend to assume responsibility for them regarding the unblock. It wasn't nice that these changes were uploaded without caring about the SID to Wheezy migration. Numerous times, I wrote about it to both Ola and Loic. I'm not surprised about the resulting conversation with the release team. But since that's not my work, and that I would like to respect what the others do, I still want to leave them the job to answer about it. So please, Ola and Loic, explain and deal with the release team. If you guys think the changes are necessary, tell why. If you think they should be removed, please do the necessary git revert (or at the very least, let me know that you would agree if I was to do it). And finally, I hope this is a lesson and that it wont happen again, and that you will bare with me and the rest of the PKG Openstack team. I'm not going to review every single one of your uploads 5 times. You don't have to, you can accept it the first time! :) Thomas -- --- Inguza Technology AB --- MSc in Information Technology / o...@inguza.comAnnebergsslingan 37\ | o...@debian.org 654 65 KARLSTAD| | http://inguza.com/Mobile: +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685251: Fixing Debian bug #685251 for the ryu plugin in Openstack
On 11/08/2012 02:16 AM, Julien Cristau wrote:
On Thu, Nov 8, 2012 at 01:50:31 +0800, Thomas Goirand wrote:
Now, I have to ask what the release team thinks about this. Should we
keep the ryu pluggin package in Debian, but disable the init script by
default, and explain the situation? Or simply remove all Ryu support?
If a package is not useful in the context of debian main then we should
not ship it.
Cheers,
Julien
Here's the proposed patch which removes the RYU pluggins completely. The
debdiff between 2012.1-5 and proposed 2012.1-7 is attached.
I am the author only of the RYU plugin removal part of the patch. Other
changes shall be discussed with either Loic or Ola, who respectively
uploaded and modified the Quantum package in our Git. If the release
team wishes to revert some of it, let me know, and I'll do my best to
produce a new patch.
Please let me know if the attached patch would be accepted by the
release team and avoid Quantum to be removed.
Cheers,
Thomas
diff -Nru quantum-2012.1/debian/changelog quantum-2012.1/debian/changelog
--- quantum-2012.1/debian/changelog 2012-06-12 18:15:41.0 +
+++ quantum-2012.1/debian/changelog 2012-11-08 21:49:58.0 +
@@ -1,3 +1,26 @@
+quantum (2012.1-7) unstable; urgency=low
+
+ [ Thomas Goirand ]
+ * Removes ryu packages, since the ryu app isn't available in Debian main, and
+ as per discussed with the release team (Closes: #685251).
+
+ [ Loic Dachary ]
+ * Added the gbp.conf file which is otherwise present in other Openstack
+ packages.
+
+ -- Thomas Goirand z...@debian.org Thu, 08 Nov 2012 21:17:11 +
+
+quantum (2012.1-6) unstable; urgency=low
+
+ [ Ola Lundqvist ]
+ * Moved plugin files to the respective plugin package.
+ * The sample plugin is moved to usr/doc.
+ * Updated debian/rules to allow build two times in a row without
+breaking.
+ * Removed useless Provides: / Breaks: / Conflicts: in debian/control.
+
+ -- Loic Dachary (OuoU) l...@debian.org Thu, 28 Jun 2012 08:12:57 +0200
+
quantum (2012.1-5) unstable; urgency=low
* Really fix upgrade from version lt 2012.1-2. Closes: #672170
diff -Nru quantum-2012.1/debian/control quantum-2012.1/debian/control
--- quantum-2012.1/debian/control 2012-06-12 18:15:41.0 +
+++ quantum-2012.1/debian/control 2012-11-08 21:49:58.0 +
@@ -44,10 +44,7 @@
Architecture: all
Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}, quantum-common,
python-quantum
-Provides: quantum-plugin
-Conflicts: quantum-plugin
-Replaces: python-quantum ( 2012.1-3)
-Breaks: python-quantum ( 2012.1-3)
+Replaces: python-quantum ( 2012.1-5.1)
Description: OpenStack Virtual network service - cisco plugin
Quantum provides an API to dynamically request and configure virtual networks.
These networks connect interfaces from other OpenStack services (e.g., vNICs
@@ -60,10 +57,7 @@
Architecture: all
Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends},
quantum-common, openvswitch-switch,
python-quantum
-Provides: quantum-plugin
-Conflicts: quantum-plugin
-Replaces: python-quantum ( 2012.1-3)
-Breaks: python-quantum ( 2012.1-3)
+Replaces: python-quantum ( 2012.1-5.1)
Description: OpenStack Virtual network service - openvswitch plugin
Quantum provides an API to dynamically request and configure virtual networks.
These networks connect interfaces from other OpenStack services (e.g., vNICs
@@ -76,10 +70,7 @@
Architecture: all
Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}, quantum-common,
python-quantum
-Provides: quantum-plugin
-Conflicts: quantum-plugin
-Replaces: python-quantum ( 2012.1-3)
-Breaks: python-quantum ( 2012.1-3)
+Replaces: python-quantum ( 2012.1-5.1)
Description: OpenStack Virtual network service - sample plugin
Quantum provides an API to dynamically request and configure virtual networks.
These networks connect interfaces from other OpenStack services (e.g., vNICs
@@ -92,10 +83,7 @@
Architecture: all
Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}, quantum-common,
python-quantum
-Provides: quantum-plugin
-Conflicts: quantum-plugin
-Replaces: python-quantum ( 2012.1-3)
-Breaks: python-quantum ( 2012.1-3)
+Replaces: python-quantum ( 2012.1-5.1)
Description: OpenStack Virtual network service - nicira NVP plugin
Quantum provides an API to dynamically request and configure virtual networks.
These networks connect interfaces from other OpenStack services (e.g., vNICs
@@ -109,10 +97,7 @@
Depends: ${python:Depends}, ${shlibs:Depends}, ${misc:Depends}, quantum-common,
bridge-utils,
python-quantum
-Provides: quantum-plugin
-Conflicts: quantum-plugin
-Replaces: python-quantum ( 2012.1-3)
-Breaks: python-quantum ( 2012.1-3)
+Replaces: python-quantum ( 2012.1-5.1)
Description: OpenStack Virtual network service - linux bridge plugin
Quantum provides an API to dynamically request and configure virtual networks.
These networks connect interfaces from
Bug#685251: Fixing Debian bug #685251 for the ryu plugin in Openstack
On 11/07/2012 11:27 PM, Isaku Yamahata wrote: Hi Thomas. Thank you for notifying this. The answer is, ryu source is needed which is available from git://github.com/osrg/ryu.git I looked at the bug report, so the issues is that Debian doesn't have Ryu package, right? If possible, I'd like to provide Ryu package to Debian. I think Ryu has already python setup script, so it wouldn't be difficult. thanks, Hi Isaku, Thanks for explaining this! Finally, it makes sense. Indeed, there's no Ryu package in Debian. That's unfortunate, because at this stage, it will *not* be able to make it into Debian Wheezy. Now, I have to ask what the release team thinks about this. Should we keep the ryu pluggin package in Debian, but disable the init script by default, and explain the situation? Or simply remove all Ryu support? Isaku, I'd be very happy to help you to get your Ryu package in Debian (for the moment, it will be only Debian experimental, since Wheezy is frozen). Note that the situation seem to be the same in Ubuntu (and why they didn't package and Depends: on Ryu is astonishing!). Cheers, Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685251: Fixing Debian bug #685251 for the ryu plugin in Openstack
On Thu, Nov 8, 2012 at 01:50:31 +0800, Thomas Goirand wrote: Now, I have to ask what the release team thinks about this. Should we keep the ryu pluggin package in Debian, but disable the init script by default, and explain the situation? Or simply remove all Ryu support? If a package is not useful in the context of debian main then we should not ship it. Cheers, Julien signature.asc Description: Digital signature
Bug#685251: [Openstack-devel] Bug#685251: Fixing Debian bug #685251 for the ryu plugin in Openstack
On 11/08/2012 02:16 AM, Julien Cristau wrote: On Thu, Nov 8, 2012 at 01:50:31 +0800, Thomas Goirand wrote: Now, I have to ask what the release team thinks about this. Should we keep the ryu pluggin package in Debian, but disable the init script by default, and explain the situation? Or simply remove all Ryu support? If a package is not useful in the context of debian main then we should not ship it. Cheers, Julien This will be done. Thomas -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
