Wednesday, 2020-01-22

sean-k-mooneygmann: efried so it looks like its failing ot install os-testr00:05
sean-k-mooneyhttp://paste.openstack.org/show/788663/00:06
sean-k-mooneyor rather willl install os tester that try to replace PyYAML00:06
*** jmlowe has joined #openstack-nova00:11
*** derekh has quit IRC00:16
*** jmlowe has quit IRC00:27
*** mlavalle has quit IRC00:29
*** jmlowe has joined #openstack-nova00:35
*** TxGirlGeek has quit IRC00:36
*** jmlowe has quit IRC00:47
*** mkrai_ has joined #openstack-nova01:43
*** gyee has quit IRC02:04
*** mkrai__ has joined #openstack-nova02:05
*** Liang__ has quit IRC02:06
*** mkrai_ has quit IRC02:08
*** TxGirlGeek has joined #openstack-nova02:51
*** gentoorax has quit IRC02:55
openstackgerritmelanie witt proposed openstack/nova stable/pike: Avoid redundant initialize_connection on source post live migration  https://review.opendev.org/68300802:55
*** jkulik has quit IRC03:00
*** mvkr has quit IRC03:02
*** gentoorax has joined #openstack-nova03:11
*** mvkr has joined #openstack-nova03:13
*** jkulik has joined #openstack-nova03:26
*** nweinber__ has joined #openstack-nova03:42
*** nweinber__ has quit IRC04:02
*** udesale has joined #openstack-nova04:04
*** mkrai__ has quit IRC04:12
*** mkrai_ has joined #openstack-nova04:12
*** links has joined #openstack-nova05:16
*** artom has quit IRC05:28
*** evrardjp has quit IRC05:34
*** evrardjp has joined #openstack-nova05:34
*** alex_xu has quit IRC05:41
*** rchurch has quit IRC05:44
*** Jeffrey4l has quit IRC05:45
*** Jeffrey4l has joined #openstack-nova05:46
*** rchurch has joined #openstack-nova05:47
fricklerso I started to fix the live-migration job at https://review.opendev.org/703735 , but a better solution would be to make os-testr work with system pyyaml. the latted is depended on by e.g. cloud-init so it's very hard to remove. or set up using os-testr from within a venv only06:02
frickleralso, has anyone started work to move that job to zuul v3?06:03
*** TxGirlGeek has quit IRC06:06
*** ociuhandu has joined #openstack-nova06:15
*** ociuhandu has quit IRC06:20
*** ratailor has joined #openstack-nova06:28
*** TxGirlGeek has joined #openstack-nova06:36
*** TxGirlGeek has quit IRC06:45
*** vishalmanchanda has quit IRC07:24
*** ivve has quit IRC07:30
*** rpittau|afk is now known as rpittau07:37
*** lpetrut has joined #openstack-nova07:47
*** yaawang has quit IRC07:50
*** slaweq_ has joined #openstack-nova07:59
*** tesseract has joined #openstack-nova08:08
*** maciejjozefczyk_ has joined #openstack-nova08:08
*** tesseract has quit IRC08:09
*** tesseract has joined #openstack-nova08:09
*** bnemec has joined #openstack-nova08:09
*** tkajinam has quit IRC08:10
*** davee_ has quit IRC08:14
*** davee_ has joined #openstack-nova08:14
*** mrch_ has joined #openstack-nova08:16
*** ratailor has quit IRC08:21
*** ratailor has joined #openstack-nova08:25
*** tosky has joined #openstack-nova08:27
*** xiaolin has quit IRC08:30
*** slaweq_ has quit IRC08:33
*** xek_ has joined #openstack-nova08:34
*** mrch has joined #openstack-nova08:35
*** xek has quit IRC08:37
*** ivve has joined #openstack-nova08:37
*** mrch_ has quit IRC08:38
*** ralonsoh has joined #openstack-nova08:51
*** jaosorior has joined #openstack-nova08:59
*** brinzhang has quit IRC09:08
*** alex_xu has joined #openstack-nova09:14
*** mvkr has quit IRC09:23
*** martinkennelly has joined #openstack-nova09:26
*** mvkr has joined #openstack-nova09:37
*** dtantsur|afk is now known as dtantsur09:48
*** maciejjozefczyk_ is now known as maciejjozefczyk10:10
*** derekh has joined #openstack-nova10:13
*** ociuhandu has joined #openstack-nova10:30
*** ociuhandu has quit IRC10:31
*** ociuhandu has joined #openstack-nova10:31
*** damien_r has joined #openstack-nova10:32
*** damien_r has quit IRC10:33
*** iurygregory has quit IRC10:36
stephenfinfrickler: I assume "install everything devstack'y in a virtualenv" is much harder than it seems10:47
stephenfinfrickler: and yes, mriedem has started work moving to zuul v3 and I think sean-k-mooney is continuing that10:47
bauzasstephenfin: gibi: worth looking at an already-approved spec that I could work on in Ussuri ? https://review.opendev.org/#/c/702943/10:51
*** damien_r has joined #openstack-nova10:56
stephenfinbauzas: Sure. Got some downstream release'y stuff to take care of this morning first though10:58
bauzashah10:58
bauzasyour turn10:58
*** pcaruana has joined #openstack-nova11:02
*** dviroel has joined #openstack-nova11:03
*** ociuhandu has quit IRC11:15
*** mkrai_ has quit IRC11:17
*** ociuhandu has joined #openstack-nova11:27
*** ratailor has quit IRC11:30
*** mvkr has quit IRC11:30
openstackgerritJohn Garbutt proposed openstack/nova-specs master: Small fixes to unified limits spec  https://review.opendev.org/70377311:36
*** rpittau is now known as rpittau|bbl11:41
*** ociuhandu has quit IRC11:42
*** mvkr has joined #openstack-nova11:43
*** tbachman has quit IRC11:44
*** ccamacho has joined #openstack-nova11:45
*** mkrai_ has joined #openstack-nova11:55
*** ccamacho has quit IRC11:55
*** ccamacho has joined #openstack-nova11:55
*** yan0s has joined #openstack-nova11:58
*** ociuhandu has joined #openstack-nova12:00
*** udesale_ has joined #openstack-nova12:04
*** udesale has quit IRC12:07
*** ociuhandu has quit IRC12:08
*** ociuhandu has joined #openstack-nova12:09
*** ratailor has joined #openstack-nova12:12
*** ratailor has quit IRC12:12
*** ivve has quit IRC12:12
*** udesale_ has quit IRC12:21
*** udesale has joined #openstack-nova12:21
*** jawad_axd has joined #openstack-nova12:24
*** iurygregory has joined #openstack-nova12:25
*** iurygregory_ has joined #openstack-nova12:29
gibiit seems I need to spend my time today on downstream issues12:30
*** iurygregory has quit IRC12:30
*** iurygregory_ has quit IRC12:32
*** zbr has quit IRC12:34
*** iurygregory has joined #openstack-nova12:34
*** zbr has joined #openstack-nova12:36
*** ivve has joined #openstack-nova12:38
*** iurygregory has quit IRC12:39
*** iurygregory has joined #openstack-nova12:40
*** damien_r has quit IRC12:40
*** zbr has quit IRC12:46
openstackgerritLee Yarwood proposed openstack/nova master: virt: Provide block_device_info during rescue  https://review.opendev.org/70081112:47
openstackgerritLee Yarwood proposed openstack/nova master: libvirt: Add support for stable device rescue  https://review.opendev.org/70081212:47
openstackgerritLee Yarwood proposed openstack/nova master: docs: Add stable device rescue docs  https://review.opendev.org/70083712:47
*** zbr has joined #openstack-nova12:49
*** mkrai_ has quit IRC13:08
*** jaosorior has quit IRC13:12
*** jaosorior has joined #openstack-nova13:12
*** damien_r has joined #openstack-nova13:13
*** ociuhandu has quit IRC13:14
*** xek_ is now known as xek13:15
*** ociuhandu has joined #openstack-nova13:18
*** rpittau|bbl is now known as rpittau13:20
*** ociuhandu has quit IRC13:22
*** mkrai_ has joined #openstack-nova13:22
*** zbr has quit IRC13:26
*** zbr has joined #openstack-nova13:30
openstackgerritStephen Finucane proposed openstack/nova master: Remove 'nova.image.api' module  https://review.opendev.org/70245113:54
openstackgerritStephen Finucane proposed openstack/nova master: WIP: nova-net: Remove unused nova-network objects  https://review.opendev.org/69715613:54
openstackgerritStephen Finucane proposed openstack/nova master: nova-net: Update API reference guide  https://review.opendev.org/70379613:54
*** rcernin has quit IRC14:03
*** ociuhandu has joined #openstack-nova14:18
*** lbragstad has quit IRC14:23
*** links has quit IRC14:23
*** nweinber__ has joined #openstack-nova14:26
*** lbragstad has joined #openstack-nova14:28
*** Liang__ has joined #openstack-nova14:33
*** eharney has joined #openstack-nova14:34
*** ociuhandu has quit IRC14:40
openstackgerritsean mooney proposed openstack/os-vif master: move os-vif-ovs to be a non legacy job.  https://review.opendev.org/70160114:40
openstackgerritsean mooney proposed openstack/os-vif master: Revert "[Follow Up] OVS DPDK port representors support"  https://review.opendev.org/70367214:40
*** ociuhandu has joined #openstack-nova14:41
*** TxGirlGeek has joined #openstack-nova14:51
*** priteau has joined #openstack-nova14:58
*** mkrai_ has quit IRC14:58
*** Liang__ is now known as LiangFang14:59
*** vishalmanchanda has joined #openstack-nova14:59
*** damien_r has quit IRC15:03
efriedsean-k-mooney, gmann: So is the PyYAML thing in n-l-m sorted yet or still busted?15:04
*** LiangFang has quit IRC15:05
openstackgerritsean mooney proposed openstack/nova stable/stein: Remove 'test_cold_migrate_with_physnet_fails' test  https://review.opendev.org/70297115:06
openstackgerritsean mooney proposed openstack/nova stable/stein: Block rebuild when NUMA topology changed  https://review.opendev.org/70297215:06
openstackgerritsean mooney proposed openstack/nova stable/stein: Disable NUMATopologyFilter on rebuild  https://review.opendev.org/70297315:06
openstackgerritsean mooney proposed openstack/nova stable/stein: FUP for in-place numa rebuild  https://review.opendev.org/70297415:06
fricklerefried: busted, need a fix in devstack and ds-gate each15:06
sean-k-mooneyefried: its breaking os-vifs 1 remaining legacy job too15:07
sean-k-mooneyfrickler: i assume ds-gate is installing os-testr or something like that15:07
*** mrch has quit IRC15:07
sean-k-mooneythe non legacy versions seem to be fine but its the installation of os-testr that is trigering PyYAML to be reinstalled15:08
*** jawad_axd has quit IRC15:08
*** jawad_axd has joined #openstack-nova15:09
efriedI can't tell if https://review.opendev.org/#/c/561597/ will fix it temporarily until https://review.opendev.org/#/c/703735/ can be landed.15:09
efriedfrickler: ^ ?15:10
fricklerefried: the former isn't the fix, but the cause of the new failures15:10
*** damien_r has joined #openstack-nova15:10
efriedoh? I was seeing them before that patch landed15:11
efriedI think15:11
fricklerfixes are https://review.opendev.org/703792 and  https://review.opendev.org/#/c/703271/415:11
frickleroh  https://review.opendev.org/#/c/703735/ is the fix, 703271 is just the bottom of that stack15:12
*** ociuhandu has quit IRC15:13
sean-k-mooneyfrickler: i was wondering if a better fix might be to start running devstack with USE_VENV=True15:13
sean-k-mooneythat shoudl prevent conflict with site packages right15:13
efriedfrickler: thanks. Who can approve these?15:14
sean-k-mooneyhowever if we wanted to keep the cross project compatblity checking we might want a USE_SHARED_VENV option too15:14
fricklersean-k-mooney: clarkb made some tests with USE_VENV, I don't think he got it into a working state15:15
sean-k-mooneyit tried it last night and it got pretty far but it failed to start glance15:16
fricklerefried: I pinged some folks in #-qa already, but devstack cores are rare these days.15:16
*** jawad_axd has quit IRC15:16
sean-k-mooneybut yes i have not used it beforfe because its not tested in the gate15:16
efriedfrickler: is there any value to me opening a bug? Or would that just be unnecessary red tape cause now we have to mark commit messages etc?15:17
*** noonedeadpunk has left #openstack-nova15:17
fricklerefried: the patches are in place and seem to work, so I don't see any value in a bug15:17
efriedack15:17
efriedsean-k-mooney: are you tracking the effort to migrate n-l-m to zv3? Or is that gmann? Clearly we're going to keep running into this kind of nonsense, and we've been suffering with the gzip thing.15:18
fricklerunless someone wants to pick up mriedem's task of feeding elastic-recheck15:19
sean-k-mooneyi dont have a bug for that currently. but i can file one15:21
*** Sundar has joined #openstack-nova15:21
*** martinkennelly has quit IRC15:22
sean-k-mooneyi have been tied up with a backport to queens of the in place numab rebuild that i need to get done by friday to do a backport of a feature downstream so i have not had time to work on the live migration job yet15:22
*** tbachman has joined #openstack-nova15:27
*** priteau has quit IRC15:28
*** tbachman has quit IRC15:28
*** martinkennelly has joined #openstack-nova15:28
*** tbachman has joined #openstack-nova15:29
sean-k-mooneyefried: https://bugs.launchpad.net/nova/+bug/186057315:29
openstackLaunchpad bug 1860573 in OpenStack Compute (nova) "Nova legacy jobs should be ported to zuul v3 native jobs" [High,Triaged]15:29
*** TxGirlGeek has quit IRC15:32
*** luksky has joined #openstack-nova15:33
efriedthanks sean-k-mooney15:34
efriedgmann: ^ for your subscribing enjoyment15:35
*** ociuhandu has joined #openstack-nova15:47
*** artom has joined #openstack-nova15:49
*** TxGirlGeek has joined #openstack-nova16:04
*** TxGirlGeek has quit IRC16:06
*** TxGirlGeek has joined #openstack-nova16:07
*** TxGirlGeek has quit IRC16:10
*** ociuhandu has quit IRC16:11
*** TxGirlGeek has joined #openstack-nova16:13
*** ociuhandu has joined #openstack-nova16:15
*** gyee has joined #openstack-nova16:16
gmannefried: ACK.16:16
gmanndevstack change is +A too16:16
*** iurygregory has quit IRC16:16
*** mlavalle has joined #openstack-nova16:18
*** iurygregory has joined #openstack-nova16:19
*** mkrai_ has joined #openstack-nova16:20
*** ociuhandu has quit IRC16:20
*** dtantsur is now known as dtantsur|afk16:23
*** mriedem has joined #openstack-nova16:24
*** yan0s has quit IRC16:25
*** ivve has quit IRC16:28
*** tosky has quit IRC16:31
*** TxGirlGeek has quit IRC16:42
*** mkrai_ has quit IRC16:46
*** luksky has quit IRC16:47
*** TxGirlGeek has joined #openstack-nova16:49
*** bnemec has quit IRC16:51
kashyapsean-k-mooney: Know where is the actual failure here?  - https://zuul.opendev.org/t/openstack/build/ce5c1b08a48348bcad0d27dd05b0d07616:53
kashyapsean-k-mooney: It says "FAILED with status: 2"16:53
* kashyap is trying to wade through the files to find it...16:53
kashyapMaybe this - https://0aa0d36168d68dde4230-9fa499072a9f8bf63e024cc09284603e.ssl.cf5.rackcdn.com/616603/15/check/nova-live-migration/ce5c1b0/job-output.txt16:54
kashyapYep16:54
*** ociuhandu has joined #openstack-nova16:56
efriedkashyap: n-l-m jobs are failing with PyYAML bs.16:56
efriedFixes in devstack and devstack-gate are merging16:57
efriedhttps://review.opendev.org/#/c/703735/ and its dep16:57
*** iurygregory has quit IRC16:57
kashyapefried: Ah, thank you, good sir16:57
*** TxGirlGeek has quit IRC16:58
efriedif you want to see the real failure, you have to look in devstacklog.txt.gz16:58
efriedwhich you have to unzip16:58
efriedwhich is a pita16:58
efriedand will go away once we migrate n-l-m to zuulv316:58
efriedwhich is nontrivial16:59
efriedbut in the works16:59
efriedbut has been for a while16:59
kashyap(Okay, I quoted you on the Nova change.)16:59
kashyapefried: Yeah, that's the "main script" the job-output.txt moans about.  Thank you16:59
efriedbut we've been essentially broken by it almost continuously for a couple of weeks.16:59
*** TxGirlGeek has joined #openstack-nova16:59
kashyapHmm17:00
efriedkashyap: If you have any ability/time to help with that migration, it would be much appreciated.17:01
efriedI've been avoiding digging in because I would be starting off so far behind the curve that by the time I figured out how to get started someone else would (hopefully) already have it figured out.17:01
kashyap(Afraid, not this week, preparing for a work conf on Fri)17:02
efriednot that that would be time wasted for me, but it terms of priorities, I need to be doing other things.17:02
efriedokay, it was worth a shot :P17:02
kashyapefried: Yeah, completely understand17:02
kashyapCan't dig into every mom-n-pop failure :D17:02
kashyapThis channel is logged, /me should mind his language17:03
melwittkashyap: I'm just reminded, we'd appreciate your review on this proposed revert https://review.opendev.org/70359617:03
efriedunfortunately the mom-n-pop failures have been what's killing us, and consuming a bunch of my time.17:03
*** rpittau is now known as rpittau|afk17:03
kashyapmelwitt: Hi, /me clicks17:03
efriedmostly me floundering around trying to find someone who can help with them.17:03
kashyapefried: :-(17:03
kashyapmelwitt: To start with, that commit doesn't even tell why on god's green earth it is trying to revert17:05
* kashyap wades through the comments17:05
melwittkashyap: take that up with sean-k-mooney lol17:05
*** udesale has quit IRC17:05
kashyapI despise "naked commit messages17:05
kashyaps/commit/commit"/17:05
kashyap:D17:05
melwittme too17:05
sean-k-mooneykashyap: it is what you get form the ui by default17:06
kashyapOkay, Sean comments on PS117:06
sean-k-mooneybut i left some comment on the backport then fielded the reviert17:06
kashyapsean-k-mooney: It just doesn't make sense at all to do CPU comparison check on AArch6417:06
sean-k-mooneythat is incorrect17:06
kashyapmelwitt: I documented "why" on the main change17:06
sean-k-mooneywe have the info in /proc/cpuinfo17:06
sean-k-mooneyso we can check the cpu flags and cpu model17:07
kashyapsean-k-mooney: I relied on the expertise on the libvirt dev who wrote that code.  Want to argue with him?17:07
sean-k-mooneysure17:07
kashyapAnd hell, even AArch64 folks *themselves* told that KVM guests are to be run via 'host-passthrough'17:07
sean-k-mooneyyes17:07
kashyaps/told/tell/17:08
sean-k-mooneybut host-passthough means that the guest will see the host cpu flags and model17:08
kashyapYes, so what?17:08
sean-k-mooneyim not arguing that we should not use host-passthough17:08
kashyapThat's the whole point in this case17:08
sean-k-mooneyim am saying when you do its more important to ensur the flags and modle do not change17:08
kashyapmelwitt: sean-k-mooney: Let me quote my message from the main change, since I don't know what people have read or haven't17:08
kashyap[quote]17:08
kashyapSo it doesn't make sense to do CPU compatability check on AArch64.  And the AArch64 folks themselves recommend that the way to run KVM guests on AArch64 is via 'host-passthrough'.17:08
kashyapIt is true that libvirt does not know how to detect host CPU model on AArch64, but even if it _wants_ to know, it cannot, because even the `/proc/cpuinfo` on AArch64 doesn't show anything interesting.  There are lots of vendors making different AArch64 CPUs, and they are not easily comparable.  They all differ in various ways.  (This is also confirmed by Jiri Denemark of libvirt.)17:09
kashyap[/quote]17:09
kashyapsean-k-mooney: Zooming out: what prompted you to revert?17:09
sean-k-mooneykashyap: that may have been true when they look or on a rhel kerenl but /proc/cpuinfo has cpu Flags and the cpu modle name17:10
sean-k-mooneyhowever they have different capitalistation then x8617:10
sean-k-mooneykashyap: i saw the backport and i consider it to be a regerssion17:10
bauzasstephenfin: so, once https://review.opendev.org/#/c/703568/ do we still have gate problems with the functional tests ?17:11
* bauzas was barely paying attention to this chan17:11
sean-k-mooneykashyap: there have been some patches to lscpu to allow it to parse the different way the flags and model are reported on aarch64. i suspect that libvirt just need to have the same change applied to its parsing17:12
sean-k-mooneykashyap: well actully the lscpu patch merged back in 201817:12
kashyapMy brain is starved of food, and my chest is aching after this bizarre bike fall.  So I can't parse you fully yet17:19
kashyapmelwitt: sean-k-mooney What I know we shouldn't merge that revert, IMHO17:19
melwittthanks kashyap17:20
kashyapmelwitt: sean-k-mooney: Until libvirt gets the parsing correct and libvirt/QEMU CPU modelling maintainers give guidance, we should stick with current Nova behaviour.17:20
sean-k-mooneyi dissagree with that but if im being over ruled fine17:21
*** ociuhandu has quit IRC17:22
sean-k-mooneywith the current patch its likely that after a migration if the guess is rebooted the cpu flags and model might change17:22
sean-k-mooneyits also not clear to me if there is a risk of the guest crashign if it trys to use a instuction not supported on the dest host17:23
sean-k-mooneygiven the info regarding cpu model and cpu flags is availabel in /proc/cpuinfo a correct fix in my view would have been to validate those17:24
sean-k-mooneyi walso woudl have expected a workaround config optin for this but im not planing on spending time to code that up17:25
kashyapsean-k-mooney: All this requires extensive testing, and extremely careful audit - we haven't done any of that (yet).  So we go with "solid heuristics".17:27
sean-k-mooneysolid heuristics of check nothing and hope it works?17:28
kashyapThe heuristic here being, "avoid needless checks"17:28
sean-k-mooneywe would not consider it safe to not check cpu compatabily on x86. its just seam wrong to have a lower standard for other archs17:29
sean-k-mooneyanyway i better go back  to backporting17:29
*** evrardjp has quit IRC17:34
sean-k-mooneystephenfin: can you review https://review.opendev.org/#/c/701601 again when you have a chance17:34
*** evrardjp has joined #openstack-nova17:34
stephenfinsean-k-mooney: done17:42
sean-k-mooneystephenfin: thanks17:42
sean-k-mooneystephenfin: do you know if jan is about. he is ment to be moving this week right to start his new job next week17:43
stephenfinbauzas: We shouldn't have, no. The issues are to do with Tempest tests, iirc (something to do with pip not uninstalling pyyaml since it was installed by the package manager)17:43
sean-k-mooneythat is being fix17:44
bauzasall good, will recheck then17:44
sean-k-mooneyor has been fixed17:44
stephenfinnot so fast, I don't think the fix has merged17:44
stephenfinbauzas: https://review.opendev.org/#/c/703735/17:44
sean-k-mooneyyou can add a depends on and then recheck17:44
bauzasoh ok17:45
sean-k-mooneythat was breaking os-vif as well hence why i want to get that os-vif change merged so we nolonger have legacy jobs for it to break17:45
*** TxGirlGeek has quit IRC17:47
*** jawad_axd has joined #openstack-nova17:48
stephenfinah, so that's the dependency17:48
stephenfingtk17:48
*** TxGirlGeek has joined #openstack-nova17:49
*** Sundar has quit IRC17:50
*** jawad_axd has quit IRC17:52
*** martinkennelly has quit IRC17:58
*** derekh has quit IRC18:00
*** eharney has quit IRC18:03
*** jawad_axd has joined #openstack-nova18:08
*** jmlowe has joined #openstack-nova18:10
openstackgerritMerged openstack/nova stable/stein: libvirt: remove conditional on VIR_DOMAIN_EVENT_SUSPENDED_POSTCOPY  https://review.opendev.org/70077318:14
openstackgerritMerged openstack/nova stable/stein: libvirt: check job status for VIR_DOMAIN_EVENT_SUSPENDED_MIGRATED event  https://review.opendev.org/70077418:14
*** eharney has joined #openstack-nova18:15
*** vishalmanchanda has quit IRC18:17
*** jawad_axd has quit IRC18:19
openstackgerritStephen Finucane proposed openstack/nova master: Recalculate 'RequestSpec.numa_topology' on resize  https://review.opendev.org/66252218:31
openstackgerritStephen Finucane proposed openstack/nova master: tests: Cleanup of '_test_resize' helper test  https://review.opendev.org/66424518:31
artomstephenfin, oh, you've picked that up again? ^^18:35
artomIIRC you handed it off to me, and then I looked it, shrugged my shoulders in despair, and never touched it again :/18:36
stephenfinartom: I'm getting hassled downstream for it and figured you didn't have bandwidth, so yeah :)18:36
stephenfinall good18:36
artomYeah, sorry. There was attempt, the Gerrit comments are evidence of that.18:36
sean-k-mooneystephenfin: i can hassel you upstrem for it too if you like18:38
sean-k-mooneyi wanted that to be in 16GA18:38
sean-k-mooneywell in train18:38
sean-k-mooneysame thing18:38
stephenfinsean-k-mooney: https://media0.giphy.com/media/R7IYpzLLMBomk/giphy.gif?cid=790b7611c0d748cc03dc8e8f5456f63a200cd89cd6b5f14f&rid=giphy.gif18:39
sean-k-mooney i think you still being working and only at 18:40 is enough pressue to make you fix anything18:40
*** tesseract has quit IRC18:40
sean-k-mooney/only/online/18:41
stephenfinheh, yeah, I'll be done shortly18:44
artomstephenfin, oh, I remember where I blocked - if we update the request spec with the new numa_topology, but the resize fails in one of a myriad of ways, and we need to revert it18:45
*** tbachman has quit IRC18:45
artomIIRC we talked with dansmith about not persisting the numa_topology at all, and just making sure each request to the scheduler has the correct one18:46
stephenfinartom: Just looked into that. FWICT, we don't revert the RequestSpec.flavor, let alone the RequestSpec.numa_topolology, in the case of a failure18:46
stephenfinSo I need another follow-up to do that18:46
artomstephenfin, ah yeah, the flavor was in the same boat18:46
sean-k-mooneyoh ye are talking about a different bug. i was refering to https://bugs.launchpad.net/nova/+bug/183177118:48
openstackLaunchpad bug 1831771 in OpenStack Compute (nova) "UnexpectedDeletingTaskStateError exception can leave traces of VIFs on host" [Medium,In progress] - Assigned to Matthew Booth (mbooth-9)18:48
sean-k-mooneysorry i saw you being ping about that downstream so assume that was the one you were refering too18:49
openstackgerritEric Fried proposed openstack/nova master: WIP: Add emulated TPM support to Nova  https://review.opendev.org/63136318:52
openstackgerritEric Fried proposed openstack/nova master: Add support for resize and cold migration of emulated TPM files  https://review.opendev.org/63993418:52
efriedgmann: What's the accepted way to add a specialized CI job to nova these days?18:58
sean-k-mooneyefried: are you asking about thrid party or first party18:59
efried1p, I would think18:59
efriedSpecifically, I'm going to need to work something up for vTPM. This is going to mean that the job will need to19:00
efried- run barbican19:00
efried- (compile and?) install special versions of libvirt and qemu19:00
efried- (compile and?) install some custom software19:00
efried- build servers with custom flavors19:00
efried- run some commands via ssh19:00
sean-k-mooneyyou can just defien it in tree in the .zuul.yaml19:00
sean-k-mooneythe job name should start with nova19:00
sean-k-mooneyright19:00
sean-k-mooneyam its on my long todo list but i do plan to add a tempest jobs that does the libvirt/qemu compilation for that devstack plugin19:01
sean-k-mooneythat said next cycle ubuntu 20.04 should ship the ones you need19:02
sean-k-mooneyfor the swtpm sorfware19:02
efriedI don't have until next cycle ;P19:02
sean-k-mooneyi would just use an ansible per-run playbook19:02
efriedI don't know that I care to run actual tempest19:02
efriedUnless the "build servers" and "run some commands" bits need to be done in a tempestuous framework of some kind? A plugin?19:03
efriedjroll: o/19:03
sean-k-mooneyit could19:03
sean-k-mooneybut on the custom flaovr front have you looked at my dpdk job19:03
efriedmy brain goes fuzzy when I see dpdk19:04
gmannefried: you can use zuulv3 native base jobs from devstack if you do not want to run tempest19:04
sean-k-mooneywell dpdk is not important19:04
sean-k-mooneybut you can use a pre-run playbook to create a local.sh file which will create custome flavors19:04
sean-k-mooneye.g. request vtpm19:04
efriedgmann: is there a "making a devstack zuulv3 job for dummies" guide somewhere?19:04
sean-k-mooneythen you can run standard tempest wtih those falvor to test your feature19:05
sean-k-mooneyor a subset of tempest19:05
gmannefried: humm, not guide as such i know but i can link you some example from other project did like Tacker etc19:05
gmannor job description19:05
efriedk. I don't trust nova's .zuul.yaml cause I never know when there's a legacy minefield I'm walking into.19:06
*** ralonsoh has quit IRC19:06
gmann'devstasck' can be used with minimum effort on specific jobs - https://github.com/openstack/devstack/blob/2e45f2c267c9ababdbdfc4c505b329398391c5f9/.zuul.yaml#L35219:07
gmannthis is tacker multinode job for their functional testing - https://github.com/openstack/tacker/blob/bdb2d52b3a1b69c58cb2ac6f903380ab8a7bd973/.zuul.yaml#L2819:07
efriedoh, so it's still kosher to use run.yaml things19:08
efriedthat's a relief.19:08
sean-k-mooney yes19:08
KeithMnemonicmelwitt. did this change break the patch? it is failing on a live migration thing now https://review.opendev.org/#/c/683008/6..7/nova/tests/unit/compute/test_compute.py19:08
gmannmultinode support is in all base jobs of devstack which is based on nodeset used on job19:08
sean-k-mooneyby default we leave it out in most of our jobs because its coming from the parent job19:08
melwittKeithMnemonic: lol no, that's a unit test. the live migration job is failing. we might need to rebase. I'm looking at the failure now19:09
efriedmelwitt: if it's PyYAML, we're just waiting for https://review.opendev.org/#/c/703735/ to merge19:09
melwittunit tests run in the openstack-tox-py27 and openstack-tox-py35 jobs19:09
KeithMnemonicok thank you19:10
melwittefried: this is stable/pike so I doubt it right? the PyYAML is a new thing?19:10
efriedoh19:11
efriedI don't know. Is devstack branchless or something?19:11
sean-k-mooneyefried: here is an example job i need to go update https://review.opendev.org/#/c/679656/12 but it show you how to create a custom job with custom flavor and run standard tempest test to validate thing19:11
melwittgah gzipped logs again19:11
sean-k-mooneyefried: no devstack is branched19:11
melwittefried: devstack has branches but tempest is branchless19:11
sean-k-mooneyyes ^19:11
efriedmelwitt: okay, that failure looks different, ignore me.19:12
melwitthow are these old crusty jobs having the friggin gzipped logs, dang19:12
efriedthanks sean-k-mooney19:12
*** luksky has joined #openstack-nova19:13
efriedoh, yeah melwitt, that's going to continue to be a problem I guess, unless we plan to migrate legacy jobs to zv3 on stable. Much sad face.19:13
efriedwe may have to figure out how to get that turned off in the job itself for stable.19:13
melwittoh geeez :''''''(19:13
sean-k-mooneyam well it should not be19:13
sean-k-mooneyoh actully19:13
efriedI thought it was an infra-level thing.19:14
sean-k-mooneyya it is19:14
efriedso, if we're going to have to figure that out anyway, I guess we might as well do it on master, asap, so we can stop being frustrated at least partially.19:14
sean-k-mooneyso we need to modify devstack-gate to stop compressing the logs internally19:14
sean-k-mooneyand backport that to stable branches19:14
melwittisn't that what you did though? it didn't stop the compression for legacy jobs on master19:15
melwittso even if we backport it, it won't help right?19:15
sean-k-mooneymy fix fixed non legacy jobs19:15
*** TxGirlGeek has quit IRC19:16
sean-k-mooneyi intended it to fix both but it seams that devstack gate is compressing them somewhere else too19:16
sean-k-mooneyor the legacy jobs are19:16
sean-k-mooneyit might not be in devstack gate19:16
melwittgot it19:16
melwittok, now to find where this thing is failing LM19:17
sean-k-mooneyi have been doing " curl <log url> | zcat | lnav -q"19:18
melwittthat's helpful, thanks19:19
*** jmlowe has quit IRC19:21
sean-k-mooneymelwitt: artom was say you can also to "curl <url> | zless" but i like using lnav to browse logs19:21
* artom pills | zzzzz19:22
*** TxGirlGeek has joined #openstack-nova19:22
melwittI still haven't gotten around to trying lnav so I'll use zless for now19:23
sean-k-mooneyya if you do try it by default lnav dumps all the logs to std out so the -q is there to stop that19:23
melwitt\:| [instance: 5bca844b-4ca6-4c63-a579-8f00316da019] Instance spawn was interrupted before instance_claim, setting instance to ERROR state19:24
sean-k-mooneyam that is new19:24
melwittyeah, it's new to me19:24
sean-k-mooneydoes that mean qemu crashed or something?19:25
melwittno idea19:25
sean-k-mooneywell that makes two of us19:25
melwittI don't expect it's related to the patch, and the patch has been sitting around forever so I wouldn't be surprised if it needs a rebase by now. but the nova-live-migration job is failing pretty consistently on it and so far, for unknown reasons19:26
melwittrechecked it like 3 times and always fail on nova-live-migration19:26
sean-k-mooneyi can take a look at it a bit later. what is the review?19:27
sean-k-mooneyonce i fix the osp 15 backport im doing ill take a quick look before moveing to osp 1319:28
melwittsean-k-mooney: it's this one https://review.opendev.org/68300819:28
sean-k-mooneycool i have it open.19:28
melwittnote that it is very old, not rebased since september19:28
artomsean-k-mooney, huh, that's the same thing we saw in whitebox19:29
artomWe thought it was because we were restarting nova-compute to change configs19:29
sean-k-mooneymelwitt: if you do a rebase via the ui i should not hurt19:29
sean-k-mooneybut i dont think that is the issue19:29
sean-k-mooneyzuul will do a merge with master so it should basicaly be the same19:29
melwittyeah, probably worth it to try. it's gonna have to be rebased to merge anyway19:29
melwittlet me do it now19:30
sean-k-mooneywell its more or less the same as a recheck and will avoid the merge commit so it wont hurt19:30
sean-k-mooneyartom: did you fix it in whitebox?19:30
artomsean-k-mooney, by extending the service restart wait delay19:31
artomWhich apparently has nothing to do with it, as we're now seeing the same thing in Nova?19:31
sean-k-mooneywe are not restart services in this job19:31
sean-k-mooneyactully19:31
sean-k-mooneywe might be19:31
openstackgerritmelanie witt proposed openstack/nova stable/pike: Avoid redundant initialize_connection on source post live migration  https://review.opendev.org/68300819:31
artomWait, n-l-m?19:31
sean-k-mooneyi think we do19:31
sean-k-mooneyya19:31
artomWe're changing some configs IIRC19:32
sean-k-mooneyi think there is a hack that swaps the storage to ceph or something19:32
artomSo yeah, we are19:32
sean-k-mooneyi think its in the post run playbook19:32
sean-k-mooneyok its not there19:33
sean-k-mooneyits proably in the test hook19:33
*** jmlowe has joined #openstack-nova19:33
sean-k-mooneyya so here https://github.com/openstack/nova/blob/master/gate/live_migration/hooks/run_tests.sh#L55-L6719:34
artomAh, yeah, configure_and_start_nova19:35
*** maciejjozefczyk has quit IRC19:35
artomAre... are we just going to hax a sleep in there? Before the run_tempest call?19:35
sean-k-mooneyhttps://github.com/openstack/nova/blob/master/gate/live_migration/hooks/ceph.sh#L71-L10019:35
sean-k-mooneywe could hack a sleep here https://github.com/openstack/nova/blob/master/gate/live_migration/hooks/ceph.sh#L11419:36
artomWhy in ceph?19:37
sean-k-mooneythis is where we restart nova after reconfiguring to use ceph19:37
*** gmann is now known as gmann_afk19:38
sean-k-mooneyso in the ligration job we deploy withour ceph intially run tempest then after that we reconfivure the deploymetn for ceph and do more testing19:38
*** jmlowe has quit IRC19:39
*** damien_r has quit IRC19:39
sean-k-mooneyso we only restart the serivce in the ceph teting at the end  here https://github.com/openstack/nova/blob/master/gate/live_migration/hooks/run_tests.sh#L6419:40
*** jmlowe has joined #openstack-nova19:40
sean-k-mooneythat function get loaded form the ceph.sh file here https://github.com/openstack/nova/blob/master/gate/live_migration/hooks/run_tests.sh#L2119:40
*** damien_r has joined #openstack-nova19:42
*** jmlowe has quit IRC19:47
stephenfinsean-k-mooney: Seeing as you're still here, does my comment here make sense https://review.opendev.org/#/c/662522/13/nova/compute/api.py@363719:53
stephenfinchecking it tomorrow is fine too. I am outta here19:53
sean-k-mooneyill check19:56
sean-k-mooney am the conducor calls the schduer19:58
sean-k-mooneyso it could modify the numa toplogy before it calls the select destination function i  think19:58
sean-k-mooneyi would have to check but you are right in that you definetly need to recalulate the numa toployg based on the new flavor before the numa toplogy filter runs19:59
sean-k-mooneymeaining either in the api or in the conductor if the conductor si what is invoking the scheduler.20:00
sean-k-mooneyi dont have that part of code loaded up in my brain right now hence vague answer20:01
*** szaher has quit IRC20:03
*** eharney has quit IRC20:04
*** szaher has joined #openstack-nova20:09
*** jmlowe has joined #openstack-nova20:12
*** gmann_afk is now known as gmann20:18
*** jmlowe has quit IRC20:18
*** TxGirlGeek has quit IRC20:31
*** gentoorax is now known as gentoorax_away20:42
*** gentoorax_away is now known as gentoorax20:42
*** mgariepy has quit IRC20:46
*** panda has quit IRC20:49
*** panda has joined #openstack-nova20:51
*** artom has quit IRC20:52
*** jmlowe has joined #openstack-nova20:55
*** TxGirlGeek has joined #openstack-nova21:01
*** jmlowe has quit IRC21:06
*** slaweq_ has joined #openstack-nova21:07
*** pcaruana has quit IRC21:07
*** eharney has joined #openstack-nova21:23
*** tbachman has joined #openstack-nova21:44
*** rchurch has quit IRC21:49
*** rcernin has joined #openstack-nova21:50
*** rchurch has joined #openstack-nova21:51
*** lucidguy has joined #openstack-nova21:54
lucidguyI'll be very very appreciative if someone can assist me with this, i've spent hours googling etc.  https://paste.ubuntu.com/p/6wqhRX68tr/21:54
*** xek has quit IRC21:54
sean-k-mooneyyou are booting vms with 1TB of ram21:56
sean-k-mooneythat is fun21:56
sean-k-mooneythis looks like a kvm kernel bug21:57
*** TxGirlGeek has quit IRC21:58
*** nweinber__ has quit IRC21:58
*** TxGirlGeek has joined #openstack-nova21:58
lucidguysean-k-mooney: Suggestions?21:59
*** TxGirlGe_ has joined #openstack-nova22:00
sean-k-mooneyubutun 16.04 is getting near the end of its life have you updated to the latest 16.04 kernel available on the host.22:01
sean-k-mooneyits possible this is already fixed if not22:01
sean-k-mooneythis is not an openstack related bug22:01
*** gentoorax has quit IRC22:01
*** gentoorax has joined #openstack-nova22:01
sean-k-mooneyso your best bet is to ralk to the ubuntu kernel folks or reach our to the kvm comunity on irc22:02
sean-k-mooneypersonlly if you are stuck on 16.04 but can upgrade your kernel i would consider using there hardware enabling kernel which tends to be more up to date22:02
*** TxGirlGeek has quit IRC22:03
lucidguysean-k-mooney: We are already using the hwe kernel22:05
sean-k-mooneyactully just re reading this22:07
sean-k-mooneyif you launch the vm with 1TB of ram it start fine22:07
sean-k-mooneyand if you launch it with 1.2TB it fails with this error22:07
lucidguyThats correct22:08
sean-k-mooneyim just wondering if you are hitting a qemu or kvm memory limit22:10
lucidguysean-k-mooney:  That's what I'm thinking but I can't find any documentation stating that22:10
jrollefried: did you have a question for me or want my comments on how we might do that CI?22:12
jroll(or neither?)22:12
sean-k-mooneylucidguy: are you using nested virt by the way22:12
lucidguysean-k-mooney:  How do I confirm that?22:13
sean-k-mooney cat /sys/module/kvm_intel/parameters/nested22:14
lucidguyY22:14
sean-k-mooneyright so in 4.15 nested virt is disable by default in the kernel because tehre were still a few edgcaces that did not work correctly22:15
sean-k-mooneyby kernel 4.19 or so they had been fixed and the upstream kernel default it to Y22:15
lucidguyAre you reading this somewhere?22:16
sean-k-mooneyhttps://bugs.launchpad.net/qemu/+bug/1813165 is a similar bug to yours but in there case they cpu was emulating System Management Mode22:16
openstackLaunchpad bug 1813165 in QEMU "KVM internal error. Suberror: 1 emulation failure" [Undecided,New]22:16
sean-k-mooneythat is not the casue in your trace back as you have SMM=022:16
sean-k-mooneybut they mentione this happend in a nested case22:17
sean-k-mooney*also happend22:17
sean-k-mooneylucidguy: and know i just have been working with nested virt for year and have seeing it improve and break over that time22:17
lucidguySince I'm using HWE, I believe I'm using the same kernal as Ubuntu 18.04.  So people with the latest LTS are still having this issue?22:18
sean-k-mooneyya nested virt in the defaul 18.04 kernel is broken22:18
lucidguyTo be honest, I don't exactly know what "nested" means.22:19
sean-k-mooneyso if that is what the 16.04 hwe kerel is trackin then that is likely the cause22:19
*** amodi has quit IRC22:19
sean-k-mooneylucidguy: it allows you to run kvm in side the vm to have 2+ layers of vms22:20
*** amodi has joined #openstack-nova22:20
lucidguySo should I not use nested?22:20
lucidguyI don't think we have users runing vms within their vms22:21
sean-k-mooneywith that specific kernel proably not22:21
sean-k-mooneybut in general its on by default now but only from 4.19 on i think22:21
lucidguyHmm, now to find out where that is set.22:21
sean-k-mooneysean@pop-os:~$ cat /etc/modprobe.d/qemu-system-x86.conf22:21
sean-k-mooneyoptions kvm_intel nested=122:21
sean-k-mooneychange 1 to 022:21
sean-k-mooneyyou could also downgrae your kernel to the 16.04 non hwe kerenl22:22
lucidguyI don't recall setting this anywhere, you think its on by default?22:22
lucidguyWe have hardware requiring that kernel22:23
sean-k-mooneyit should not be on by defualt on ubuntu 16.0422:23
lucidguyHmm, set in nova somewhere?22:23
sean-k-mooneyno22:23
sean-k-mooneynova does not set this22:23
lucidguyodd22:23
sean-k-mooneyit can be set in two places22:24
sean-k-mooneyeither in a file in /etc/modeprobe.d22:24
sean-k-mooneyor on the kernel command line22:24
lucidguysean-k-mooney:  I have to leave soon, before I forget I just want to thank you for this info22:24
sean-k-mooneyno worries. nested virt would be my best guess but i dont know its defintly that22:24
sean-k-mooneyit is definetly a kenrel bug22:25
lucidguyStill lots more to think about22:25
*** slaweq_ has quit IRC22:25
*** dviroel has quit IRC22:25
*** TxGirlGe_ has quit IRC22:25
lucidguyhave to run.  Thanks again.22:26
sean-k-mooneyno worries o/22:26
sean-k-mooneydoes anyone remember how to enable debug loggin in functinal tests?22:31
sean-k-mooneynevermind i think i found the issue22:43
sean-k-mooneyyep22:43
sean-k-mooneybefore train you should use NUMAHostInfo not HostInfo when you want it to constuct a numa toplogy form the kwargs22:43
sean-k-mooneyi even fixed that in one of the previous patches.22:43
lucidguyback for a few minutes22:56
lucidguysean-k-mooney:  You supporting a large OpenStack production environment?22:56
sean-k-mooneynot directly. i work at redhat on the comptue team so i mainly work upstream but i also support customer when they report bugs downstream22:57
sean-k-mooneyso we have some large cloud deployment that i support indirely but im on the enginerring team rather then support22:58
lucidguyI'm supporting a 600+ hypervisor Queens deployment.22:58
lucidguyI'm betting my boss is going to ask me to upgrade to Train.  Lord help me.22:59
sean-k-mooneywhat do you use for your installer. charms? or do you use something like kolla ansible or osa?22:59
sean-k-mooneyqueens to train is a bit leap but its doable23:00
lucidguyWe install everything from scratch, using custom ansible playbooks23:00
sean-k-mooneyoh ok23:01
lucidguyAre we crazy?23:01
sean-k-mooneyya that makes it more challanging in some ways23:01
sean-k-mooneythat depends23:01
lucidguyBut this way you trully understand how things work.23:01
sean-k-mooneyyep that is the advantage23:01
sean-k-mooneyi would suggest looking at the ansibel roles form OSA23:01
sean-k-mooneyosa being openstack ansibel23:02
sean-k-mooneyto so see if they are of use too you23:02
lucidguyOpenStack ansible popular ehh?23:02
sean-k-mooneyyes23:02
sean-k-mooneyit is the install that vexhost use23:03
lucidguyvexhost?23:03
sean-k-mooneythey are a large public cloud operator that donate ci resouce to the openstck comunity23:03
lucidguyinteresting23:03
sean-k-mooneylucidguy: you shoudl reach out to mnaser23:04
sean-k-mooneyi think he is still the PTL of OSA but they have done a lot to make upgrade simpler23:04
lucidguyDoesn't canonical support OpenStack?23:04
sean-k-mooneyyes they do, they have an installer base on opesntack charms deployed with juju23:05
sean-k-mooneyso if you pay for support with them that is the install they woudl use23:05
lucidguyinteresting23:05
lucidguyI would think large organizations would go with our approach.  Avoid wrappers.23:06
sean-k-mooneyredhat has an openstack distobution that build on top of the triplo project23:06
sean-k-mooneyyou would be surprised23:06
*** tkajinam has joined #openstack-nova23:07
sean-k-mooneysome do if they have the devepolment staff to mainatin it23:07
sean-k-mooneybut its more common to see large companies contibuie and addopt the comuntiy installer23:07
sean-k-mooney*installers23:07
lucidguyJust sounds like a pain to have to troubleshoot another layer of software.23:08
sean-k-mooneywell when that software is built by a group of operators that have really clouds in produciton you would be suprised at how helpful it can be23:10
sean-k-mooneythat said i agree if its a complex installer it can be a pain to debug23:10
sean-k-mooneyso i tend to prefer the simpler ones like devstack and kolla-ansible23:11
sean-k-mooneyjust never run devstack in production...23:11
*** mlavalle has quit IRC23:14
lucidguyugg stupid instance stuck in deleting state.. and virsh on hv not responding FML23:14
sean-k-mooneythat sounds like the host kernel might have hung23:15
lucidguythis is the box I disabled nesting23:16
sean-k-mooneyby the way i hope if you are runing 1TB VM you are using Hugepages for the memory23:16
lucidguyWhatever the default option is.23:16
sean-k-mooneyso no you are not23:16
sean-k-mooneythe reason i mentioned that is it can take a long time for qemu/kvm to release all the mapped memory when you kill it23:17
lucidguyI was just reading those options in nova.conf23:17
sean-k-mooneyso if you are using the decault 4k memory then it might take a while to fully delete the vm23:17
lucidguyWould I not see a load on the system anywhere?23:18
lucidguyI don't even see a qemu process running23:19
sean-k-mooneyyou would see that the memory has not been freed with free -m23:21
sean-k-mooneybut in that case if virsh is not working i would check to see if libvirt is still running23:21
lucidguyIts free23:21
lucidguylibvirtError: failed to connect to monitor socket: No such process23:21
sean-k-mooneyso that mean libvirt tried to connecct to qemu but it failed because it was not running23:22
lucidguyoooo its gone.  So it did take forever.23:22
lucidguyNow you're going to make me research how Hugepages works.  Thanks alot.  heh23:22
*** mriedem has quit IRC23:23
sean-k-mooneyhehe ya they are non trival23:23
sean-k-mooneybut basically it invole preallcoating meory so that it can be handed out in larger chunks23:23
sean-k-mooneynormaly either 2MB or 1G instead of 4k23:23
sean-k-mooneythat signicatly impoves memory performance but it has other implciations23:23
*** TxGirlGeek has joined #openstack-nova23:24
lucidguyWon't the mem be used less efficiently?23:24
sean-k-mooneythe main onces beign non memory over subsription and no live migation suppor until train23:24
sean-k-mooneyno23:24
sean-k-mooneyby using larger page allocation you actully optimeis adress translation23:25
sean-k-mooneythe translation lookaside buffer can only cache a limite number of page translations. if each page is bigger you can cache the adress to more memory23:25
sean-k-mooneyso it can give 30%+ performanc improment if you applciation is memory or latency sensitive23:26
lucidguyTried launching a new intance on that HV without nexting.. instance comes up paused and I can see that same error in libvirt ..  :(23:26
lucidguyWas worth a try.23:27
sean-k-mooneyya sorry it did not work23:27
lucidguyWas so excited about that.  Installing a 5.0 kernel on a 16.04 box in production I don't think is wise23:28
sean-k-mooneyi run 5.4 on my home server based on ubuntu 18.0423:28
sean-k-mooneybut its really something you need to evaluate for your own usecase23:29
lucidguyDid you basically upgrade using this approach? https://www.tecmint.com/upgrade-kernel-in-ubuntu/23:29
sean-k-mooneyno i was lazy and used ukuu the ubuntu kernel update utility23:30
sean-k-mooneyit automates that23:30
sean-k-mooneybut i am running the 5.4 mainline kernel form that ppa23:30
lucidguyohh, theres a cli approach.23:30
sean-k-mooneyhttps://www.omgubuntu.co.uk/2017/02/ukuu-easy-way-to-install-mainline-kernel-ubuntu23:31
sean-k-mooneyagain you proably shoudl not do that in prodcutin but i basically un the latest upstream lts kernel which is 5.4 a the moment23:32
sean-k-mooney5.0 was the previous upstream long life kernel i think23:32
sean-k-mooneyoh the previous long term support was 4.1923:33
lucidguyThings to think about.  Thanks again.  Have to run.  Wife is hating me. heh23:33
sean-k-mooneyhttps://www.kernel.org/category/releases.html23:33
sean-k-mooneyno worries o/23:33
lucidguyI guess I should start by updating my local repo and giving 4.19 a try.  Sadly I'm not optimistic of the outcome.23:34
lucidguyhave a good one23:35
*** damien_r has quit IRC23:39
efriedjroll: we had talked vaguely about you being involved in the development of the CI, so I thought to involve you in that conversation :)23:55

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!