=== Sooty is now known as Guest69692 === amoralej|off is now known as amoralej === iberezovskiy|off is now known as iberezovskiy [10:26] zul, jamespage, coreycb, ddellav, hi I uncounter a qemu live-migration issue from trusty to xenial https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1641532 [10:26] Launchpad bug 1641532 in qemu (Ubuntu) "Unknown ramblock "/rom@etc/acpi/rsdp", cannot accept migration" [Undecided,New] [10:26] zul, jamespage, coreycb, ddellav, I thnk this should be fixed before openstack user try to upgrade from mitaka to newton [10:27] sileht: known issue, let me find and point you to the right one [10:27] STS working on it arm [10:27] atm [10:27] at least it seems that way [10:28] grr no meeting minutes uploaded last week [10:29] sileht, I was about to point you to cpaelzer but I see he's jumped in [10:29] :) [10:29] thanks cpaelzer [10:32] * cpaelzer is still checking - envision a spinning wheel here - \ | / - ... [10:33] :) [10:34] sileht: not a dup to the one I thought - now context switching into the bug more [10:35] cpaelzer, I have tested the patch I have attached to the bug report on my cluster and it works well [10:36] sileht: yeah I'd even say ack after 2 minutes looking at it - but I'd like to look at it at least a bit more :-) [10:36] sileht: I recently cleaned up a lot of this machine type mess, but due to LTS cycles we could only drop old cruft after LTS [10:36] sileht: and atm I think you are right [10:37] sileht: give me a bit and I'll fully agree :-) [10:37] cpaelzer, sure the patch as-is is enougth or do you want a proper debdiff ? or something else ? [10:37] this is a can of nice worms [10:37] sileht: I'm fine with the patch as-is [10:37] cool [10:37] sileht: I have a testbed for just such migration issues where I'll test it [10:38] sileht: I just never happened to use that old guests as "utopic" [10:38] cpaelzer, :) [10:38] sileht: migrating after Xenial you'd be supposed to update the machine type to go on [10:38] sileht: but for what you reported it is a valid issue [10:39] sileht: so I'm now going on to check and test on this [10:39] cpaelzer, changing machine type means 'rebooting customer vm' [10:39] sileht: I'll let you know [10:39] sileht: yes it does [10:39] cpaelzer, I can't do that [10:40] sileht: at some point old things have to go out of support - that is why we (after long discussion) decided to drop older types after an LTS and only those types that are "out of support" then [10:40] cpaelzer, I have very old VM with just 'pc-i440fx' and it still work fine [10:40] cpaelzer, yeah I understand but 2.0 machine type is still supported upstream [10:41] sileht: I fully understand your case and pain - but at some point it becomes a matter of maintainability [10:41] cpaelzer, the custom ubuntu machine type just break think [10:41] think/thing [10:41] sileht: yeah it is a shame - the early days of qemu machine types forced all dirstibutions to go the "custom machine type way" [10:41] sileht: these days it might mostly be fine [10:41] sileht: but everybody has to obey his history [10:42] sileht: and now time comes and makes things non maintainable :-/ [10:42] sileht: all distributions are in the same mess here - but there is no golden solution (IMHO) [10:42] sileht: on one side you have the valid "the upstream type still works" - but that is only true in most but not all cases [10:43] sileht: and on the other you can't care about the old delta forever as it less and less applies to the new code [10:44] sileht: there was a lot of info (and less "discussion" than I'd liked) around it - let me know if you want some pointers [10:44] sileht: I'll now go for your fix [10:44] * cpaelzer declares machine-types a never ending can of worms [10:44] agreed ! [10:47] and it did not help that the way to define them was changed three times in the last 2 years [11:31] sileht: I think this is all worse than we thought - may I ask what you did to do the check that lead you to "...I have seen that in 2.3, the utopic machine is a kvm-2.3 machine..." ? [11:32] cpaelzer, I have looks at the code of qemu-system-x86 1:2.3+dfsg-5ubuntu9.4~cloud2 [11:32] sileht: ah so just reading [11:32] sileht: I thought you'd have a live check better than mine [11:33] cpaelzer, the code in the define-ubuntu-machine-types.patch [11:33] sileht: sure IMHO it is more broken than that [11:33] sileht: it inherits whatever the latest version is [11:33] cpaelzer, it uses pc_init_pci [11:33] cpaelzer, and at this times that was 2.3 marchine [11:34] sileht: so while your utopic type on a 2.3 host had 2.3 it would have had 2.1 in a real utopic for example [11:34] cpaelzer, I just hope ubuntu never release a 2.4 with 'pc_init_pci' :p [11:35] cpaelzer, oh I see [11:35] sileht: so that is super worse than I thought at first :-/ [11:35] sileht: I could fix it to what it should have been, but that would not help you (=2.1) [11:35] sileht: in fact I'd have to choose on "when did the last geust restart happen" [11:36] where it picked up the latest type [11:36] cpaelzer, utopic was shipped qemu 2.1 ? [11:37] yes [11:37] cpaelzer, trusty was 2.1 and cloud-archive have backport the utopic 2.3 to trusty, no ? [11:37] https://launchpad.net/ubuntu/+source/qemu/+publishinghistory?batch=75&memo=75&start=75 [11:38] sileht: trusty 2.0, utopic 2.1, vivid 2.2, wily 2.3, xenial 2.5, yakkety 2.6 [11:38] sileht: depends on which cloud archive you have [11:39] cpaelzer, so this a bug of the cloud archive backport [11:39] I don't really think so - is it? [11:39] it is a bug that was there a long time but now bites us in the worst possible way (for fixing one has to choose who to break) [11:40] cpaelzer, yes this is what I would say [11:42] cpaelzer, I would said the 'main' qemu should stick 2.1 and the cloud-archive one should use "2.3" [11:42] cpaelzer, that should limit the breakage ? [11:44] only for one "sort of UCA" - you have qemu 2.3 because you have the liberty UCA I assume [11:44] cpaelzer, exaclty [11:44] but what about one that comes from U/J/K ? [11:44] they will have the other versions [11:45] cpaelzer, I was using debian before and the machine for those VM is 'pc-i440fx' [11:45] cpaelzer, and I have no pb with them [11:45] I wish the past wouldn't have forced us onto the specific type route [11:45] but none of us can change that [11:46] sileht: hmm, the pc-i440fx is also only a pointer to latest [11:47] cpaelzer, let's me check what I really have currently running [11:49] cpaelzer, I have this currently on my cluster: [11:49] pc-i440fx-2.1,accel=kvm,usb=off [11:49] pc-i440fx-utopic,accel=kvm,usb=off [11:49] pc-i440fx-vivid,accel=kvm,usb=off [11:49] I'm guessing the debian VMs are 'pc-i440fx-2.1 [11:51] with number: [11:51] 2 pc-i440fx-2.1,accel=kvm,usb=off [11:51] 90 pc-i440fx-utopic,accel=kvm,usb=off [11:51] 50 pc-i440fx-vivid,accel=kvm,usb=off [11:53] cpaelzer, kilo UCA have the utopic machine patch and it's 2.2 :( [11:54] this is an awful bug [12:00] sileht: I can only agree [12:00] sileht: I'll dump the state into the bug, but that needs more people involved given the potential magnitude [12:04] I wonder thou that this only affects special cases - as I can just nicely migrate trusty to xenial [12:04] which is 2.0 to 2.5 [12:04] and while xenial currently mis-assumes that to be a 2.5 type it is just fine [12:04] so on a migration it seems to be important what both pairs think [12:05] umm "the pair" [12:05] trusty thinks it has a 2.0 guest (correct) and Xenial (while misinterpreting the type as 2.5 when starting new) can receive it correctly [12:06] yet it fails for you from 2.3 -> 2.5 [12:06] some of the special quirks qmeu/libvirt do only apply to certain combinations - and this might be one [12:06] sileht: as guest type? [12:07] sorry [12:07] bad reference - ignore it [12:10] cpaelzer, if you apply my fix but puting 2.0 instead of 2.3 you will fix the 'main' repo [12:10] cpaelzer, but UCA users will still be broken [12:10] sileht: yes this is how far I am in my thoughts [12:10] sileht: but I'm spinning around why you are broken and a base T->X migration is not [12:12] cpaelzer, because UCA have backported qemu without updating define-ubuntu-machine-types.patch correctly [12:13] sileht: almost - because utopic machine type update was done wrong, never fixed till now and all those releases in between got picked up by UCA [12:13] yeah :( [12:32] sileht: do you need more than x86 for your tests if I prep a ppa? [12:33] cpaelzer, no I only have amd64 server [12:41] jamespage: FYI - you might want to reread bug 1641532 content and triage accordingly for UCA now [12:41] bug 1641532 in qemu (Ubuntu) "machine-types trusty and utopic are not unique (depend on the qemu version)" [Critical,Confirmed] https://launchpad.net/bugs/1641532 === amoralej is now known as amoralej|lunch [12:53] cpaelzer, ack [13:16] cpaelzer, I have tested your ppa and got the same issue so like I thought, in my case, the utopic type is a 2.3 type === _degorenko|afk is now known as degorenko === amoralej|lunch is now known as amoralej [13:28] sileht: I was afraid of that, but thanks for verifying [13:29] cpaelzer, for my cluster I can live with the custom package for a while [13:30] cpaelzer, don't hesitate to ping me for real testing [13:30] sileht: thanks - I highly appreciate your report and your fast feedback on this - yet as we agreed before it is an ugly issue and won't make me or anybody else ever really "happy" [13:53] I want to use debootstrap to create a new xenial image, my machine is running on precise. How do I add xenial to debootstrap on an old version of ubuntu? [13:53] i created a symlink in /usr/share/debootstrap/scripts ( ln -s gutsy xenial ) [13:54] oops [13:55] nevermind, it's ubuntu-vm-builder that I am using, not debootstrap. [13:56] i'll just install old-school using an iso [16:02] hey everyone, i edited the sudoers file with the command visudo and added the following line: "%rftadm ALL=(ALL) NOPASSWD:ALL" [16:02] it doesn't seem to be applied though [16:03] do i need to restart the system or any service? im running ubuntu 16.04 lts [16:03] i want every user in group rftadm to be able to use sudo without passwortprompt [16:10] zul can you review lp:~ddellav/ubuntu/+source/keystone master branch, I've implemented your config generator script and it seems to work but I want to make sure. I've installed the built package and it works. [16:11] KlausedSource: I think it has to have a space between ":" and ALL [16:12] KlausedSource: usually no restart/reload needed for that [16:12] KlausedSource: use "visudo" to edit the file that does all you need and locks properly [16:13] KlausedSource: IIRC for the groups you could also try "%rftadm ALL=NOPASSWD: ALL" [16:13] cpaelzer, i figured out the problem with space too. however that alone didn't fix it. [16:14] cpaelzer, the user was also in group sudo and for sudo there was a password-prompt (default) line in the sudoers file which lead to the setting being overwritten by it [16:15] KlausedSource: so it was an issue of first match then and is resolved for you now? [16:17] coreycb jamespage i need a review for the cinder sru: lp:~ddellav/ubuntu/+source/cinder newton branch, just a missing dependency added [16:20] cpaelzer, yes it is resolved now. however it wasn't first match but it got overwritten (first match was %rftadm, followed by %sudo) [16:21] KlausedSource: oh really - didn't remember it was that way around - thanks for sharing [16:22] cpaelzer, ye i thought it would be first match too that's why i posted here in the first place [16:24] jamespage: when you get a chance can you review this please? https://code.launchpad.net/~zulcss/charm-helpers/ocata-support/+merge/310678 [16:46] I just accidentally ran $ sudo setfacl -d -m g::--- / what is the correct group defaults that are supposed to be there?? [16:56] ddellav, can you add some more details to that bug, including sru sections in the description? [17:00] coreycb what would you suggest I use as the impact? I didn't initiate this sru from noticed behavior, it was simply missing a dependency. It still builds and installs fine. Should I attempt to create a situation where keystoneauth1 is required? [17:03] ddellav, i think if you look at cinder code that imports keystoneauth1 that wouldn't work if python-keystoneauth1 was missing [17:03] it's possible that keystoneauth1 is getting pulled in by another dependency though [17:06] coreycb it is being pulled in by python-keystoneclient [17:32] ddellav: and your keystone branch builds ok? [17:32] ddellav: changelog should be ubuntu1 btw [17:32] zul yes, in zesty [17:33] ddellav: fix the changelog and ill merge it [17:33] zul ah yea, dch incremented it. I'll fix it === iberezovskiy is now known as iberezovskiy|off [17:34] zul pushed [17:34] thanks [17:55] cpaelzer: is it possible to increase disk space on the s390x lpar? :) we ran out [18:09] powersj, there is very little disk space and it is epxensive [18:09] powersj, =/ [18:19] xnox: ok thanks for the heads up. I'll let cpaelzer respond to my email as well to see if we can slim down the images === amoralej is now known as amoralej|off === blacknred0 is now known as Guest22544 === Guest82234 is now known as blacknred0 [19:52] jamespage: https://code.launchpad.net/~zulcss/charm-helpers/fix-typo/+merge/310805 [20:46] hello [20:46] I have recently bought a 512MB vps [20:46] the images available are 16.04 64bit and 14.04 32bit and 64bit. [20:47] momken: So use 16.04 [20:47] momken: I don't see a question here. Use 16.04. [20:47] Is it better to have the more uptodate 16.04 64bit or less ram usage in 14.04 32bit^ [20:47] ? [20:48] Hmmm. Isn't 512MB ram very small for 16.04 64bit? [20:48] I think the 64bit system would consume ~1.5x ram than 32bit [20:48] You wont notice the difference in RAM usage. [20:49] Yout thought about that is entirely wrong. [20:49] *your [20:50] bekks, I don't think so. There is a little more usage because increased size of 64bit pointers [20:50] 1.5x is totally nonsense. [20:50] It is more significant in low rams. [20:50] "a bit more" means a few MB. Not 1.5x [20:50] bekks, But yeh I also think that should not be more than 100MB for increase [20:51] Where did you got that rumout from, regarding 1.5x? [20:51] bekks, It was only a guess [20:51] Hey guys, the Ansible's service module is not working on Debian / Ubuntu LTS, basically, this: "- service: name=dpdk enabled=yes", does nothing, service does not become enabled! `systemctl status dpdk` show its disabled, any clue? [20:51] momken: And that guess is horrible wrong. So just use 16.04 [20:51] I read somewhere it may even take more than 1.7x [20:51] bekks, OK, thanks [20:51] Wherever you read that - ignore that site from now on. [20:58] rbasak: ping, there was a bug you poked me on about a week ago, which one was it? === Guest22544 is now known as blacknred0 [22:06] Hey guys! I have an Ubuntu 16.04 running OpenvSwithc and DPDK, it is really awesome! From Newton Cloud Archive... [22:06] However, my Newton, is not using the OVS with DPDK, it still uses the regular OVS bridges... My KVM only setup with with OVS+DPDK but, Newton is "not aware" that OVS+DPKD is available... Where are the instructions? [22:07] This doc: http://docs.openstack.org/newton/networking-guide/config-ovs-dpdk.html looks not enough... [22:09] Do I need the "sudo apt install python-networking-vs-dpdk" package installed? [22:48] ThiagoCMC: hah, once again I thought of you being the expert here before I noticed that it was you asking the question.. [23:00] sarnold, lol [23:00] come on... =P [23:00] If I don't know, I don't know... [23:00] have to ask... =) [23:00] :)