[PKG-Openstack-devel] Bug#842496: Bug#842496: Bug#842496: closed by Thomas Goirand <zigo at debian.org> (Re: neutron-fwaas-common: Missing /usr/bin/neutron-fwaas-l3-agent 'binary')
Thomas Goirand
zigo at debian.org
Thu Nov 3 17:23:45 UTC 2016
On 11/03/2016 02:01 PM, Turbo Fredriksson wrote:
> On 3 Nov 2016, at 09:03, Thomas Goirand <zigo at debian.org> wrote:
>
>> I very much agree with the above, the only issue is enough time to put
>> these warning in place. Maybe some text in a NEWS or README.Debian file
>> could do the trick. I'm not so fan of adding debconf text for such a
>> warning.
>
> You need to TAKE the time!
Someone once told me it's never a question if someone has time, but
always about priority. So let me put it this way. My priority was to
have everything ready on time *AND TESTED* on my CI, which I was able to
do. Unfortunately, having a good package user documentation has a lower
priority than the quality of the packages (ie: testing that they
actually do work...).
> You can’t upload a package without testing (as in, does it work ‘from
> scratch’ _AND_ (!!) does the upgrade from _at least_ the previous version work without any problem)
That, I've done it. This isn't the issue you're talking about. Here the
issue is documenting the process of upgrading. I really believe this
should be addressed upstream within docs.openstack.org.
> it properly and when you notice (or know!) of something that will affect users, then documenting that
> properly (in a place where they’ll actually LOOK! :) needs to be done.
Yup. :)
> In a case like this, where the effect was MAJOR (basically, the whole network stopped working
> because there was no L3 agent!), a debconf warning MUST be issued!!
This has been already well documented in upstream release notes here:
http://docs.openstack.org/releasenotes/neutron-fwaas/newton.html
A debconf prompt (or something else like a README.Debian, which I would
prefer because some people run in non-interactive mode) could point to
that. However I don't really think the upstream doc are good enough, as
they don't explain what the consequences are for package users.
>From this page:
"Earlier the FWaaS agent integrated with the L3 agent by having the L3
Agent class inherit from the FWaaS Agent class. This meant that other
service agents could not also integrate with the L3 agent. Now, using
the L3 agent extensions mechanism, FWaaS (v1 and v2) plugs in to the L3
agent. This means that it can interoperate peacefully with other L3
advanced services that also implement the L3 agent extension mechanism,
all without any code changes to Neutron."
OpenStack users should read these before upgrading. But like for Debian,
users don't read the release notes... :)
In theory, you are right, I should take the time. But really, some
contribution could help here, as I'm probably too much focus on the
packages themselves. This thing, I just forgot about it, and didn't even
think I should have documented the issue. Thanks your comments.
However, you may have noticed that I did take the time to actually test
and document the install procedure, and contribute to that upstream. The
Debian install-guide is now available upstream here:
http://docs.openstack.org/project-install-guide/newton/
I have contributed and tested both the debconf and the non-interactive
install-guide. My hope is that this will be useful for most Debian
users. I'd really enjoy reading comments about it.
> Just imagine that people are actually using this in production and that their livelihood depends on this
> working 24/7/365 and ANY disruption (other than the ‘normal’ restart of a service) can have dyer consequences.
I very much agree. Though really, that's where contributions (even small
like this) would be very useful.
> Or in another way: What would YOU think/do if someone just shot your whole system to pieces??!
That someone isn't me, but upstream, trying to address a very legitimate
concern. Though...
...again, I very much agree with you that this could be perfected, and I
very much welcome contributions to go in the direction you're suggesting
(ie: documenting the upgrade path). I'm however a lot more worried about
your issue with Horizon, and I believe it should have a higher priority.
Did you have time to investigate it more?
Cheers,
Thomas Goirand (zigo)
More information about the Openstack-devel
mailing list