| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| markus_z | https://bugs.launchpad.net/nova/+bug/1455252 | 13:54 |
| ubottu | Launchpad bug 1455252 in OpenStack Compute (nova) "enabling serial console breaks live migration" [High,In progress] | 13: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 | 14:54 | |
| 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:01 |
| 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:02 |
| markus_z | xnox: That' news to me. Isn't hvc0 xen related? | 15:04 |
| 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:11 |
| 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:12 |
| markus_z | I have to leave for today, we can talk tomorrow about this if you like. | 15:18 |
| 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 |
| ubottu | Launchpad bug 1563854 in update-notifier (Ubuntu) "update-notifier updates-available does not reset after dpkg run" [High,Fix released] | 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:36 |
| 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:38 |
| smb | which I think is already protected somehow against concurrent runs | 15:39 |
| cpaelzer | xnox: looking | 15:40 |
| cpaelzer | xnox: yeah that update was lost, and currently has the delay til next update | 15:43 |
| 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:44 |
| 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 | =) | 15:45 |
| * xnox wishes dasdfmt was faster | 16:18 | |
| cpaelzer | xnox: your fixe worked for me in general and in the few tests I've made | 19:17 |
| cpaelzer | xnox: it achieves what you wanted and it didn't break anything for me that I would have noticed | 19:18 |
| xnox | cpaelzer, cool. I was after that! | 19:19 |
| 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:20 |
| xnox | yeap | 19:22 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!