[PKG-Openstack-devel] Bug#842496: 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')

Fri Nov 4 19:29:56 UTC 2016

On 11/04/2016 12:28 PM, Turbo Fredriksson wrote:
> Even though this is Unstable, that package (or rather the issues with upgrades) will
> eventually end up in Stable.
> 
> So if a minor upgrade(s) between versions don’t work in Unstable, imagine the
> problem that will come when Stable becomes a new/other Stable!

Upstream does *not* support "jumping" version. The reason is because
alembic migration code also imports code from the release. So until we
have Bikesheds in Debian, upgrade from old-stable to stable is simply
impossible.

> I’ve had _SERIOUS_ problem with upstream documentation in the past, and I probably
> alienated myself from most of the community because of it. But, and I’ve said that
> before, “blaming upstream” is not how we should do it..

I haven't said we should blame upstream, but that docs should be written
there first. But I'm not 100% sure that's the place, and probably the
Debian package is the right place to talk about package upgrade.

> But in this specific case, what _REALLY_ pisses me of is that “no-one” (and feel free
> to blame this on upstream - I do :) seems to give a F on this change being done
> between minor versions! It should ONLY have been allowed into a major version!!

This really is the case that it happened between major versions. If it
happened between b1, b2, b3, rc1 and final, that's during the dev cycle
of Newton, so that's what I'd say match a major version.

Never the less, you're right. :)

> I’m going to take some (a lot actually I guess) of the “blame” here. My upgrade
> was unintentional. I’m not going to blame you for pushing a new version of
> OS (Newton) to Sid when I was pretty happy running Mitaka. You did your
> job, Sid is exactly the place for this. Although.. It might have been better to
> push it to Experimental and let it roost there for a few months, then mention
> the upcoming upgrade of Sid on the list and “elsewhere” well in advance..

The normal workflow is to push all to Experimental until the day of the
release, where all of it is pushed to Sid. So far, I always have been
able to run tempest successfully on the RC versions before the releases,
which makes me confident enough that the new release is working. The
release dates for OpenStack are documented here:

https://releases.openstack.org/

> But to learn something from this, push it to Experimental first, then mention
> it on the list, THEN push it to Sid.. ??

You're now aware of the workflow, so I guess it wont be a surprise for
you next time. Though next time, we'll have Stretch frozen, so I'm not
sure if I'll be able to upload Ocata to Sid though...

> Or maybe you did, and I didn’t bother paying attention :).

I just make the assumption that users know already because they've been
following what happened before. Maybe the process should be documented
somewhere in https://wiki.debian.org/OpenStack/

> And I fully realise (and accept) that your time is no less valued than mine and
> we all have many things on our plate and there’s to few hours in the day :(.

OpenStack in Debian is currently maintained mostly by me only, with
Ondrej doing Swift, and Canonical only helping for Python modules (ie:
not on the services). Considering the amount of work that there's to do
on each release, if we want improvements on the documentation side of
the packages, it is my view that we need more contributors.

>> "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... :)
> 
> This is exactly what I mean!! Even _IF_ I had read that before hand, I would
> be absolutely clueless to what to do!! That is a very valid excuse and reason
> for doing the change, there’s no question there! However, there is absolutely
> NO information on what to actually DO!

I've been thinking about the issue, and I now think part of the fix
should be this:

https://review.openstack.org/393917

(ie: the now transitional package neutron-fwaas-l3-agent runtime depends
on neutron-l3-agent)

I first need to fix the build CI though, so if it currently fails to
build in OpenStack infra, that's because we need to finish fixing the
issues related to the latest sbuild upload in jessie-backports.

It would still need manual neutron.conf tweaks though.

> Yeah, I "wish I had the time” :D. But even if I did, I don’t have neither the
> experience nor the knowledge to help :(. All I can do is let you know of my
> experiences when I’m “kicked in the jewels” as it where :).

Your bug reports are gold to me. Please also feel free to ping me on IRC
(I'm zigo on both #debian-openstack on OFTC and #openstack-pkg on freenode).

> Nothing other than purging and reinstalling the package. But I’ve had problem
> with the other Horizon packages in the past, so I’m going to purge ALL of
> them and then install them one by one and see what happens. I’ll try to do
> that this weekend, because Horizon is at the very core of my use-case (that
> and Neutron and Nova of course :D).

I know that the last month upload of libjs-jquery 3.x broke Horizon too.
I'm planning on re-embedding JQuery into python-xstatic-jquery as a
workaround. I here blame the libjs-jquery maintainer for uploading that
late in the Stretch dev cycle, and I don't see how I could do in another
way but to duplicate jquery.js. Thoughts welcome. In the mean time
(before I can update python-xstatic-jquery), snapshot.debian.org is your
friend to get an older version of jquery.

Cheers,

Thomas Goirand (zigo)