| === Sooty is now known as Guest69692 | ||
| === amoralej|off is now known as amoralej | ||
| === iberezovskiy|off is now known as iberezovskiy | ||
| 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 |
|---|---|---|
| ubottu | Launchpad bug 1641532 in qemu (Ubuntu) "Unknown ramblock "/rom@etc/acpi/rsdp", cannot accept migration" [Undecided,New] | 10:26 |
| sileht | zul, jamespage, coreycb, ddellav, I thnk this should be fixed before openstack user try to upgrade from mitaka to newton | 10:26 |
| 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:27 |
| cpaelzer | grr no meeting minutes uploaded last week | 10:28 |
| 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:29 |
| * cpaelzer is still checking - envision a spinning wheel here - \ | / - ... | 10:32 | |
| sileht | :) | 10:33 |
| cpaelzer | sileht: not a dup to the one I thought - now context switching into the bug more | 10:34 |
| sileht | cpaelzer, I have tested the patch I have attached to the bug report on my cluster and it works well | 10:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| cpaelzer | and it did not help that the way to define them was changed three times in the last 2 years | 10:47 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| cpaelzer | where it picked up the latest type | 11:36 |
| sileht | cpaelzer, utopic was shipped qemu 2.1 ? | 11:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| sileht | cpaelzer, yes this is what I would say | 11:40 |
| 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:42 |
| 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:44 |
| 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:45 |
| cpaelzer | sileht: hmm, the pc-i440fx is also only a pointer to latest | 11:46 |
| sileht | cpaelzer, let's me check what I really have currently running | 11:47 |
| 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:49 |
| 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:51 |
| sileht | cpaelzer, kilo UCA have the utopic machine patch and it's 2.2 :( | 11:53 |
| sileht | this is an awful bug | 11:54 |
| 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:00 |
| 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:04 |
| 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:05 |
| 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:06 |
| cpaelzer | sorry | 12:07 |
| cpaelzer | bad reference - ignore it | 12:07 |
| 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:10 |
| sileht | cpaelzer, because UCA have backported qemu without updating define-ubuntu-machine-types.patch correctly | 12:12 |
| 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:13 |
| cpaelzer | sileht: do you need more than x86 for your tests if I prep a ppa? | 12:32 |
| sileht | cpaelzer, no I only have amd64 server | 12:33 |
| cpaelzer | jamespage: FYI - you might want to reread bug 1641532 content and triage accordingly for UCA now | 12:41 |
| ubottu | 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 | 12:41 |
| === amoralej is now known as amoralej|lunch | ||
| jamespage | cpaelzer, ack | 12:53 |
| 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:16 |
| === _degorenko|afk is now known as degorenko | ||
| === amoralej|lunch is now known as amoralej | ||
| cpaelzer | sileht: I was afraid of that, but thanks for verifying | 13:28 |
| sileht | cpaelzer, for my cluster I can live with the custom package for a while | 13:29 |
| 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:30 |
| 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:53 |
| bananapie | oops | 13:54 |
| bananapie | nevermind, it's ubuntu-vm-builder that I am using, not debootstrap. | 13:55 |
| bananapie | i'll just install old-school using an iso | 13:56 |
| 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:02 |
| 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:03 |
| 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:10 |
| cpaelzer | KlausedSource: I think it has to have a space between ":" and ALL | 16:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| cpaelzer | KlausedSource: so it was an issue of first match then and is resolved for you now? | 16:15 |
| ddellav | coreycb jamespage i need a review for the cinder sru: lp:~ddellav/ubuntu/+source/cinder newton branch, just a missing dependency added | 16:17 |
| 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:20 |
| cpaelzer | KlausedSource: oh really - didn't remember it was that way around - thanks for sharing | 16:21 |
| KlausedSource | cpaelzer, ye i thought it would be first match too that's why i posted here in the first place | 16:22 |
| zul | jamespage: when you get a chance can you review this please? https://code.launchpad.net/~zulcss/charm-helpers/ocata-support/+merge/310678 | 16:24 |
| Pinkamena_D | I just accidentally ran $ sudo setfacl -d -m g::--- / what is the correct group defaults that are supposed to be there?? | 16:46 |
| coreycb | ddellav, can you add some more details to that bug, including sru sections in the description? | 16:56 |
| 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:00 |
| 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:03 |
| ddellav | coreycb it is being pulled in by python-keystoneclient | 17:06 |
| 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:32 |
| zul | ddellav: fix the changelog and ill merge it | 17:33 |
| ddellav | zul ah yea, dch incremented it. I'll fix it | 17:33 |
| === iberezovskiy is now known as iberezovskiy|off | ||
| ddellav | zul pushed | 17:34 |
| zul | thanks | 17:34 |
| powersj | cpaelzer: is it possible to increase disk space on the s390x lpar? :) we ran out | 17:55 |
| xnox | powersj, there is very little disk space and it is epxensive | 18:09 |
| xnox | powersj, =/ | 18:09 |
| 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 | 18:19 |
| === amoralej is now known as amoralej|off | ||
| === blacknred0 is now known as Guest22544 | ||
| === Guest82234 is now known as blacknred0 | ||
| zul | jamespage: https://code.launchpad.net/~zulcss/charm-helpers/fix-typo/+merge/310805 | 19:52 |
| 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:46 |
| 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:47 |
| 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:48 |
| bekks | Yout thought about that is entirely wrong. | 20:49 |
| bekks | *your | 20:49 |
| 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:50 |
| 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:51 |
| teward | rbasak: ping, there was a bug you poked me on about a week ago, which one was it? | 20:58 |
| === Guest22544 is now known as blacknred0 | ||
| 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:06 |
| ThiagoCMC | This doc: http://docs.openstack.org/newton/networking-guide/config-ovs-dpdk.html looks not enough... | 22:07 |
| ThiagoCMC | Do I need the "sudo apt install python-networking-vs-dpdk" package installed? | 22:09 |
| sarnold | ThiagoCMC: hah, once again I thought of you being the expert here before I noticed that it was you asking the question.. | 22:48 |
| 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 | :) | 23:00 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!