| ScottK | ^^^ is just rejected so it doesn't get inadvertently accepted before I get my testing questions answered. | 03:27 |
|---|---|---|
| ScottK | And an FFe reviewed. | 03:51 |
| Laney | blerg, need to remember to pass --source to queue | 08:33 |
| === seb128_ is now known as seb128 | ||
| apw | ^ bug fix only update to ensure thermald runs correctly in the face of sysfs bits being late to the party | 08:50 |
| rbasak | cjwatson: reuploaded bcache-tools. Thanks for the review. | 09:18 |
| cjwatson | rbasak: ta | 09:20 |
| cjwatson | zul: Um I just noticed that python-nova.flex contains no useful files. Please can you run packages through sbuild before uploading them? | 09:24 |
| apw | ^ fix for vbox VMs failing to reach lightdm | 10:23 |
| knome | \o/ | 10:27 |
| mlankhorst | oh for the love of god.. | 10:41 |
| mlankhorst | https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1374131 seems that it needs libgl1-mesa-dri installed | 10:42 |
| ubot2 | Launchpad bug 1374131 in mesa (Ubuntu) "qtcreator-plugin autopkgtest fails on AMD64 mesa mesa_10.3.0" [Critical,Confirmed] | 10:42 |
| ogra_ | can someone approve phablet-tools and ubuntu-touch-meta ? | 11:11 |
| ogra_ | (i thought there is a bot that does it) | 11:12 |
| ogra_ | Laney, i assume you justified with the right people that it is ok to add another font to the seed (while we are just trying to only drop bits to make space) | 11:12 |
| cjwatson | 10:57 -queuebot:#ubuntu-release- Unapproved: accepted phablet-tools [sync] (utopic-proposed) [1.1+14.10.20140929-0ubuntu1] | 11:12 |
| ogra_ | oh | 11:12 |
| Laney | ogra_: are you telling me off? | 11:13 |
| ogra_ | missed that | 11:13 |
| cjwatson | And I'm not sure how ubuntu-touch-meta can possibly be accepted given that 1.187 is already in the archive. | 11:13 |
| cjwatson | rejecting | 11:13 |
| ogra_ | Laney, no, i was wondering if you talked to pmcgowan and slangasek ... who work on shrinking the image :) | 11:13 |
| ogra_ | hmm | 11:14 |
| ogra_ | why didnt i see it on -cahnges then | 11:14 |
| cjwatson | Please use "pull-lp-source ubuntu-touch-meta" as your starting point for uploads | 11:14 |
| Laney | I didn't justify with anybody, go ahead and revert if you want. Seems like a valid enough request to me. | 11:14 |
| cjwatson | ogra_: anyway, https://lists.ubuntu.com/archives/utopic-changes/2014-September/010878.html | 11:15 |
| ogra_ | Laney, right, to me too ... we can still remove it if someone complains ... that was simply the reason why i didnt merge it yet | 11:15 |
| ogra_ | cjwatson, yeah, i see it now | 11:15 |
| Laney | Nobody even responded to the request at all | 11:15 |
| cjwatson | ... but it makes ubuntu-touch/i386 uninstallable apparently | 11:15 |
| ogra_ | hmm | 11:15 |
| cjwatson | libqt5gui5-gles : Conflicts: libqt5gui5 but 5.3.0+dfsg-2ubuntu6 is to be installed | 11:17 |
| cjwatson | libqt5quick5-gles : Conflicts: libqt5quick5 but 5.3.0-3ubuntu12 is to be installed | 11:17 |
| cjwatson | because signon-apparmor-extension needs to be built against -gles on !armhf, I think? | 11:18 |
| ogra_ | oh, fun | 11:18 |
| cjwatson | possibly | 11:18 |
| ogra_ | yeah | 11:18 |
| cjwatson | oh, no, it's the sdk-libs changes | 11:18 |
| ogra_ | so that needs arch specific differentiation i guess | 11:20 |
| cjwatson | yup, will sort it out | 11:20 |
| ogra_ | thanks | 11:20 |
| cjwatson | ogra_: does http://paste.ubuntu.com/8454630/ look right in terms of the package organisation? | 11:21 |
| ogra_ | cjwatson, it does, are these two enough ? | 11:22 |
| cjwatson | the others there don't have -gles variants | 11:22 |
| ogra_ | k | 11:22 |
| cjwatson | Laney: it would be nice if you could have merged your branch into trunk when you noticed the divergence, rather than merging trunk into your branch and then pushing that over the top of trunk | 11:23 |
| cjwatson | produces confusing bzr log :-/ | 11:23 |
| Laney | mmm, apols, can overwrite if you like? | 11:24 |
| cjwatson | if you could then now might be a good time, yeah | 11:24 |
| Laney | cjwatson: try that | 11:29 |
| cjwatson | Laney: thanks | 11:31 |
| cjwatson | ogra_: committed, if you want to redo a 1.188 upload with a fresh seed update | 11:31 |
| === agateau_ is now known as agateau | ||
| mlankhorst | cjwatson: hey I've fixed the dependency issue of mesa, shall I re-upload? | 12:23 |
| cjwatson | mlankhorst: I know nothing about this beyond people having asked me about it the other day and me redirecting them | 12:26 |
| cjwatson | Do what seems appropriate :) | 12:26 |
| mlankhorst | I've found the root cause at least | 12:27 |
| mlankhorst | it being that it was working by pure chance before. :P | 12:28 |
| mlankhorst | DISPLAY=:0 glxinfo | 12:31 |
| mlankhorst | name of display: :0 | 12:31 |
| mlankhorst | Error: couldn't find RGB GLX visual or fbconfig | 12:31 |
| mlankhorst | oops | 12:31 |
| mlankhorst | didn't mean to copy paste | 12:31 |
| Laney | It'd be nice if someone could review gnome-desktop3 - it's a small transition that we want to do quickly | 13:49 |
| cjwatson | infinity,slangasek: openssl and grub2 reviews from unapproved would be lovely when you're around. | 14:15 |
| ogra_ | that package name could need a few more "s" in it :P | 14:20 |
| jamespage | ^^ that keystone upload does a variety of good things and should unblock all of the pending oslo.* packages stuck in proposed on failing autopkgtests | 14:37 |
| mlankhorst | same for mesa, i promise it won't break qtbase-opensource-src this time. :D | 14:40 |
| cjwatson | reviewing | 14:41 |
| Laney | is it possible to get the signer of a queue item? | 15:01 |
| Laney | Don't see anything on package_upload | 15:01 |
| ScottK | For mesa it's not the known stuff I worry about. | 15:04 |
| jamespage | thanks cjwatson | 15:09 |
| === bladernr_30kFeet is now known as bladernr_ | ||
| === Guest13468 is now known as balloons_ | ||
| Riddell | anyone know what's wrong with okular? it seems the main blocker to KDE SC 4.14.1 bits getting in the archive but I can't see a failure in jenkins http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html | 15:32 |
| rbasak | Riddell: https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-okular/lastBuild/? shows as failed to me. | 15:34 |
| Laney | https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-okular/lastBuild/ARCH=amd64,label=adt/artifact/results/testsuite-stdout | 15:34 |
| Laney | That's faily | 15:34 |
| Riddell | ah hah, I was looking at the "log" file | 15:37 |
| Riddell | thanks Laney | 15:37 |
| Laney | it's in there, you just have to look harder | 15:38 |
| Laney | 'testsuite' has its output before 'acc' | 15:38 |
| Riddell | ah yes, still getting my head around this autopkgtest stuff | 15:40 |
| zul | ^^^ the nova-compute-flex makes it installable and fixes races with cgmanager | 15:51 |
| infinity | cjwatson: I assume you're using the word "review" very loosely in the openssl case. | 16:29 |
| infinity | cjwatson: "Yes, your rainbow tables all look correct, I re-calculated them on a napkin." | 16:29 |
| cjwatson | infinity: right :) that took me roughly a day of resolving merges on two monitors | 16:32 |
| cjwatson | infinity: I ended up importing the current package state into git temporarily so that I could cherry-pick the requested series from upstream and then compare that against the rolled-up patch I'd been given to make sure I'd resolved conflicts correctly ... | 16:32 |
| infinity | cjwatson: Well, not matching theirs doesn't imply you're the one that did it wrong. :P | 16:33 |
| infinity | cjwatson: But if both ended up the same, that has some implication that you're both equally smart or equally unlucky. | 16:34 |
| infinity | cjwatson: So, yeah, more of a verbal review, then. Did yours, indeed, match theirs in the end? | 16:34 |
| infinity | cjwatson: And this is building with full testsuite goodness and no obvious regressions? | 16:35 |
| cjwatson | close enough. there were a few bits where they'd pulled unnecessary bits of other patches, and I went with my own resolution. I'd made one or two mistakes which I found that way and corrected. | 16:35 |
| infinity | cjwatson: And, how can we test the POWER8 stuff (can I build it on a P7 host, and run a testsuite on P8 and watch for bogons?) | 16:35 |
| cjwatson | I built on amd64/powerpc/ppc64el and the test suites passed | 16:35 |
| cjwatson | I trust that the last is true but don't have one to test on :) | 16:36 |
| infinity | Sure, but building on ppc64el probably means POWER7, which would skip any P8-optimised bits. | 16:36 |
| infinity | So, how can we test on P8? I think we should, since that's the whole point of the upload. | 16:36 |
| cjwatson | Fair question. I think: build source package on p7, rsync built tree to p8, run 'make test' | 16:38 |
| cjwatson | Do I have access to one I've forgotten about? | 16:38 |
| infinity | cjwatson: Kay. That sounds reasonable. Want to spin up a test tree on kelsey, and I'll do the second bit when I find a host to slap a chroot on? | 16:39 |
| infinity | cjwatson: You might have access to a few, though what state any of them are in is the more interesting question. | 16:39 |
| cjwatson | infinity: OK, (re-)building on kelsey01 | 16:41 |
| === seelaman is now known as IS_hr_bot | ||
| === IS_hr_bot is now known as seelaman | ||
| cjwatson | infinity: kelsey01:~cjwatson/openssl-1.0.1f/ | 17:03 |
| infinity | cjwatson: Ta. | 17:04 |
| dobey | uploads to seeded packages are ok now as long as they don't break feature/ui/string freeze, right? | 17:07 |
| cjwatson | Yes, they're just held for manual review | 17:12 |
| dobey | ok | 17:15 |
| cjwatson | infinity: I take it it passed? | 17:19 |
| infinity | cjwatson: Nah, I was on a call with our fearless leader. | 17:56 |
| cjwatson | infinity: Oh. Somebody accepted it. | 17:59 |
| infinity | Oh. Indeed somebody did. | 18:00 |
| infinity | I wonder how they "reviewed" it. | 18:00 |
| infinity | Anyone want to confess to accepting that openssl upload? :P | 18:00 |
| infinity | cjwatson: I guess no one's fessing up. I'll test it anyway in a bit. | 18:11 |
| infinity | (I wish someone had finished that queue auditing feature...) | 18:11 |
| cjwatson | Thanks | 18:14 |
| bdmurray | cjwatson: slangasek ran change-override for aptdaemon but there is no information about that here - https://launchpad.net/ubuntu/trusty/amd64/aptdaemon. Any ideas? | 18:14 |
| cjwatson | bdmurray: That's where it would've appeared | 18:14 |
| cjwatson | So need to know what he did | 18:14 |
| cjwatson | (Assuming he did a binary override in the correct suite including that architecture ...) | 18:15 |
| infinity | bdmurray: Ran change-override to what end? | 18:15 |
| bdmurray | infinity: to fully phased the update | 18:15 |
| bdmurray | 18:09 <slangasek> $ change-override -z 100 -s trusty-updates aptdaemon | 18:15 |
| infinity | Looks fully phased to me. | 18:15 |
| cjwatson | Then that worked fine | 18:15 |
| cjwatson | phase 100 shows empty in that column | 18:16 |
| infinity | Empty... What Colin said. | 18:16 |
| infinity | Small UI bug that could be filed, perhaps. | 18:16 |
| infinity | Er, of course, that should have been -S aptdaemon, to phase all the binaries from the source. | 18:18 |
| infinity | Oh, I say that, but python3-aptdaemon also looks phased. | 18:18 |
| infinity | So maybe slangasek did them individually. | 18:18 |
| infinity | slangasek: ^? | 18:18 |
| bdmurray | I understand that empty means 100%, the timing is particularly confusing | 18:19 |
| bdmurray | 17:08:15 ... 0% of users | 18:19 |
| bdmurray | 17:08:14 ... empty | 18:20 |
| slangasek | infinity: I mistakenly did it without -S the first time around, then went back and used -S on a second pass when bdmurray called my attention back to it | 18:20 |
| infinity | bdmurray: That's the date it was deleted/superseded, not the date it was set to 0% | 18:20 |
| infinity | slangasek: Ahh, kay. | 18:20 |
| infinity | bdmurray: The history output is a bit confusing in that regard, I agree. | 18:20 |
| slangasek | cjwatson, infinity: I accepted the openssl upload, as cjwatson highlighted both of us and infinity did not tell me he was claiming it :) | 18:22 |
| infinity | slangasek: Oh. Backscroll had me waffling about unreviewability and that it should be tested first. | 18:22 |
| slangasek | infinity: yep; didn't see that until now | 18:22 |
| slangasek | so, well, feel free to continue testing | 18:23 |
| infinity | slangasek: But I assume you pored over all the assembly and recalculated the rainbow tables by hand, so we're good. ;) | 18:23 |
| slangasek | I'll say that's what I did, sure | 18:23 |
| infinity | :) | 18:23 |
| infinity | bdmurray: Hrm. Is it an lpapi bug or sru-review bug that it seems to pick up the wrong diff for a package that's been uploaded, rejected, and reuploaded with the same version? | 18:28 |
| bdmurray | infinity: which package? | 18:29 |
| infinity | bdmurray: flash-kernel, it's picking the debdiff from rejected. | 18:30 |
| bdmurray | infinity: it uses the debdiff in launchpad so - https://launchpadlibrarian.net/186070966/flash-kernel_3.0~rc.4ubuntu49.3_3.0~rc.4ubuntu49.4.diff.gz | 18:31 |
| infinity | bdmurray: But that's not the diff I'm getting. | 18:31 |
| infinity | bdmurray: Does it cache locally? | 18:31 |
| bdmurray | infinity: nope, I'll take a look | 18:31 |
| infinity | bdmurray: ... And now I do get that diff. WTF? | 18:33 |
| infinity | bdmurray: Does it fall back to other queues if unapproved doesn't have a diff yet, maybe? | 18:33 |
| bdmurray | infinity: no, but there is a --queue option | 18:35 |
| infinity | bdmurray: Which I wasn't uding, since it defaults to unapproved. | 18:35 |
| infinity | s/uding/using/ | 18:35 |
| === balloons_ is now known as balloons | ||
| === balloons is now known as Guest63150 | ||
| === Guest63150 is now known as balloons_ | ||
| === jhenke_ is now known as jhenke | ||
| === balloons_ is now known as balloons | ||
| hallyn | hi, bugs 1374622, 1374617 and 1374612 fix the inability to migrate VMs from p->t. The latter two require FFE for u. The second is a new package with only 4 pxe roms. | 20:56 |
| ubot2 | bug 1374622 in libvirt (Ubuntu Trusty) "Support migration from 12.04" [High,New] https://launchpad.net/bugs/1374622 | 20:56 |
| ubot2 | bug 1374617 in Ubuntu Trusty "[FFE] New package: ipxe-precise" [High,New] https://launchpad.net/bugs/1374617 | 20:56 |
| ubot2 | bug 1374612 in qemu (Ubuntu Trusty) "[FFE] add pc-1.0-precise machine type" [High,New] https://launchpad.net/bugs/1374612 | 20:56 |
| infinity | hallyn: How is this meant to work to the user without excessive documentation? | 21:02 |
| infinity | hallyn: If their old machines were pc-1.0, starting them on trusty won't magically use pc-1.0-precise, I assume. Will it fail to boot gracefully with an error telling them what to do? | 21:02 |
| infinity | hallyn: And once it's migrated, does it become "pc-1.0" again and use the new ipxe ROMs, or are they stuck as pc-1.0-precise forever? | 21:04 |
| infinity | I'm a bit fuzzy on how this works. | 21:04 |
| hallyn | infinity: once they've migrated to trusty, it'll be called pc-1.0-precise | 21:05 |
| hallyn | then they can edit the machine type to be something newer if they like | 21:06 |
| infinity | Can't that be handled transparently, then? | 21:06 |
| hallyn | but yes, the switch to pc-1.0-precise wont' be automatic. they have to set a libvirt flag | 21:06 |
| hallyn | which part | 21:06 |
| infinity | Well, with any luck, all of it. | 21:06 |
| infinity | So, AIUI, we need to go from precise/1.0 to trusty/1.0-precise to trusty/1.0, cause you stop in the middle, you're still using ipxe-precise, which we don't want to keep forever, yes? | 21:07 |
| hallyn | no. because pc-1.0 means two different things. so we are introducing pc-1.0-precise to refer to one of them, and using the libvirt flag to tell libvirt which to use | 21:07 |
| infinity | s/cause you/cause if you/ | 21:07 |
| hallyn | it's ok to use pc-1.0-precise at least as long as precise is supported | 21:08 |
| hallyn | and realistically we'll probably never get rid of it. | 21:08 |
| infinity | So, I guess I have two questions. 1) if we can move from trusty/1.0-precise to trusty/1.0, why can't we move from precise/1.0 to trusty/1.0, and 2) can we make either step more automatic? | 21:08 |
| hallyn | just as the default machine type in trusty is now caled 'pc-i440fx-trusty | 21:08 |
| hallyn | 1) is false. ou'd move to something newer ,not to 1.0 | 21:09 |
| hallyn | 2) we can't make it more automatic bc there is no way to tell which pc-1.0 they are sending us. | 21:09 |
| infinity | Err, whatever, ignore my terminology. | 21:09 |
| infinity | But you can move from trusty/1.0-precise to trusty/pc-i440fx-trusty then, right? | 21:09 |
| hallyn | while it is shut down, yes | 21:09 |
| infinity | What happens when I try to migrate precise to trusty today? | 21:10 |
| hallyn | one of the proposed packages is to make pc-1.0-precise the default in precise to cut down on the amount by which this happens now | 21:10 |
| hallyn | it simply fails | 21:10 |
| infinity | Is it a detectable failure? | 21:11 |
| infinity | Or completely nonsensical? | 21:11 |
| hallyn | not complete nonsensical. it's detectable if yo uknow what to look for | 21:11 |
| infinity | Okay, so if it's detectable, it's automatable. | 21:12 |
| hallyn | it'll complain about memory segments not being the same or somesuch | 21:12 |
| hallyn | at what level though. some ppl are doing qemu migration by hand. there yo ubasically get no feedback at the source site, other than that the vm kept running instead of stopping | 21:12 |
| hallyn | some are using libvirt. we coudl indeed try to fix it automatically there, but it would not be simple. the destination would have to detect it, then tell the source to restart | 21:13 |
| hallyn | the ipxe-precise package would be needed regardless, | 21:13 |
| hallyn | for qemu users really it can't be automaticed more tha nit is - you specify the target machine type with 'qemu -M pc-1.0-precise', jsuts as you would otherwise do 'qemu -M pc-1.0'. you have to specify it regardless. | 21:15 |
| infinity | hallyn: Right, not disputing the need for the new package, just thinking that we can do better than "oh, yeah, that failed because you need to read obscure doc X". | 21:15 |
| infinity | hallyn: For qemu, it could still be trapped, I'd think. If -M pc-1.0 runs into the memory segment consistency issue, can we not do some checksums, compare to our other ipxe on disk, go "oh, no, we need that one", and reboot with that machine type? | 21:16 |
| hallyn | we have discussed making the fallback to the pc-1.0-precise the default; that would throw users who were using 'pc-1.0' in trusty (which some would say would be their own fault, but i think that's not quite true) | 21:16 |
| infinity | hallyn: Thus eliminating the need for people or tools to specify -precise at all, we just twiddle it. | 21:16 |
| hallyn | rharper: ^ got a job for you :) | 21:17 |
| rharper | hallyn: sup | 21:17 |
| hallyn | infinity: it may be possible | 21:17 |
| hallyn | i'm not sure we can restart at that level | 21:17 |
| hallyn | sure we can always re-exec ourselves :) | 21:17 |
| infinity | It's all just a userspace program, you can restart at any level. | 21:17 |
| infinity | You just need some cleverness. | 21:17 |
| hallyn | do we want cleverness in an sru? | 21:17 |
| infinity | I'd rather cleverness than something that technically fixes the issue but is hard to discover. | 21:18 |
| hallyn | so yeah, it should be possible. detect an old vga size paired with pc-1.0, then re-exec ourselves with "-M pc-1.0-precise" | 21:18 |
| infinity | At worst, I'd like it to be able to detect the issue and print "you probably want -M pc-1.0-precise", but once we've gone that far trapping it, a bit more clever to JDTRT might be the best option. | 21:18 |
| rharper | hallyn: if I'm reading backscroll right, neither qemu nor libvirt are the right place to "detect" which type to be used | 21:18 |
| hallyn | then what is? | 21:19 |
| infinity | qemu seems like the ideal lowest common denominator. | 21:19 |
| infinity | It's the only one that knows something's broken. | 21:19 |
| hallyn | if we *could* have qemu just re-exec itself, then libvirt wouldn't need to do anything | 21:19 |
| rharper | at the end of the day, folks without a higher level management tool which makes migration and machine type decisions (versus taking hte defaults which is what both do) it's going to be trouble getting it "right" | 21:19 |
| hallyn | infinity: so to be clear the machine type as such is not passed from source to destination | 21:20 |
| rharper | not sure I follow the re-exec -- when migration fails you retain the original qemu -- and IIUC folks don't want to actually have to reboot/restart their qemu VM | 21:20 |
| hallyn | rharper: re-exec the destination | 21:20 |
| rharper | who? | 21:20 |
| hallyn | and somehow signal the source to restart :) | 21:20 |
| hallyn | itself | 21:20 |
| rharper | no one is reexecting in the qemu case | 21:20 |
| rharper | libvirt *could* but that's just a guess | 21:20 |
| rharper | and what if migration fails for some other reason | 21:20 |
| hallyn | qemu could do it itself. | 21:20 |
| rharper | no way to know that it should do that | 21:20 |
| infinity | What if it fails for "some other reason'? | 21:21 |
| infinity | I don't care about some other reason. | 21:21 |
| infinity | I'm specifically curious about "pc-1.0" failing due to this specific issue. | 21:21 |
| hallyn | detect that vgasize is that of pc-1.0-precise while m-t is pc-1.0. D oit only in that case | 21:21 |
| rharper | how long do you want and how many times do we want qemu to keep rexecing itself ? | 21:21 |
| hallyn | infinity: but i still don't know how we could tell the source qemu to re-start migration | 21:21 |
| infinity | Which should be entirely solvable by detecting the situation and swithcing to pc-1.0-precise. | 21:21 |
| rharper | this all seems crazy hacky | 21:21 |
| hallyn | rharper: agreed, but the goal of something easier ofr the user to discover is laudible | 21:22 |
| rharper | scan some part of the incoming migration data, some how track these parts in some state (or write it out) so it can recall what happened the last N times we re-exec'ed ourselves ? | 21:22 |
| hallyn | rharper: yup, write out what we've read so far, re-exec ourselves with -m pc-1.0-precise; if we're already exec'd with that we just fail | 21:23 |
| infinity | hallyn: So, the problem here is that qemu itself is also doing the migration? This isn't fed to it by some higher level tool? (I'm mostly ignorant to how this works). | 21:23 |
| rharper | that sounds like a really bad idea w.r.t keep state, how to handle if the file is still around, or if it contains bogus data, or ... | 21:23 |
| hallyn | infinity: right, the two qemu processes do it with a'migrate' API | 21:23 |
| hallyn | rharper: it works for upstart :) | 21:23 |
| infinity | And who triggers the migration? Source or destination? | 21:23 |
| rharper | qemu can't migrate itself -- it always requires a third party to initiate migration | 21:23 |
| hallyn | both :) | 21:23 |
| rharper | neither | 21:24 |
| rharper | mgmt | 21:24 |
| hallyn | destination is started with "-incoming tcp:0.0.0.0:5555" | 21:24 |
| hallyn | source is told "migrate tcp:a.b.c.d:5555" | 21:24 |
| rharper | management application ( most likely libvirt ) is issued a migration command to the source (with the destination URL); | 21:24 |
| rharper | and mgmt app does as hallyn describes under the covers; | 21:25 |
| infinity | Okay, but once it's started, the destination knows the source, as it has an open TCP connection to it. | 21:25 |
| hallyn | and qemu does the migration :P | 21:25 |
| hallyn | yup | 21:25 |
| infinity | So, no need to save temp files or other ugliness. | 21:25 |
| rharper | we can't modify the migration protocol | 21:25 |
| infinity | You detect the bad memory segment, and restart the source migration. | 21:25 |
| rharper | source doesn't retain any state w.r.t migration succeeding or failing, the mgmt application can/could | 21:26 |
| hallyn | infinity: if we make that kind of change, supporting/backporting future CVEs until 2019 is gonna hurt | 21:26 |
| infinity | Bleh. Maybe. | 21:26 |
| infinity | I just see limited value in non-discoverable ways to work around bugs. | 21:26 |
| hallyn | well lemme put it another way - i don't believe any 'ordinary user' is going to migrate vms from P->T | 21:26 |
| infinity | And "we documented it somewhere, really" isn't discoverable. | 21:27 |
| hallyn | we saw limited value in supporting this at all, but ablight needed it enough that he wrote the patches himself to fix it. his own site is done entirely with thie rown mgmt toold | 21:27 |
| rharper | honestly, the easiest fix I'd say for 99% of folks is to shutdown your Precise VM, modify the machine type to pc-1.0-precise | 21:27 |
| rharper | and then we're all good | 21:27 |
| rharper | or offline migration to trusty | 21:27 |
| hallyn | agreed. this is mainly for ppl who have tons of customers not willing to shut down | 21:27 |
| infinity | rharper: sure, but those people need to be told to do that. | 21:27 |
| hallyn | but we can't predict how they're using this. if they're using netcat to a qemu monitor socket they won't see any info we try to hand them | 21:28 |
| infinity | Anyhow, I'm not saying magic is a blocker for this, I'm just examining if there are better ways. | 21:28 |
| rharper | indeed; I don't think there is an easy package-specific place to do this... | 21:28 |
| hallyn | so right now what happens is - they try to migrate, it fails. the question is, is there any better way - other than release notes and/or a lp bug - to let them know that hey they can re-try it like this | 21:29 |
| infinity | I'm more concerned about if this will come up again between 14.04 and 16.04, etc. | 21:29 |
| hallyn | that shouldn't, that's why we have the pc-i440fx-trusty machine type | 21:29 |
| hallyn | so we can do magic | 21:29 |
| infinity | hallyn: Release Notes are useless to communicate to users on release day, they're even worse after. | 21:29 |
| hallyn | we could do magic if we didn't care about 14.04 pc-1.0 users | 21:29 |
| infinity | hallyn: So, a special trusty machine type is a start, but I assume this still implies we might need 14.04 ROMs in 16.04? | 21:30 |
| infinity | hallyn: So, better magic for the users, same mess for us? :) | 21:30 |
| rharper | documenting on wiki and socializing the document | 21:30 |
| rharper | that's not the best, but better than nothing | 21:30 |
| hallyn | infinity: we will need old roms, yes. fixing that is not up to us, but up to the qemu folks. they believe it's up to distros to work that out. | 21:31 |
| infinity | I wonder if/how this affects non-BIOS arches. | 21:31 |
| infinity | OVMF, SLOF, etc. | 21:31 |
| hallyn | egads, for that matter, we never got qemu-slof ot compile for utopic | 21:31 |
| hallyn | ("that reminds me") | 21:31 |
| infinity | hallyn: Err, never got it to compile? | 21:32 |
| infinity | hallyn: Is it currently sad? | 21:32 |
| hallyn | correct. | 21:32 |
| infinity | binutils segv. Exciting. | 21:33 |
| infinity | I can look at that in a bit. | 21:33 |
| hallyn | infinity: now the roms have to change their size to the next o(log n) or something before it matters that they changed, which odesn 'thappen much. otherwise new roms are fine during migration. | 21:33 |
| hallyn | but when thta does happen, then we need to package the old roms and direct qemu to them. | 21:33 |
| hallyn | on the bright side, we can do that automatically | 21:33 |
| hallyn | (for the user, not for us) | 21:33 |
| infinity | This all sounds a whole like some serious design flaws. ;) | 21:34 |
| rharper | fwiw I do believe this is something that QEMU should address upstream, but it's not an easy thing to do | 21:34 |
| infinity | Alright, so I'm not happy about, but can accept "manual migration, icky forward-ported ROMs, and socializing docs", but I'd really like better answers. | 21:35 |
| infinity | The docs part goes away for 14.04->16.04, so that's a plus, but the rest still looks sketchy. | 21:35 |
| rharper | the idea of a OS or VM being bound to a machine, is very much like real hardware ... and part of real hardware (and virtual) is the BIOS/Firmware/Blob -- that ought to be something we can encapsulate (if users desire) | 21:36 |
| rharper | and possibly included in the payload of the VM. | 21:36 |
| infinity | rharper: Effectively, save the firmware blobs that the VM was started with as an nvram blob that gets reused and passed around? | 21:36 |
| infinity | That has the disadvantage that it's then hard to upgrade the firmware. | 21:36 |
| infinity | But I guess this is a case where having and eating cake might just be really hard. | 21:37 |
| infinity | Or impossible. | 21:37 |
| rharper | infinity: I think it can be worked out -- the nvram stuff already has a "writable" drive that needs to be kept with the the VM | 21:39 |
| rharper | no reason that we couldn't keep/load/write roms for BIOS as well -- but we need to think carefully about how to handle the permissions needed to host these VMs that can care and update their own BIOS | 21:40 |
| rharper | with something like qcow2 (or other metadata drive files) one could even mark out hidden partitions to hold this... but it's seriously like a qemu 3.0 sort of feature as it will cut across all of QEMU | 21:40 |
| hallyn | rharper: did you mention recently that you were talking about just that with qemu upstream? What sort of venue was that, i.e. email/irc, and is there a log? | 21:41 |
| infinity | rharper: Yeah, that sounds rather complex and whacky. | 21:41 |
| rharper | hallyn: not upstream, with alex | 21:41 |
| rharper | hallyn: I probably have the log | 21:41 |
| hallyn | rharper: oh, ok, i thought you had told alex you'd been talking with upstream about something like that. nm then | 21:48 |
| hallyn | infinity: so really, the libvirt patch could be tweaked so that if /etc/libivrt/qemu.conf does not have 'assume_incoming_qemukvm = 1' and machine type is pc-1.0, it spits a warning out "if migration fails, try setting that" | 21:56 |
| ari-tczew | do we still use subscribing to ~ubuntu-release for FFe reviews? | 21:58 |
| infinity | ari-tczew: Yeah. It does hurt to poke people on IRC too, though. | 22:00 |
| infinity | cjwatson: Want to lob a grub2-signed at the queue too, or should I do that? | 22:01 |
| cjwatson | infinity: I was going to do that, yeah. | 22:02 |
| cjwatson | infinity: ^- | 22:38 |
| infinity | cjwatson: Ta. | 22:40 |
| xnox | infinity: Laney: poke re:FFe Bug #1372367 | 23:44 |
| ubot2 | bug 1372367 in btrfs-tools (Ubuntu Utopic) "FFe Upgrade btrfs-tools to 3.16" [Undecided,New] https://launchpad.net/bugs/1372367 | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!