On 3 Nov 2016, at 17:23, Thomas Goirand <z...@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).