[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')

[Turbo Fredriksson]

On 3 Nov 2016, at 17:23, Thomas Goirand <zigo at debian.org> wrote:

> My priority was to have everything ready on time *AND TESTED* on my CI

I know this is “Unstable” and “shit happens”. I can live with that (I’d prefer NOT
to, but I rather have a reasonably late version of OS so I had made the compromise
to run Sid).

BUT, I’d also _want_ to have that in as good state as possible. I honestly don’t
know how to solve this. On one hand, I want the packages you’re providing and
the later/-est versions, but on the other hand I don’t want my system “F’ed up”
either so.. Tough choice :).


So I think slowing done a little and test each version better (and I don’t only mean
automated testing of the code, but rather the ‘user interaction’ - as in upgrades etc)
would be prudent.

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!

> That, I've done it. This isn't the issue you're talking about. Here the
> issue is documenting the process of upgrading.

Documenting the procedure is more important, yes. More important than making it
work automatically. But automatic upgrades isn’t a “non-issue”! It still needs to be
“on the table”, even if it takes a back seat..

> I really believe this should be addressed upstream within docs.openstack.org.

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..

And that includes the upgrade procedure. They don’t seem to give a hoot about that.
I’ve seen a lot of the so called “upgrade notes”! I’d like to consider myself _extremly
experienced_ in all things Linux and computers, but I had an huge problem understanding
them! They weren’t written for the user, they where written for themselves so that they
could remember what they did.

And I’m a coder as well, and I know, from personal experience, that notes I write
for me (or for other coders) is .. “short and to the point” :).


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!!

But I’ve had my whole system trashed, and this was the biggest problem I have
(to date - it’s still not up and running, so there might be others lurking around once
I’ve had time to fix this one). So I’m “not a happy camper” right now :(.

> This has been already well documented in upstream release notes here:
> http://docs.openstack.org/releasenotes/neutron-fwaas/newton.html

I’ll have a closer look at that later, thanx!

As I said above, I’ve had a look at other such documents before, and I had
problems understanding them.

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..

But as I said, I’m not going to hold any grudges over that, it’s done and all-in-all,
you did what I in reality think was the correct choice - push Newton to Sid over
Mitaka..


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

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


So my upgrade was unintentional, and if I had been forewarned, would I have
done anything differently? Well, I wouldn’t have upgraded a major version on
this system - I’ve been warned (time and time again!!) by friends and others
that upgrading OS is an absolute ___HORRIBLE___ experience!!

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 :(.

I _at all possible_ (as in “at least try”), don’t blame upstream. Take matters in
your own hands and solve the upgrade procedure for your users. If they can’t
be bothered, then lets make Debian GNU/Linux the choice for people that want
to use OS _AND_ have it upgradable using the same standards that all other
packages in Debian GNU/Linux?

> "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!

So that information would have been totally useless to me :(.

> 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.

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 :).

> http://docs.openstack.org/project-install-guide/newton/

That doesn’t really help me :D :D.

But it’s better than nothing I guess. A “How to upgrade OS from Mitaka to Newton”
would be good to :).

Luckily, it don’t seem to be that horribly extensive. So far I’ve only had a few
problems. The FWaaS the biggest and worst, but not the only one.

Because I started a new job this month and are going to be quite bussy with
that over the next five, six months (I’m designing, building and testing a
completely new infrastructure - a _complete_ infrastructure with testing,
QA, Live etc, etc - in the Cloud [AWS]), my own cloud have had to take a
backseat on this :(.

So I only have a few hours on the weekends - and not even EVERY weekend -
to work on this :(.

I’m already loosing track on what I’ve done so far :( :(.

> I very much agree. Though really, that's where contributions (even small
> like this) would be very useful.

Unfortunately, that’s all I can do at this moment :(.

> ...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’ll do my best to help out there as much as I can. I’m going to read through
the links you’ve given me and I’ll try your suggestions and see where it
leads me.

> 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?

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).