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