[13:50] <jamespage> markus_z, switching to cpu-mode = 'none' fixed things sufficiently to get a cloud up and running
[13:50] <jamespage> albeit in all on lpar using containers, but a useful validation point all the same
[13:51] <markus_z> jamespage: cool! Good to hear that. Thanks for the info.
[13:51] <markus_z> jamespage: Did I already mention that VNC is not working and you need the "serial console" if you want to access it in Horizon?
[13:51] <markus_z> "it" == an instance
[13:51] <jamespage> markus_z, ah - no I did not know that
[13:51] <jamespage> tbh I generally avoid horizon
[13:52] <jamespage> but thanks for the feedback anyway
[13:52] <markus_z> jamespage: good choice :)
[13:52] <jamespage> serial console is not configured by the charms atm - I'll add that to the features list for next cycle...
[13:53] <markus_z> jamespage: The serial console still has limitations though. Live-migration is not possible with it. I'm working on a bug fix for that.
[13:54] <markus_z> https://bugs.launchpad.net/nova/+bug/1455252
[14:54] <xnox> markus_z, hm, surely we can connect to the virtio console and have migrations working et.al.? (same as on other arches)
[14:54]  * xnox looks into the bug report
[15:01] <markus_z> xnox: It's not related to the arch. It behaves the same on x86. The way nova handles the ports during the live-migration is the root cause.
[15:01] <xnox> ah, ok =)
[15:02] <xnox> markus_z, i meant VNC -> i thought that should work without serial console, and simply with the /dev/hvc0 console no?
[15:02] <xnox> hvc0-7 consoles
[15:04] <markus_z> xnox: That' news to me. Isn't hvc0 xen related?
[15:11] <xnox> markus_z, it might be qemu 2.5 new stuff. And yes hvc0 is usually xen stuff. I'll boot another instance on my machines in a moment to inspect available things.
[15:11]  * xnox ponders if there is Xen on s390x
[15:11] <smb> xnox, no
[15:12] <xnox> either something is recycling the names, or possibly ubuntu config has xen stuff enabled =/
[15:12] <xnox> (kernel config)
[15:12] <smb> I think hvc is Xen but not only, there was something else using that name (thoug I thought ppc)
[15:18] <markus_z> I have to leave for today, we can talk tomorrow about this if you like.
[15:36] <xnox> cpaelzer, infinity, smb - could you take a look at the last patch I've posted on https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1563854 ?
[15:36] <xnox> it seems reasonable to me, but I'm not sure if it will re-introduce the stalls you have worked on removing in previous uploads.
[15:36] <xnox> i'm gonna run in that config for a bit, and see if it's reasonable.
[15:38] <smb> xnox, I can try this as a manual fix, too. It looks reasonable and I guess the stalls were mainly because the cache was updated on every login. Now it would be only when running update or upgrade
[15:39] <smb> which I think is already protected somehow against concurrent runs
[15:40] <cpaelzer> xnox: looking
[15:43] <cpaelzer> xnox: yeah that update was lost, and currently has the delay til next update
[15:44] <xnox> cpaelzer, so currently story: apt update, ssh localhost "you have X updates", apt full-upgrade, ssh localhost "you have X updates", apt update, "<no updates message>"
[15:44] <cpaelzer> xnox: I agree on "recounting" after DPkg ran to be a proper solution
[15:44] <xnox> cool.
[15:44] <cpaelzer> I haven't tested
[15:44] <xnox> with this thing after dist-upgrade (even if partial) the right new count is displayed.
[15:44] <cpaelzer> do you want us to test it too, any ppa or anything?
[15:44] <xnox> i'll test it more with partial / aborted upgrades later on, before uploading.
[15:44] <cpaelzer> or just test itonce upload is through?
[15:45] <xnox> cpaelzer, it's a conf file, just edit it in /etc/apt.conf.d =)
[15:45] <cpaelzer> xnox: so true
[15:45] <xnox> to match the new stanza.
[15:45] <cpaelzer> xnox: let me get my numa "§$%& out of the way and I'll test it later one
[15:45] <xnox> =)
[16:18]  * xnox wishes dasdfmt was faster
[19:17] <cpaelzer> xnox: your fixe worked for me in general and in the few tests I've made
[19:18] <cpaelzer> xnox: it achieves what you wanted and it didn't break anything for me that I would have noticed
[19:19] <xnox> cpaelzer, cool. I was after that!
[19:20] <cpaelzer> and the extra latency is only added to another apt/dpkg action which is where it should belong to
[19:20] <cpaelzer> as you remember it was "on login" in the past which was horrible waiting these seconds over and over again :-)
[19:22] <xnox> yeap