Monday, 2019-03-25

*** luksky has quit IRC00:02
*** sapd1_x has quit IRC00:12
*** stakeda has joined #openstack-nova00:37
*** wolverineav has joined #openstack-nova00:38
*** wolverineav has quit IRC00:42
*** ileixe has joined #openstack-nova00:51
*** wolverineav has joined #openstack-nova00:51
*** tbachman has joined #openstack-nova00:56
*** hongbin has joined #openstack-nova01:05
*** tiendc has joined #openstack-nova01:05
openstackgerritTakashi NATSUME proposed openstack/nova stable/rocky: Replace glance command with openstack command  https://review.openstack.org/63706001:14
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (4)  https://review.openstack.org/57410601:15
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (5)  https://review.openstack.org/57411001:15
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (6)  https://review.openstack.org/57411301:17
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (6)  https://review.openstack.org/57411301:17
*** tetsuro has joined #openstack-nova01:48
gmannefried: melwitt matt, i replied on removing the tempest-multinode-full job ML, review. We should not remove it instead we should make it voting. we are losing the coverage now and potentially in future also when slow marked tests will be made non-slow01:52
*** psachin has joined #openstack-nova01:57
*** Dinesh_Bhor has quit IRC02:07
*** tbachman has quit IRC02:21
*** tbachman has joined #openstack-nova02:25
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (7)  https://review.openstack.org/57497402:30
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (8)  https://review.openstack.org/57531102:30
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (9)  https://review.openstack.org/57558102:30
*** whoami-rajat has joined #openstack-nova02:43
openstackgerritTakashi NATSUME proposed openstack/nova-specs master: Fix warnings in the document generation  https://review.openstack.org/63115002:43
*** tssurya has joined #openstack-nova03:00
*** udesale has joined #openstack-nova03:16
*** hongbin_ has joined #openstack-nova03:21
*** hongbin has quit IRC03:23
*** tssurya has quit IRC03:23
*** elbragstad has joined #openstack-nova03:25
openstackgerritmelanie witt proposed openstack/nova master: Re-enable testing of console with TLS in nova-next job  https://review.openstack.org/64543203:46
*** wolverineav has quit IRC03:54
*** wolverineav has joined #openstack-nova03:56
*** janki has joined #openstack-nova03:56
*** hongbin_ has quit IRC03:59
*** kaiokmo has joined #openstack-nova04:16
kaiokmohi Nova folks. I was wondering if it is possible to change permissions of the directories used by nova to launch new instances (when using local storage on the compute-node)04:23
kaiokmofor example: I have an instance dir which is /var/lib/nova/instances/some_hash/. this directory permissions are 755 and nova:nova (user:group)04:24
*** ileixe has quit IRC04:25
kaiokmoit is possible to change (on config files or something) new directories to be created with 775 instead of 755?04:25
*** wolverineav has quit IRC04:29
*** zhubx has quit IRC04:41
*** zhubx has joined #openstack-nova04:42
*** ileixe has joined #openstack-nova04:46
openstackgerritThomas Bechtold proposed openstack/os-vif master: Drop testtools from test-requirements.txt  https://review.openstack.org/64728604:46
*** wolverineav has joined #openstack-nova04:47
*** sajauddin has joined #openstack-nova05:11
*** ratailor has joined #openstack-nova05:13
*** wolverineav has quit IRC05:21
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (7)  https://review.openstack.org/57497405:29
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (8)  https://review.openstack.org/57531105:30
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (9)  https://review.openstack.org/57558105:31
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (9)  https://review.openstack.org/57558105:31
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (8)  https://review.openstack.org/57531105:31
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (9)  https://review.openstack.org/57558105:32
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (10)  https://review.openstack.org/57601705:32
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (10)  https://review.openstack.org/57601705:32
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (11)  https://review.openstack.org/57601805:33
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (11)  https://review.openstack.org/57601805:33
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (12)  https://review.openstack.org/57601905:34
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (12)  https://review.openstack.org/57601905:34
openstackgerritTony Breeds proposed openstack/nova stable/queens: Document unset/reset wrinkle for *_allocation_ratio options  https://review.openstack.org/64729105:35
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (13)  https://review.openstack.org/57602005:35
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (13)  https://review.openstack.org/57602005:35
openstackgerritTony Breeds proposed openstack/nova stable/queens: Don't persist zero allocation ratios in ResourceTracker  https://review.openstack.org/61327105:35
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (14)  https://review.openstack.org/57602705:36
openstackgerritTony Breeds proposed openstack/nova stable/queens: Update resources once in update_available_resource  https://review.openstack.org/61229405:36
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (14)  https://review.openstack.org/57602705:36
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (15)  https://review.openstack.org/57603105:37
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (15)  https://review.openstack.org/57603105:37
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (16)  https://review.openstack.org/57629905:38
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (16)  https://review.openstack.org/57629905:38
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (17)  https://review.openstack.org/57634405:39
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (17)  https://review.openstack.org/57634405:39
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (18)  https://review.openstack.org/57667305:40
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (18)  https://review.openstack.org/57667305:40
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (19)  https://review.openstack.org/57667605:41
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (19)  https://review.openstack.org/57667605:41
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (20)  https://review.openstack.org/57668905:42
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (20)  https://review.openstack.org/57668905:42
openstackgerritTony Breeds proposed openstack/nova stable/pike: Document unset/reset wrinkle for *_allocation_ratio options  https://review.openstack.org/64729205:42
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (21)  https://review.openstack.org/57670905:43
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (21)  https://review.openstack.org/57670905:43
openstackgerritTony Breeds proposed openstack/nova stable/pike: Don't persist zero allocation ratios in ResourceTracker  https://review.openstack.org/61326305:43
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (22)  https://review.openstack.org/57671205:43
openstackgerritTony Breeds proposed openstack/nova stable/pike: Update resources once in update_available_resource  https://review.openstack.org/61229505:43
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (22)  https://review.openstack.org/57671205:44
*** yonglihe has joined #openstack-nova05:44
*** jaosorior has joined #openstack-nova06:02
*** wolverineav has joined #openstack-nova06:11
*** udesale has quit IRC06:15
*** udesale has joined #openstack-nova06:16
openstackgerritAbhishek Kekane proposed openstack/nova-specs master: Support multiple backend of Glance  https://review.openstack.org/64121006:19
*** udesale has quit IRC06:20
*** udesale has joined #openstack-nova06:20
*** ivve has joined #openstack-nova06:37
*** elbragstad has quit IRC06:45
*** Luzi has joined #openstack-nova06:53
*** owalsh has quit IRC06:54
openstackgerritTakashi NATSUME proposed openstack/nova master: Add a live migration regression test  https://review.openstack.org/64120006:58
openstackgerritTakashi NATSUME proposed openstack/nova master: Add TODO note for mox removal  https://review.openstack.org/57675806:59
openstackgerritTakashi NATSUME proposed openstack/nova master: Add TODO note for mox removal  https://review.openstack.org/57675807:00
*** wolverineav has quit IRC07:00
*** wolverineav has joined #openstack-nova07:01
*** ratailor has quit IRC07:05
*** pcaruana has joined #openstack-nova07:07
*** brinzhang has joined #openstack-nova07:08
*** ratailor has joined #openstack-nova07:09
*** sapd1_x has joined #openstack-nova07:10
*** sridharg has joined #openstack-nova07:18
*** slaweq has joined #openstack-nova07:19
*** dpawlik has joined #openstack-nova07:19
*** alex_xu has quit IRC07:24
*** sapd1_x has quit IRC07:25
*** wolverineav has quit IRC07:34
*** wolverineav has joined #openstack-nova07:35
*** wolverineav has quit IRC07:36
*** wolverineav has joined #openstack-nova07:37
*** oanson has joined #openstack-nova07:37
*** wolverineav has quit IRC07:37
*** owalsh has joined #openstack-nova07:41
*** ileixe has quit IRC07:49
*** alex_xu has joined #openstack-nova07:56
*** jangutter has joined #openstack-nova08:01
*** ccamacho has joined #openstack-nova08:06
*** awalende has joined #openstack-nova08:07
*** tetsuro has quit IRC08:09
*** tesseract has joined #openstack-nova08:10
*** udesale has quit IRC08:14
*** udesale has joined #openstack-nova08:15
*** udesale has quit IRC08:17
*** udesale has joined #openstack-nova08:17
*** luksky has joined #openstack-nova08:18
*** rpittau|afk is now known as rpittau08:22
openstackgerritMartin Schuppert proposed openstack/nova stable/stein: Eventlet monkey patching should be as early as possible  https://review.openstack.org/64731008:22
*** ralonsoh has joined #openstack-nova08:28
*** tosky has joined #openstack-nova08:28
*** tssurya has joined #openstack-nova08:33
*** takashin has left #openstack-nova08:35
*** helenafm has joined #openstack-nova08:36
*** brinzh has joined #openstack-nova08:40
*** Dinesh_Bhor has joined #openstack-nova08:40
*** tkajinam has quit IRC08:42
*** brinzhang has quit IRC08:43
*** wolverineav has joined #openstack-nova08:43
*** zbr has quit IRC08:53
*** wolverineav has quit IRC09:02
*** yikun has joined #openstack-nova09:04
*** wxy-xiyuan has joined #openstack-nova09:07
*** ivve has quit IRC09:10
*** mdbooth_ has joined #openstack-nova09:15
*** xek has joined #openstack-nova09:17
*** mdbooth has quit IRC09:18
*** maciejjozefczyk has joined #openstack-nova09:18
*** zbr has joined #openstack-nova09:20
*** xek has quit IRC09:24
*** IvensZambrano has joined #openstack-nova09:25
*** jonher has quit IRC09:26
*** dtantsur|afk is now known as dtantsur09:32
openstackgerritSurya Seetharaman proposed openstack/nova-specs master: Support adding the reason behind a server lock  https://review.openstack.org/63862909:40
*** xek has joined #openstack-nova09:40
*** derekh has joined #openstack-nova09:43
*** ivve has joined #openstack-nova09:52
*** ttsiouts has joined #openstack-nova10:07
*** wolverineav has joined #openstack-nova10:17
*** ivve has quit IRC10:21
*** erlon has joined #openstack-nova10:22
*** wolverineav has quit IRC10:30
*** jonher has joined #openstack-nova10:37
*** wolverineav has joined #openstack-nova10:39
*** trident has quit IRC10:43
*** stakeda has quit IRC10:48
*** ivve has joined #openstack-nova10:50
*** erlon has quit IRC10:51
openstackgerritBalazs Gibizer proposed openstack/nova master: Add falvor to requested_resources in RequestSpec  https://review.openstack.org/64739610:57
*** ratailor has quit IRC11:02
*** kaiokmo has quit IRC11:02
*** trident has joined #openstack-nova11:08
*** ttsiouts has quit IRC11:11
*** ttsiouts has joined #openstack-nova11:11
*** wolverineav has quit IRC11:14
*** kaiokmo has joined #openstack-nova11:14
*** ttsiouts has quit IRC11:15
*** psachin has quit IRC11:16
*** ivve has quit IRC11:19
*** sapd1_x has joined #openstack-nova11:22
*** rcernin has quit IRC11:31
*** hemna has quit IRC11:32
*** hemna has joined #openstack-nova11:32
openstackgerritMerged openstack/nova-specs master: Replace openstack.org git:// URLs with https://  https://review.openstack.org/64669511:34
*** ttsiouts has joined #openstack-nova11:36
*** luksky has quit IRC11:39
*** shilpasd has joined #openstack-nova11:44
*** xek_ has joined #openstack-nova11:47
*** wolverineav has joined #openstack-nova11:48
*** panda|drappt is now known as panda11:49
*** xek has quit IRC11:49
*** kaiokmo has quit IRC11:55
*** wolverineav has quit IRC11:56
*** xek has joined #openstack-nova11:58
*** xek_ has quit IRC11:59
*** xek_ has joined #openstack-nova12:01
*** xek has quit IRC12:03
*** xek_ has quit IRC12:03
*** helenafm has quit IRC12:03
*** xek has joined #openstack-nova12:04
*** sajauddin has quit IRC12:06
*** xek has quit IRC12:08
*** xek has joined #openstack-nova12:08
*** jroll has quit IRC12:14
*** luksky has joined #openstack-nova12:15
*** jroll has joined #openstack-nova12:15
*** tiendc has quit IRC12:16
*** kaiokmo has joined #openstack-nova12:18
*** whoami-rajat has quit IRC12:24
*** markvoelker has quit IRC12:26
*** lpetrut has joined #openstack-nova12:26
*** logan- has quit IRC12:27
*** logan- has joined #openstack-nova12:31
*** brinzh has quit IRC12:33
shilpasdHi: openstacksdk returning 400 for 'force_service_down' API with version as 2.72, pl refer https://bugs.launchpad.net/ubuntu/+source/python-openstacksdk/+bug/182158412:36
openstackLaunchpad bug 1821584 in python-openstacksdk (Ubuntu) "Compute 'force_service_down' API returns 400 with current version 2.72 " [Undecided,New]12:36
tssuryamelwitt, mriedem: I feel we should fallback to legacy if the queued_for_delete is not migrated and is still NULL like its done for user_id : https://review.openstack.org/#/c/638072/14/nova/objects/instance_mapping.py@38612:36
shilpasdHi All: please confirm the same12:37
*** cdent has joined #openstack-nova12:38
*** edleafe has joined #openstack-nova12:39
*** awaugama has joined #openstack-nova12:57
efriedshilpasd: Thanks for the bug report.12:58
efriedFYI there's a community-wide goal getting set up for Train to try to get more of the CLIs up to parity12:59
efriedIf you have the means, it would be great if you wanted to propose a fix for this.12:59
*** mriedem has joined #openstack-nova12:59
shilpasd<efried> sure13:00
shilpasdefried: sure13:00
sean-k-mooneyefried: in this case its an openstacsdk limitation not a cli issue13:00
efriedsean-k-mooney: Yes, I agree. shilpasd opened the bug against the right component.13:00
sean-k-mooneynova cli and osc do not use the sdk for the api currently13:00
sean-k-mooneyah yes they did13:00
sean-k-mooneyefried: stephenfin and i were talking internally about ho to improve cli partity13:02
sean-k-mooneyefried: we were thinking a phased approch make the most sence. first make osc have partity with nova cli by just delegating to it internall. then port osc to openstack sdk once that is done13:04
*** jmlowe has quit IRC13:04
sean-k-mooneyso form a user point of view we get to cli parity first then we can get teh sdk to partity and swap over to useing it13:04
*** dklyle has joined #openstack-nova13:04
sean-k-mooneybut there are still big gaps in that plan. e.g. should clint only things like nova host-evac be ported and how to deal with micorverions13:05
gansoHi folks. I am about to log a bug and would like to confirm if this is an intentional behavior or not: If an exception is raised by the driver during confirm_migration, the migration record is stuck in confirming state and the allocations are not removed. The instance is fine at the destination in this stage, but the source host has allocations that is not possible to clear without going to the database or invoking13:07
gansothe Placement API via curl. After several migration attempts that fail in the same spot, the source node is filled with these allocations that prevent new instances from being created or instances migrated to this node.13:07
sean-k-mooneyefried: but ya in anycase i do hope we can make progress on that goal in train13:08
*** ivve has joined #openstack-nova13:15
efriedganso: What release are you running?13:16
*** wolverineav has joined #openstack-nova13:16
gansoefried: I tried pike, queens and stein13:16
gansoefried: same problem in all of them ^13:17
efriedganso: Well, that doesn't sound great. mriedem is probably your best bet to say whether this is a known issue. If he doesn't chime in here I think you can safely open a bug.13:18
gansoefried: thanks! I will wait for mriedem's confirmation first.13:19
*** helenafm has joined #openstack-nova13:19
*** takashin has joined #openstack-nova13:19
*** mvkr has quit IRC13:20
mriedemlooking, but i wouldn't be at all surprised13:20
mriedemack on the migration.status not being set to error because the @errors_out_migration_ctx decorator is not used here https://github.com/openstack/nova/blob/926753ee6bebee5bacc29073e123ed5c1a0bb647/nova/compute/manager.py#L393313:21
mriedemso you never get this far https://github.com/openstack/nova/blob/926753ee6bebee5bacc29073e123ed5c1a0bb647/nova/compute/manager.py#L401113:22
mriedemnor do the allocations get cleaned up https://github.com/openstack/nova/blob/926753ee6bebee5bacc29073e123ed5c1a0bb647/nova/compute/manager.py#L401713:22
*** med_ has joined #openstack-nova13:22
mriedemso yes it's a big13:22
mriedemsetting the migration status to error is easy13:22
mriedemknowing whether or not the allocations should be changed is harder13:22
mriedemganso: the instance status goes to ERROR right? https://github.com/openstack/nova/blob/926753ee6bebee5bacc29073e123ed5c1a0bb647/nova/compute/manager.py#L399313:23
gansomriedem: yes the instance goes to error13:23
mriedemwhich means you can't revert the resize after confirm fails13:23
mriedemunless you manually reset the vm_state to 'resized' in the db13:23
mriedemso at this point, the instance is on the dest, the db points the instance at the dest, and confirm fails on the dest and you're stuck in error state,13:24
gansomriedem: I didn't try that. I noticed I could only change the status to either error or active, so I changed the status to active and could use the instance fine after that, even migrate it again.13:24
mriedemi would say we probably just consider the instance is stuck there now and cleanup the allocations13:24
mriedemganso: yeah reset status only changes to active/errror13:24
mriedem*error13:24
*** elbragstad has joined #openstack-nova13:24
mriedemso you could have tried hard rebooting the instance to fix it also since you can do that with an error instance13:24
mriedembut that's not going to cleanup the allocations as you found13:25
*** elbragstad is now known as lbragstad13:25
mriedemganso: anyway, it's definitely a bug13:25
gansomriedem: hmmm seems to me the migration_confirm runs on the source, and fails there. The libvirt driver only cleans up on that method's implementation13:25
mriedemoh right, yeah confirm_resize runs on the source host13:25
mriedemto cleanup the source host13:25
efriedno confirm_resize --force?13:26
efried"I know this thing is copacetic on the destination, make it so"13:26
mriedemprobably another good reason to just cleanup the guest on the hypervisor as best effort but still cleanup the allocations13:26
gansomriedem: thanks! I will log the bug =)13:26
mriedemefried: that would assume you know you need to force it before the instance gets stuck in error status13:26
mriedemyou can't confirm resize on an error instance13:27
efriedThat's what the force would be13:27
mriedemew13:27
efried"I done checked the instance, and it's good. Make it look good in the databases and stuff"13:27
efriedshrug, just spitballing.13:27
mriedemyou can fix it up with a hard reboot13:27
mriedemon the dest13:27
efriedexcept the allocations13:27
*** trident has quit IRC13:27
mriedembut that won't clean the allocations13:27
mriedemright, so what i'm saying is we should suck less and care for where errors can happen in a more granular way13:28
gansoefried, mriedem: yea the main problem are the allocations.13:28
*** irclogbot_2 has joined #openstack-nova13:28
efrieddoes nova manage heal_allocations work on something like this?13:28
mriedemthese giant compute / conductor manager methods are so convoluted that it gets hard to deal with errors in isolation13:28
mriedemand if they should be fatal or not13:28
mriedemefried: no, that only creates missing allocations, doesn't cleanup ones that shouldn't exist13:28
mriedemmnaser has a script for that though13:29
mriedemsec13:29
cdentI'm gonna get a tattoo of [t c6v1]13:29
purplerbot<mriedem> right, so what i'm saying is we should suck less and care for where errors can happen in a more granular way [2019-03-25 13:28:05.178818] [n c6v1]13:29
efriedWhat I'm getting at is, if there's some way to clean up the allocations other than curl'ing placement, I'm less concerned about this than otherwise13:29
*** trident has joined #openstack-nova13:29
mriedemnot built into nova no13:29
mriedemthere are various operator scripts floating around13:29
*** cdent has quit IRC13:31
*** altlogbot_3 has quit IRC13:31
mriedemhttps://bugs.launchpad.net/nova/+bug/179356913:31
openstackLaunchpad bug 1793569 in OpenStack Compute (nova) "Add placement audit commands" [Wishlist,Confirmed]13:32
mriedemthere is a script in there from mnaser and one from larsks about cleaning up allocations in placement based on the nova db13:32
*** altlogbot_3 has joined #openstack-nova13:32
mriedemi can't find the email, but last year i posted to the ML looking for someone to incorporate mnaser's into nova-manage13:33
efriedganso: ^^ :P13:34
gansoefried, mriedem: it would be great if such functionality existed in nova-manage, so the customer can run if they run into this situation.13:36
tssuryamriedem: manser's script: http://paste.openstack.org/show/734146/13:36
efriedganso: Above was me subtly suggesting that you might be interested in making that a reality :)13:36
*** mchlumsky has joined #openstack-nova13:37
tssuryaoh nvm, had a question but got the answer13:37
*** cdent has joined #openstack-nova13:37
*** dklyle has quit IRC13:37
*** tosky has quit IRC13:38
*** irclogbot_2 has quit IRC13:38
gansoefried: on the other hand, it is a workaround for a bug. Once the bug is fixed there shouldn't be a need for the customer to run those scripts. I am not aware of which situations it is acceptable to have stale resources and perform cleanup of them.13:39
mriedemi just re-posted to the ML13:39
*** irclogbot_2 has joined #openstack-nova13:39
efriedganso: Yeah, if we never had bugs, we wouldn't need scripts like this :)13:40
mriedemi'm sure the same problem exists on revert resize13:40
mriedemand lots of other move ops13:40
efriedganso: This won't be the last time we encounter a bug for which this workaround ... yeah, what mriedem said.13:40
mriedemthere is an assumption in these 200 LOC methods that we'll get to the things at the end because everything at the top and middle of the method will pass without error13:41
*** tetsuro has joined #openstack-nova13:41
mriedemeven when we're trying to help https://github.com/openstack/nova/blob/926753ee6bebee5bacc29073e123ed5c1a0bb647/nova/compute/manager.py#L4703 i'm not sure how correct that is now13:42
gansoefried: yup. What I am trying to say is: if such workaround was common and of easy access, perhaps those bugs wouldn't even be considered bugs and wouldn't be reported by customers. Not sure if that's a good route to go.13:42
mriedemresize_instance changes the instance.host/node to the dest machine, and finish_resize then runs on the dest which could fail and if so, will revert allocations13:42
efriedmriedem: Restructure so the critical stuff is in a finally: block?13:42
*** temka is now known as artom13:42
efriedganso: btw, did you figure out what the driver failure was?13:43
efriedmriedem: Are we supposed to be fast-approving the s,git://,https://, patches?13:43
gansoefried: no, unfortunately my customer's logs don't go far back. I was able to find out where it fails because of the migration record in 'confirming' state13:43
mriedemefried: which ones?13:43
efriedmriedem: https://review.openstack.org/#/c/646682/13:44
efriedand brethren13:44
*** BjoernT has joined #openstack-nova13:44
mriedemi guess i haven't been paying attention to the opendev changes13:45
*** mchlumsky has quit IRC13:45
*** belmoreira_ has joined #openstack-nova13:45
mriedemapproved13:46
*** mvkr has joined #openstack-nova13:47
*** belmoreira_ has quit IRC13:47
*** mchlumsky has joined #openstack-nova13:48
mriedemoh god it's on all branches too13:49
*** belmoreira has joined #openstack-nova13:49
mriedemianw will be king of all stats13:49
openstackgerritEric Fried proposed openstack/nova master: s,git://github.com/,https://git.openstack.org/,  https://review.openstack.org/64747213:49
*** belmoreira has quit IRC13:51
mriedemsean-k-mooney: is the kuryr-kubernetes-tempest-daemon-octavia failure in https://review.openstack.org/#/c/646868/ on stable/rocky a known issue?13:52
*** jdillaman has joined #openstack-nova13:53
openstackgerritSylvain Bauza proposed openstack/nova master: Refactor CONTRIBUTING.rst  https://review.openstack.org/64097013:55
bauzasstephenfin: I'd appreciate some doc-nits ;)13:55
mriedemganso: let me know when you have a bug posted and i can at least fix the migration.status = 'error' thing quickly13:55
bauzasstephenfin: oops, https://review.openstack.org/64097013:55
mriedembauzas: unrelated, but for you https://review.openstack.org/#/c/646006/13:55
bauzasmriedem: ack, will look13:56
gansomriedem: https://bugs.launchpad.net/nova/+bug/182159413:56
openstackLaunchpad bug 1821594 in OpenStack Compute (nova) "Error in confirm_migration leaves stale allocations and 'confirming' migration state" [Undecided,New]13:56
gansomriedem: thanks!13:56
*** jmlowe has joined #openstack-nova14:00
*** munimeha1 has joined #openstack-nova14:04
efriedthanks ganso14:05
*** hongbin has joined #openstack-nova14:06
mriedemi need to email claudiub about https://review.openstack.org/#/c/543971/14:07
*** ivve has quit IRC14:11
*** mlavalle has joined #openstack-nova14:12
sean-k-mooneymriedem: sorry was on 1:1 will check thatreview now14:14
sean-k-mooneymriedem: we made kuryr-kubernetes-tempest-daemon-octavia non-voting on master and kuryr removed it a few weeks ago so im not surpised that it failed14:16
sean-k-mooneymriedem: it looked like it failed becasue the devstack-plugin-container tried to install linux kernel package that are not found on the repos anymore14:20
sean-k-mooneyit looks like it was installin kernel 4.4.0 packages which would correspond to ubuntu 16.0414:20
sean-k-mooneyif this ran on ubunut bionic then it would explain why it was not found14:20
sean-k-mooneyactully its a  ubuntu-xenial node i would guess the package is just not in te repo anymore14:21
*** hamzy_ is now known as hamzy14:22
*** ivve has joined #openstack-nova14:23
openstackgerritMerged openstack/nova-specs master: Fix warnings in the document generation  https://review.openstack.org/63115014:28
sean-k-mooneymriedem: ill propose the backport of making that non voting to the sable branches14:33
openstackgerritMerged openstack/nova master: Update contributor guide for Train  https://review.openstack.org/64558114:34
mriedemthanks14:34
*** tetsuro has quit IRC14:38
*** wolverineav has quit IRC14:39
mnaserbtw, I raised this on the mailing list .. I dunno how release-critical this can be considered considering it's been a long time bug -- http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004206.html14:43
*** N3l1x has joined #openstack-nova14:54
*** awalende has quit IRC15:00
*** sridharg has quit IRC15:00
*** beekneemech is now known as bnemec15:00
*** awalende has joined #openstack-nova15:00
*** takashin has left #openstack-nova15:01
*** whoami-rajat has joined #openstack-nova15:01
*** awalende has quit IRC15:04
*** Luzi has quit IRC15:05
*** cfriesen has joined #openstack-nova15:06
*** tbachman has quit IRC15:07
openstackgerritsean mooney proposed openstack/os-vif stable/rocky: make kuryr-kubernetes-tempest-daemon-octavia non voting  https://review.openstack.org/64750015:09
sean-k-mooneymriedem: that will do it for rocky ^ but i need to check project-conifg for older branches15:10
openstackgerritBalazs Gibizer proposed openstack/nova master: Add falvor to requested_resources in RequestSpec  https://review.openstack.org/64739615:10
openstackgerritBalazs Gibizer proposed openstack/nova master: Add flavor to requested_resources in RequestSpec  https://review.openstack.org/64739615:11
*** sapd1_x has quit IRC15:13
sean-k-mooneyactully no never mind15:13
sean-k-mooneywe have zuul config in repo for older release se just do not run that job15:13
*** tbachman has joined #openstack-nova15:15
openstackgerritMatt Riedemann proposed openstack/os-vif stable/rocky: Replace openstack.org git:// URLs with https://  https://review.openstack.org/64686815:16
*** dklyle has joined #openstack-nova15:20
openstackgerritMerged openstack/python-novaclient stable/stein: Replace openstack.org git:// URLs with https://  https://review.openstack.org/64707515:22
*** tssurya has quit IRC15:24
*** zhubx has quit IRC15:26
*** zhubx has joined #openstack-nova15:28
*** zhubx has quit IRC15:28
*** zhubx has joined #openstack-nova15:29
*** zhubx has quit IRC15:30
*** zhubx has joined #openstack-nova15:32
openstackgerritMerged openstack/os-vif master: Replace openstack.org git:// URLs with https://  https://review.openstack.org/64686715:32
*** tssurya has joined #openstack-nova15:32
*** lpetrut has quit IRC15:32
*** itlinux has quit IRC15:37
*** wolverineav has joined #openstack-nova15:37
openstackgerritMatt Riedemann proposed openstack/nova master: Overwrite RequestSpec.ignore_hosts during evacuate  https://review.openstack.org/64751215:37
openstackgerritMatt Riedemann proposed openstack/nova master: Do not persist RequestSpec.ignore_hosts  https://review.openstack.org/64751315:37
mriedembauzas: cfriesen: dansmith: ^ fixes that super latent bug15:37
cfriesenmriedem: nice.  will take a look.15:39
mriedemonly took 2+ years15:39
*** BjoernT_ has joined #openstack-nova15:40
mriedemi can't wait until my next "don't persist field x in request spec" adventure15:41
*** BjoernT has quit IRC15:42
mriedemi guess i need to squash the 2nd and 3rd changes anyway...doing that15:45
bauzasmriedem: nice15:48
bauzasmriedem: once I'm done with some internal meeting + the vgpu docs, you're next in the queue15:49
*** kaisers has quit IRC15:50
*** idlemind has quit IRC15:50
openstackgerritMatt Riedemann proposed openstack/nova master: Add functional regression test for bug 1669054  https://review.openstack.org/64600615:52
openstackbug 1669054 in OpenStack Compute (nova) "RequestSpec.ignore_hosts from resize is reused in subsequent evacuate" [Medium,In progress] https://launchpad.net/bugs/1669054 - Assigned to Matt Riedemann (mriedem)15:52
openstackgerritMatt Riedemann proposed openstack/nova master: Do not persist RequestSpec.ignore_hosts  https://review.openstack.org/64751215:52
*** udesale has quit IRC15:55
cfriesenfound a grammar bug in the commit message for https://review.openstack.org/#/c/64751215:55
cfriesenmriedem: ^15:55
cfriesensee review15:55
openstackgerritSylvain Bauza proposed openstack/nova master: Remove expiremental note in the VGPU docs  https://review.openstack.org/64751815:56
openstackgerritSylvain Bauza proposed openstack/nova master: Add doc on VGPU allocs and inventories for nrp  https://review.openstack.org/64751915:56
bauzasmriedem: you could be interested in ^15:56
openstackgerritMatt Riedemann proposed openstack/nova master: Do not persist RequestSpec.ignore_hosts  https://review.openstack.org/64751215:59
mriedemcfriesen: done15:59
dansmithwow a grammar nit in a mriedem patch15:59
*** cdent has quit IRC16:00
*** xek has quit IRC16:02
openstackgerritSylvain Bauza proposed openstack/nova master: Add doc on VGPU allocs and inventories for nrp  https://review.openstack.org/64751916:02
*** xek has joined #openstack-nova16:08
openstackgerritMerged openstack/python-novaclient stable/queens: Replace openstack.org git:// URLs with https://  https://review.openstack.org/64707316:09
*** wolverineav has quit IRC16:09
mriedembauzas: a few nits in that top docs patch but otherwise really nice16:09
openstackgerritBalazs Gibizer proposed openstack/nova master: Add flavor to requested_resources in RequestSpec  https://review.openstack.org/64739616:09
gibimriedem: regarding your patch about prefiltering for multiattach capable nodes. I tried to make your first approach (request group) work by creating request group for the flavor resource too ^^16:11
openstackgerritMerged openstack/python-novaclient stable/rocky: Replace openstack.org git:// URLs with https://  https://review.openstack.org/64707416:12
openstackgerritMerged openstack/python-novaclient stable/ocata: Replace openstack.org git:// URLs with https://  https://review.openstack.org/64707116:12
mriedemgibi: seems kind of gross to have to call a new helper method in conductor for all move operations16:12
openstackgerritMerged openstack/python-novaclient stable/pike: Replace openstack.org git:// URLs with https://  https://review.openstack.org/64707216:13
mriedemi guess it's not all move ops16:14
gibimriedem: I tried to hook into the RequestSpec.flavor property setter but property setter doesn't seem to work on ovos16:15
gibimriedem: there are another problem noted in the commit message. The numbering of the request groups are lost during the process16:16
mriedemso if someone is resizing with a flavor that has numbered request groups in it, we could lose that16:17
mriedemand break something later16:17
mriedembecause we don't persist requested_resources16:17
mriedemright?16:17
gibimriedem: we are not loosing the group we are loosing the number used in the flavor extra_spec for a given group16:18
dansmithsurely we don't want to persist requested_resources16:18
gibimriedem: besically the patch renumbers each group when generating the a_c query16:18
dansmithsince those could change in format or structure across releases16:18
gibidansmith: I agree16:18
mriedemgibi: isn't the flavor group number coming from the flavor extra specs? which are persisted in RequestSpec.flavor.extra_specs16:18
mriedemdansmith: i'm not so sure here, persisting things in request spec has really helped us out thus far......16:19
gibimriedem: yes. The goal of this patch to create RequestGroup ovos from the flavor16:19
dansmithmriedem: heh16:19
dansmiththe resources in the flavor *are* structural and fixed, but the full set that we calculate from the flavor and other requirements (i.e. from the image, etc) shouldn't be persisted I think16:19
gibimriedem: there is no place currently in the RequestGroup to store it's ident16:20
*** imacdonn has quit IRC16:21
*** imacdonn has joined #openstack-nova16:22
*** helenafm has quit IRC16:23
*** luksky has quit IRC16:23
mriedemgibi: i'm not sure what that means for this16:24
mriedemwhat is the ident? requester_id? or just the group number?16:24
mriedemindex?16:24
mriedemrequest groups baffle me which is why i've deprioritized that multiattach patch :)16:24
gibithe group number from the flavor.extra_spec16:24
mriedemi thought that was baked into the extra spec key name?16:25
mriedemresources1 etc16:25
gibithe flavor create can use resourceN where N is a positive number16:25
gibiand that N ends up in the a_c query16:25
gibibut the current patch renumbers the groups16:25
gibiit will be 1,2,3,... in the a_c query16:26
openstackgerritMerged openstack/nova master: Replace openstack.org git:// URLs with https://  https://review.openstack.org/64668216:26
openstackgerritMerged openstack/nova stable/stein: Replace openstack.org git:// URLs with https://  https://review.openstack.org/64668816:26
mriedemgibi: ok so i guess the question is does that matter as long as the groups remain....grouped16:26
*** ivve has quit IRC16:26
gibithey remain grouped. So it only hardens the troubleshooting16:27
*** panda is now known as panda|ko16:27
openstackgerritSurya Seetharaman proposed openstack/nova-specs master: Support server power state update through external event  https://review.openstack.org/63613216:30
*** ttsiouts has quit IRC16:32
*** igordc has joined #openstack-nova16:32
*** igordc has quit IRC16:32
*** ttsiouts has joined #openstack-nova16:32
openstackgerritSurya Seetharaman proposed openstack/nova-specs master: Support server power state update through external event  https://review.openstack.org/63613216:34
*** cdent has joined #openstack-nova16:37
*** ttsiouts has quit IRC16:37
melwittmriedem: I was wondering re: counting quotas, since we're doing a blocker migration for user_id this cycle, does that mean we don't need to check whether it's populated and fall back to legacy counting anymore? or do we still need to?16:49
*** gyee has joined #openstack-nova16:50
mriedemmelwitt: i think the blocker migration missed stein so it has to be in U now16:51
mriedembut probably a better question for dansmith16:51
mriedemdoing the blocker migration right away in Train seems overly aggressive16:51
*** tssurya has quit IRC16:52
dansmithmelwitt: if we do a blocker, then yes that's what that means, but if we're going to be a little softer about it, then we'd need to handle the compat16:52
melwittmriedem: ok, yeah I wasn't sure how that usually works. I was thinking since we landed all of the migration code in stein, then the blocker migration might only be related to that16:52
dansmithgenerally we do a blocker so we can drop support for something16:52
dansmithand doing that right after we opened the window would be rather aggressive as mriedem said16:52
melwittoh, I see. yeah, then T would be too early16:52
mriedemi think trying to drop the compat in the same release that we add the new code that depends on that compat seems aggressive16:53
dansmithand remember,16:53
dansmithblocker migrations are a pain for FFU people, so we should use them sparingly for when we need to fully drop support for something vs. just avoiding some compat code16:53
dansmithlike if we need to drop a column or something16:53
*** janki has quit IRC16:54
melwittoh, ok :/ might have to amend the spec in that case16:54
melwitt(since it mentions a blocker migration)16:54
dansmithI'm not saying we can't (I don't remember what the spec says), I'm just saying we should be judicious in our application of that technique16:55
melwittthe spec says blocker migration for being able to remove compat code/stop legacy counting16:55
melwittunderstood16:55
dansmithright, so, when we remove that code, we should have a blocker, so depending on how the spec words it, it may not be wrong :)16:56
melwitt(although we have to keep legacy counting indefinitely until partitioning of placement allocations is possible)16:56
dansmithokay16:56
dansmithwe could also do it a different way and just roll the blocker and new constraints together in one migration, but we definitely need to give some buffer between adding the thing and requiring the thing I thnk16:57
melwittyeah, understood and agreed16:58
*** igordc has joined #openstack-nova16:58
cdentmelwitt: speaking of partitioning placement allocations. Is that a thing you were planning to spec or is that a broader all of us kind of thing?17:01
melwittcdent: broader thing17:01
cdentor "dunno" is of course a reasonable answer17:01
cdent17:02
*** jhinman has joined #openstack-nova17:08
melwittmriedem, stephenfin, gmann: fyi, I have changes proposed for re-enabling testing of console with TLS in nova-next https://review.openstack.org/#/q/topic:bug/1819794+status:open17:11
*** Sundar has joined #openstack-nova17:11
* stephenfin clicks17:11
gmannmelwitt: thanks.17:11
sean-k-mooneycdent: is partioning placemetn allocation the "owner thing"17:12
* sean-k-mooney reads scollback17:12
cdentsean-k-mooney: it's basically a way of saying "this allocation of VCPU is from this thing (which happens to be nova X)"17:13
cdentwhich is somewhat different from the resource provider allocation, which is supposed to be a way of saying "these rps below to cloud X"17:13
cdent(which I think is something jaypipes has been thinking about, if I remember right)17:13
sean-k-mooneycdent: oh its partioning in the sense of multiple nova sharing the same placment17:14
cdentsean-k-mooney: not necessarily. there could be other things that consume vcpu17:14
cdentwhich may or may not be a nova17:15
sean-k-mooneysure but i thin this started as an edge usecase.17:15
cdentbut as you can see there's a lot of overlap and ambiguity here, which is why it needs a bit more drive and discussion17:15
sean-k-mooneyya17:15
*** dustinc has joined #openstack-nova17:15
cdentyes, it started as an edge usecase, with two different models for the distribution: one placement many clouds, or one placement many novas but same keystone17:16
sean-k-mooneycdent: what are the other consumer of vcpu beyond nova out of interest?17:16
cdentI don't know17:16
cdentI'm not too savvy about either of these use cases, just have heard people mention them17:16
cdentfrom my standpoint, until somebody steps up a bit more, they aren't yet real17:16
cdentjust speculative stuff to think about in the back of the mind17:16
sean-k-mooneyi guess maybe zun? but i would have asumed it had its only RP17:16
melwittto be clear, I didn't mention it because it's a pressing issue right now, just to note that there's another larger reason why we wouldn't be able to remove quota usage counting compat code than just a blocker migration17:17
* cdent nods17:17
cdentIt does seem like the sort of thing where if there was somebody who had the cycles to make it go, it would be a good thing to have17:18
cdentbut until then...17:18
jhinmanI'm trying to get an instance up with ovs-dpdk. but the vif doesn't get exposed because of this code:        vifs_to_expose = {vif.address: vif for vif in vifs     if ('tag' in vif and vif.tag) or     vlans_by_mac.get(vif.address)}17:19
sean-k-mooneycdent: having the list of usecasue for the feature would be a good starting point. im not entirly sure that the usecsue we all vaguly recall someone talking about at some point are actully the same feature or should be :)17:19
openstackgerritMatt Riedemann proposed openstack/nova master: Error out migration when confirm_resize fails  https://review.openstack.org/64754617:20
sean-k-mooneyjhinman: where is that code ?17:20
cdentsean-k-mooney: yeah, it is a bit vague17:20
jhinmanthe code is in /virt/libvirt/driver.py17:20
jhinmanwhere does the  tag come from?17:21
sean-k-mooneyjhinman: what release are you running17:21
sean-k-mooneyvifs_to_expose is not in that file on master17:22
* jaypipes reads back17:22
*** rpittau is now known as rpittau|afk17:22
jhinmanrocky release17:22
sean-k-mooneyjhinman: its not there on rocky either are you deploying a downstream version of openstack17:23
jhinmanI'm deploying kolla-ansible, so whatever that container has17:23
sean-k-mooneyjhinman: kolla-ansible has several modes. are you usign ubuntu source vs cento binary17:24
openstackgerritSylvain Bauza proposed openstack/nova master: Add doc on VGPU allocs and inventories for nrp  https://review.openstack.org/64751917:25
jhinmanubuntu17:25
sean-k-mooneyjhinman: the tag i think is the interface tagging feature where you can associate a generic name to an interface and look it up in the metadata service17:25
jhinmanbut how does the tag get assigned? is it something passed from neutron. or maybe the tag is not the problem? is there supposed to be a vlan associated17:27
sean-k-mooneyits passed in by the user on nova boot. it is not related to the neutron segmentation id17:27
sean-k-mooneyits a value like "wan" or "lan"17:27
efriedstephenfin: Are we waiting to merge https://review.openstack.org/#/c/645991/ ?17:28
sean-k-mooneyso this is the code that is failing https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L9284-L928617:28
sean-k-mooneylooks like we just merged somthing17:29
sean-k-mooneyhttps://github.com/openstack/nova/blob/0dfbcd74642b16432b800b51f304a89d762e3ff1/nova/virt/libvirt/driver.py#L9290-L929217:29
*** dtantsur is now known as dtantsur|afk17:30
sean-k-mooneyjhinman: there should be nothing ovs-dpdk specific in that code. it shoudl be totally generic17:30
sean-k-mooneyjhinman: actully if that is the code that is runnign that should not run for vhost-user interfaces17:34
jhinmanultimately, it ends up with line 9204:  LOG.debug('No VIF found with MAC %s, not building metadata',                       dev.mac_addr)17:35
sean-k-mooneythe section i linked if for sriov17:35
*** wolverineav has joined #openstack-nova17:35
sean-k-mooneyjhinman: can you provide a paste of the trackback on paste.openstack.org17:37
sean-k-mooneyvifs_to_expose = {vif.address: vif for vif in vifs17:37
sean-k-mooney                          if ('tag' in vif and vif.tag) or17:37
sean-k-mooneyvlans_by_mac.get(vif.address)}17:37
sean-k-mooneyis in the sriov code path and should not be called when handeling vhost-user17:37
*** mvkr has quit IRC17:37
sean-k-mooneywell unless we use that fucntion to do generic dispatch to the others. lets see where is it called17:39
sean-k-mooneyactully so yes that is how it is working17:39
sean-k-mooneywe get the interface metadata here17:39
sean-k-mooneyhttps://github.com/openstack/nova/blob/0dfbcd74642b16432b800b51f304a89d762e3ff1/nova/virt/libvirt/driver.py#L931017:39
sean-k-mooneyjhinman: we emiit that debug message when the user does not specify any device role tags17:41
sean-k-mooneyso its not a error to see that in the logs17:41
openstackgerritElod Illes proposed openstack/nova stable/pike: Fix incompatible version handling in BuildRequest  https://review.openstack.org/64755717:42
*** wolverineav has quit IRC17:42
sean-k-mooneyjhinman: this code is for this spec https://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/virt-device-role-tagging.html are you having a specic  issue or did you jsut see that debug message and were trying to figure out how to scilance it?17:43
jhinmanallright, I was looking at that because I was going back from another error: I can't find any reason for qemu not to have permission to write the socket:  Failed to connect socket /var/run/openvswitch/vhu7a90d3cd-d7: Permission denied17:45
sean-k-mooneyjhinman: the socket error can happen for two reasons. first apparmor can block it, that should not be an issue with rocky but it was in the past17:46
sean-k-mooneysecond /var/run/openvswitch need to be writabel by the user that qemu is running with17:46
jhinmanI disable apparmor17:46
jhinmanbut nova is the user of qemu, so should have permission for anything on the instances, right?17:47
sean-k-mooneyqemu and nova need to be runign in the same group17:47
sean-k-mooney*qemu and ovs17:47
*** wolverineav has joined #openstack-nova17:48
*** ivve has joined #openstack-nova17:48
sean-k-mooneyjhinman: on rocky qemu should be acting as teh vhost-user server and will create the vhost-user socket17:49
sean-k-mooneyas such qemu need to have write permission to the /var/run/openvswith directory that is owned by ovs17:49
jhinmanso I need to add qemu to the ovs group?17:51
sean-k-mooneyjhinman: this should all be done by kolla ansible17:51
openstackgerritMerged openstack/nova stable/queens: Replace openstack.org git:// URLs with https://  https://review.openstack.org/64668517:53
openstackgerritMerged openstack/nova stable/ocata: Replace openstack.org git:// URLs with https://  https://review.openstack.org/64668317:53
sean-k-mooneyjhinman: its been a few years since i implented the support in kolla-ansibel so i cant remember of the top of my head how i fixed this issue17:54
jhinmanI think I remember a patch for qemu.conf, to set user to nova. but I think its in the nova group. is there a common group?17:54
sean-k-mooneyjhinman: this is where the contain is created https://github.com/openstack/kolla-ansible/blob/stable/rocky/ansible/roles/ovs-dpdk/handlers/main.yml#L56-L7617:56
*** cdent has quit IRC17:57
sean-k-mooneywe are not setting a user in the yaml or in teh command using su no17:57
sean-k-mooneyhttps://github.com/openstack/kolla-ansible/blob/stable/rocky/ansible/roles/ovs-dpdk/templates/ovsdpdk-vswitchd.json.j217:57
sean-k-mooneyso i think that means ovs woudl be running as root maybe17:58
jhinmannot obvious to me what you see, but I'll study it17:59
sean-k-mooneyqemu is running as nova17:59
sean-k-mooneyhttps://github.com/openstack/kolla-ansible/blob/stable/rocky/ansible/roles/nova/templates/qemu.conf.j217:59
*** derekh has quit IRC18:00
jhinmanyes, so how to give it permission to access ovs's file?18:00
sean-k-mooneyso nova would have to have write permission to /var/run/openvswitch18:00
sean-k-mooneyya18:00
jhinmansean: in order to get hostconfig stuff working, I added a new start-ovs script, overriding the embedded script. Is that the right way, or can the commands be added to the script in the tools directory (ovs-dpdkctl.sh)?18:04
sean-k-mooneybefore or after this issue18:06
openstackgerritMatt Riedemann proposed openstack/nova master: Delete allocations even if _confirm_resize raises  https://review.openstack.org/64756618:06
jhinmanif you have a quick answer. I could submit a patch for you to review18:06
sean-k-mooneysure its simpler to anwer questiosn on a review but i would proably put it here https://github.com/openstack/kolla/blob/master/docker/ovsdpdk/ovsdpdk/extend_start.sh18:07
dansmithmriedem: you should be okay to backport a default= change on an object field It hink18:07
mriedemthat affects the version of the object doesn't it?18:08
dansmithmriedem: it shouldn't.. it has nothing to do with the wire format18:08
sean-k-mooneymriedem: technicall i think it wont casue our ovo tests to fail as the filde dont change and the default value is not considered part of teh field type18:09
dansmithmriedem: some remote host could not specify a value and then break if a different default is chosen, but that'd be pretty silly18:09
sean-k-mooneyjhinman: oh wait its already here https://github.com/openstack/kolla/blob/master/docker/ovsdpdk/ovsdpdk-vswitchd/extend_start.sh18:10
dansmithmriedem: I'm not saying you need to change your patch, but if you want to and/or it's better, then I think you're in the clear18:11
mriedemdansmith: ok i guess i was thinking of takashi's change here https://review.openstack.org/#/c/641200/3/nova/objects/request_spec.py but he's also setting nullable=True on network_metadata18:11
mriedemso maybe i got confused18:11
dansmithmriedem: yeah, nullable is fo' sho' a problem18:11
*** xek_ has joined #openstack-nova18:11
mriedemfo real fo sho?18:11
sean-k-mooneymriedem: nullable will change the db schma for the column18:11
dansmithsean-k-mooney: no it won't18:12
mriedemwas just about to say ^ :)18:12
mriedemexact words18:12
sean-k-mooneywell it requires you too chagne it right18:12
dansmithno18:12
sean-k-mooneyno18:12
dansmithwe have many fields which intentionally have different nullability for the db and object18:12
dansmithincluding one we just did for the quota stuff18:12
sean-k-mooneyallowing an object to have a nullable field that was previousl not nullable does not require the db to allow it to be null?18:13
sean-k-mooneyohok18:13
dansmithnot necessarily18:13
dansmithtotally depends on the thing18:13
*** xek has quit IRC18:14
* dansmith steps away for a few18:14
jhinmansean: that doesn't affect the instance's socket perms, does it?18:15
sean-k-mooneyjhinman: its not he socket perms that is the issue18:16
sean-k-mooneyqemu is createing the socket so it will be the owner and will have read and write permissions18:16
sean-k-mooneyovs is runnign as root18:16
sean-k-mooneyso the issue is the permission on the directory18:16
sean-k-mooneynova need read write permission to create the unix socket18:17
sean-k-mooney777 should give all users and groups read wite permission to create files there18:17
jhinmanbut that script has been there all along18:20
sean-k-mooneyjhinman: we bind mount the host /run into both the nova-libvirt and ovs vswtichd container18:20
sean-k-mooneycan you check the permission on the host18:21
sean-k-mooneyls -al /run/openvswitch/18:21
jhinmanok, will do. co-worker just told me she has it working on master branch, so something got fixed18:22
sean-k-mooneyjhinman: perhaps but none of this code has change in well over 8 month and most is 2+ years old18:22
sean-k-mooneyjhinman: that said i wrote most of the ovs-dpdk code in kolla so im not surpised if there are bugs :)18:23
jhinmanhost has 777 on /run/openvswitch18:24
jhinmanI thought the log is saying that it's creating a socket in the VM18:26
*** itlinux has joined #openstack-nova18:26
*** luksky has joined #openstack-nova18:26
sean-k-mooneyno its creating a socket for the vm. not in the vm.18:26
jhinmana socket in nova-compute?18:26
sean-k-mooneyits created on the host by qemu i recent release. it was previously created by ovs and connected to by qemu in old releases18:27
sean-k-mooneythe socket wil be create in the nova-libvirt container which also has the same directory bind monted shared form the host18:27
*** xek_ has quit IRC18:27
sean-k-mooneyjhinman: https://github.com/openstack/kolla-ansible/blob/stable/rocky/ansible/roles/nova/defaults/main.yml#L1618:27
*** xek has joined #openstack-nova18:27
jhinmanok. I'll figure it out. thanks for your help!18:28
sean-k-mooneysorry i couldnt help more. i shoudl really test that code again but i have not been working on kolla for about 18 months so i havent really been aroudn to take care of it18:29
sean-k-mooneyjhinman: if you have issue im also on the #openstack-kolla channel so feel free to ping me there not to bother the nova folks. if its not specific feel free to ping me here18:30
*** betherly has joined #openstack-nova18:32
*** xek has quit IRC18:32
*** betherly has quit IRC18:37
*** tesseract has quit IRC18:44
*** dustinc is now known as dustinc|away18:44
openstackgerritsean mooney proposed openstack/nova-specs master: add spec for image metadata prefiltering  https://review.openstack.org/64757818:53
mnaserwould it be ok to add https://review.openstack.org/#/c/645352/ to the rc2 list? and https://review.openstack.org/#/c/641907/ ?18:56
*** ivve has quit IRC18:57
sean-k-mooneymnaser: oh that the fix for the null issue you were looking at last week?18:59
*** wolverineav has quit IRC19:01
mnasersean-k-mooney: correct, the first one is that, the second one is Oslo.service doing a full restart of the service instead of reload, which breaks some assumptions nova does19:01
mnaserwhich means reloading to refresh info leaves you in a broken state19:01
*** betherly has joined #openstack-nova19:02
sean-k-mooneymnaser: right i brifly skimed that thread on the mailing list19:02
sean-k-mooneyoh so that was how this was getting to None in the first place19:02
*** cdent has joined #openstack-nova19:03
mnasersean-k-mooney: yeah I could see it in the DB going from "NULL" (sql null) to "null" (son null)19:03
sean-k-mooneyor rather how self._bdm_obj.connection_info was19:03
mnaserjson*19:03
*** jmlowe has quit IRC19:03
*** betherly has quit IRC19:07
sean-k-mooneymnaser: by the way on the olso service thing my intiall reaction was make oslos reload not call stop and start but i have no idea what other effect that would have19:08
*** gbarros has quit IRC19:08
sean-k-mooneymnaser: but that is more have sane names for things then because it definetly the right thing to do19:08
openstackgerritsean mooney proposed openstack/nova-specs master: re add for train  https://review.openstack.org/64758119:10
openstackgerritsean mooney proposed openstack/nova-specs master: forward ported form stien  https://review.openstack.org/64758219:15
sean-k-mooneymriedem: do ^ need to go back through full review or do can they be fast approved. i litrally just copied them updated the history footer? i know we are still focusing on RC2 but im hoping we can land that code before the ptg or m119:17
sean-k-mooneymriedem: i know we want to talk about openlab for the numa testing at the ptg but just said i would ask19:18
efriedsean-k-mooney: If they were approved in stein, and they're verbatim (except the footer and s/stein/train/i) then they can be fast approved.19:19
sean-k-mooneyefried: ya they are19:20
efriedsean-k-mooney: However, I would request that you make some reference to the actual blueprint being proposed in the commit title and message body.19:20
melwittmnaser: are they regressions? I think we're only doing regression fixes for RC219:20
efriedsean-k-mooney: those titles are going to kill me19:20
sean-k-mooneysure :)19:20
efriedthanks19:21
sean-k-mooneyi was just going for dinner and wanted to push something19:21
efriedcool19:21
efriedif you need to run, I can edit and fast approve.19:21
*** tssurya has joined #openstack-nova19:21
sean-k-mooneyill fix them later. should i add them to the metting aggenda?19:21
melwittsean-k-mooney: instructions, you need the Previously-approved in the commit message https://specs.openstack.org/openstack/nova-specs/readme.html#previously-approved-specifications19:21
sean-k-mooneymelwitt ah perfect thanks19:22
efriedsean-k-mooney: You mean for the PTG? Unless there's something more to be discussed on them, I wouldn't think so.19:22
efriedsean-k-mooney: I guess they will come up in a "what do we prioritize for train" discussion, but that'll be fed by whatever's in the train approved blueprint list at the time anyway.19:22
sean-k-mooneyefried: no i wasnt sure if i was ment to add fast approavl spec to the nova team meeting agenda19:22
sean-k-mooneyill just do what the doc says19:23
*** Sundar has quit IRC19:23
efriedoh, yeah, that won't be necessary. I (or someone) will push them as soon as they conform to what melwitt linked above.19:23
sean-k-mooneyefried: cool in that case ill fix them up and upload them later tonight19:24
efriedsean-k-mooney: ++19:24
mnasermelwitt: no both are long standing upgrade bugs afaik so yeah19:25
mriedemmnaser: i've got a todo to try and recreate that first one with an in-tree functional test, which shouldn't take me long19:29
mriedemidk about that oslo.service one - note that would require a release freeze exception on oslo.service and a minimum required version of oslo.service bump in nova (maybe that'd be optional though)19:29
mnaserwell, I think we need to come to consensus on if the issue is in Oslo service or nova.19:32
mnaserImho it’s Oslo service cause then what’s the point of sighup if you’re gonna stop and start...19:32
dansmithmnaser: I've lost context here, but is there anything nova can do to _not_ be fully torn down and reset?19:32
dansmithbecause I thought not, based on how we get started and managed from oslo19:33
dansmithas it is, a "systemctl restart nova-compute" is much better than the behavior we're getting from HUP, IMHO19:34
mnaserdansmith: based on my understanding it looks like Oslo service never really provides an API to handle HUP signals.19:34
dansmithmnaser: you mean it grabs HUP itself, but doesn't do what a HUP signal should really do19:35
dansmithand, if so, I agree :)19:35
mnaserExactly. It calls reload but only after calling stop and start after so that’s a bit useless at that point.19:35
dansmithright19:36
mnaserI think the most portable potential fix is adding a keyword argument to the stop() function call which includes sighup=bool19:36
dansmiththat doesn't seem like a reasonable status quo to me, which means I think it's an oslo.service bug, not a "nova should be doing something different" scenario19:36
efriedI agree with that19:36
mnaserYes. I think Nova is doing the right thing as well.19:36
dansmithefried: agree with which?19:36
mnaserNothing except reload() should be called on SIGHUP.19:37
efrieddansmith: `it's an oslo.service bug, not a "nova should be doing something different" scenario`19:37
dansmithefried: ack19:37
efriedAnd we've got stuff documented that is supposed to happen to nova on HUP19:37
dansmithright19:37
efriedwhich currently does happen, but is worthless because it destroys the process19:37
dansmithyarp19:37
efriedstuff I have the confidence to say in IRC, but not on the ML19:38
efriedbut I have been watching that thread with interest19:38
mnaserSo my review here solved this but “changed” existing behaviour ... https://review.openstack.org/#/c/64190719:38
mnaserSo is it a bug fix or behaviour change. Up for debate.19:38
efriedit can be both19:39
dansmiththe only argument not to do that would be to keep the existing behavior because it's always been broken, but that leaves us unable to resolve our issue19:39
mnaserBut it looks like nova is a heavy user of sighup and I can’t get other projects to talk about their usage. But it looks like neutron is broken because it makes the same (norms) assumption19:39
dansmithwhich does not seem reasonable19:39
*** _alastor_ has joined #openstack-nova19:39
efriedZane's comment is valid, though. The first time I heard of SIGHUP for openstack it was in the context of mutable config options. So if the "fix" makes some config options not mutable, that's a problem.19:40
*** wolverineav has joined #openstack-nova19:40
dansmithefried: I don't think it has anything to do with that19:40
dansmiththe only thing that would be impacted are things that you only look at on service start19:40
efriedlike RPC settings?19:40
dansmithhowever, those kinda by definition shouldn't be mutable, or you need to specifically handle the case where they have changed19:40
dansmithefried: right, db connection and rpc connection have always been "these can't be mutable"19:41
dansmithbecause it's unlikely people are going to handle them properly (as exposed here)19:41
efriedOkay. Can you respond to Zane in https://review.openstack.org/#/c/641907 ?19:41
dansmithI can, but I don't really want to.. he's also not asserting that it makes sense to say that,19:42
dansmithhe's just coming up with some guess19:42
dansmithoh,19:42
dansmithI see his latest one19:42
dansmiththere, I said things19:45
mnaserI'll try to keep following up on things and get it to land, I just don't know how back portable these things can be19:45
*** wolverineav has quit IRC19:45
*** ccamacho has quit IRC19:55
openstackgerritChris Dent proposed openstack/nova master: Delete the placement code  https://review.openstack.org/61821519:55
*** jhinman has quit IRC19:58
*** jmlowe has joined #openstack-nova20:00
*** wolverineav has joined #openstack-nova20:02
*** wolverineav has quit IRC20:07
*** whoami-rajat has quit IRC20:11
*** betherly has joined #openstack-nova20:11
mriedemmnaser: there should definitely at least be a "fixes" release note in that oslo.service change if it's changing behavior but fixing a long-standing bug in HUP handling20:12
mriedemrelated to your "I just don't know how back portable these things can be" comment20:12
mriedemgenerally don't want to backport changes in behavior, but if we have a good reason to, let's make sure there is a release note20:12
mnasermriedem: ok, ill wait for zane's comments and try to write up a release note that explains how critical (and how it was pretty much broken in every project I've inspected)20:15
*** betherly has quit IRC20:16
mriedemmnaser: dansmith: efried: i've also dumped some thoughts in there20:17
*** wolverineav has joined #openstack-nova20:17
mriedemtrying to compromise but give operators a switch20:17
mriedemwhich could also be backportable20:17
*** cdent has quit IRC20:18
mriedemessentially add a [workarounds] style option to oslo.service20:19
*** itlinux has quit IRC20:20
*** zbr has quit IRC20:22
*** pcaruana has quit IRC20:23
*** tosky has joined #openstack-nova20:23
*** zbr has joined #openstack-nova20:23
*** itlinux has joined #openstack-nova20:27
*** xek has joined #openstack-nova20:33
openstackgerritMerged openstack/os-vif master: Drop testtools from test-requirements.txt  https://review.openstack.org/64728620:42
*** Sundar has joined #openstack-nova20:44
*** ralonsoh has quit IRC20:57
mriedemmnaser: i wrote a functional test for bug 1821244 but can't recreate the issue20:57
openstackbug 1821244 in OpenStack Compute (nova) "Failed volume creation can result in invalid `connection_info` field" [Medium,In progress] https://launchpad.net/bugs/1821244 - Assigned to Mohammed Naser (mnaser)20:57
efriedmriedem: Some bp questions if you have a mo20:57
mriedemmnaser: i'll post it quick and see if you can poke holes in the test20:57
mriedemefried: i have to run real quick, but should be back before 520:57
efriedmriedem: k, I'll leave this here for you:20:58
efried1) Why doesn't https://blueprints.launchpad.net/nova/+spec/add-locked-reason show up in https://blueprints.launchpad.net/nova/train ?20:58
efried2) Why can't I edit Series goalZ?20:58
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: A functional test for bug 1821244  https://review.openstack.org/64760320:58
openstackbug 1821244 in OpenStack Compute (nova) "Failed volume creation can result in invalid `connection_info` field" [Medium,In progress] https://launchpad.net/bugs/1821244 - Assigned to Mohammed Naser (mnaser)20:58
mriedemefried: i've noticed that sometimes (1) happens and i just have to reset the series and save it then it does, which i just dod20:59
mriedem*did20:59
mriedemso refresh https://blueprints.launchpad.net/nova/train20:59
mriedemefried: you probably can't edit series goals b/c you're not a nova driver team member https://launchpad.net/~nova-drivers20:59
efriedah, you changed it from "proposed for train" to "accepted for train"20:59
mriedemoh20:59
mriedemoh maybe tssurya had set the series goal which was 'proposed'21:00
mriedemefried: now see if you can do #221:00
mriedemhttps://launchpad.net/~nova-drivers21:00
efriedwhich isn't the same thing as approving the bp, which is an awkward distinction that's unnecessary for us.21:00
efriedokay...21:00
efriedmriedem: yup, thanks.21:01
efriedyou may go now21:01
openstackgerritMerged openstack/python-novaclient master: Replace openstack.org git:// URLs with https://  https://review.openstack.org/64707021:02
tssuryamriedem, efried: err yea I meant "propose for train" I am not sure why it says accepted21:03
efriedtssurya: It's possible you can only say "proposed" and we have to say "accepted".21:03
efriedBecause apparently "proposed" doesn't show up in the useful dashboard, it only shows up in the useless ones, or if you happen to know the exact url.21:03
efriedLaunchpad woes21:04
efriedtssurya: as stated above ("useless distinction") that doesn't mean the bp is approved for train. It just means it... uhh... shows up instead of now showing up?21:05
tssuryaefried: should I just unset it or something ? still its strange I did the same for https://blueprints.launchpad.net/nova/+spec/nova-support-instance-power-update21:05
tssuryaand that looks okay21:05
tssuryaits "proposed"21:06
efriedtssurya: But it doesn't show up in https://blueprints.launchpad.net/nova/train21:06
efriedso let me fix it21:06
efriednow it does21:06
tssuryaah thanks21:07
efriedthis leaves me with a problem though21:07
efriedI need a way of finding blueprints in "proposed for train" status.21:07
*** betherly has joined #openstack-nova21:07
efriedRight now I can only chance upon them, like happened here.21:07
*** awaugama has quit IRC21:07
tssuryahaha, I always assumed for some reason the bp's get accepted only *after* the spec gets merged21:08
tssuryabut guess all bp's don't have specs21:08
*** betherly has quit IRC21:11
*** tssurya has quit IRC21:15
*** mdbooth has joined #openstack-nova21:17
*** mdbooth_ has quit IRC21:19
melwittefried: there's a link at the bottom of the page https://blueprints.launchpad.net/nova/train that says "have been proposed"21:24
efriedmelwitt: AHA, THANK you.21:35
efriedI was all digging into the lp API, which appears to bear no relation to what it's documented as being.21:38
*** betherly has joined #openstack-nova21:39
*** betherly has quit IRC21:44
*** xek_ has joined #openstack-nova21:46
*** xek__ has joined #openstack-nova21:47
*** xek has quit IRC21:49
*** xek_ has quit IRC21:50
*** itlinux has joined #openstack-nova21:54
openstackgerritMatt Riedemann proposed openstack/nova master: Do not persist RequestSpec.ignore_hosts  https://review.openstack.org/64751221:56
openstackgerritMatt Riedemann proposed openstack/nova stable/queens: Update instance.availability_zone during live migration  https://review.openstack.org/64762321:58
*** wolverineav has quit IRC22:02
*** mchlumsky has quit IRC22:02
*** wolverineav has joined #openstack-nova22:04
*** wolverineav has quit IRC22:08
*** mlavalle has quit IRC22:08
*** betherly has joined #openstack-nova22:11
*** BjoernT_ has quit IRC22:12
openstackgerritMatt Riedemann proposed openstack/nova stable/queens: Update instance.availability_zone during live migration  https://review.openstack.org/64762322:13
*** wolverineav has joined #openstack-nova22:13
*** rcernin has joined #openstack-nova22:14
*** betherly has quit IRC22:16
*** munimeha1 has quit IRC22:20
*** ivve has joined #openstack-nova22:25
openstackgerritEric Fried proposed openstack/nova master: docs: Dedupe controller install guides  https://review.openstack.org/63871522:53
openstackgerritEric Fried proposed openstack/nova master: docs: Dedupe compute install guides  https://review.openstack.org/63871622:53
*** IvensZambrano has quit IRC22:58
openstackgerritMatt Riedemann proposed openstack/nova stable/pike: Update instance.availability_zone during live migration  https://review.openstack.org/64763022:58
*** tkajinam has joined #openstack-nova23:01
*** tkajinam has quit IRC23:01
*** tkajinam has joined #openstack-nova23:02
openstackgerritMatt Riedemann proposed openstack/nova master: Error out migration when confirm_resize fails  https://review.openstack.org/64754623:03
openstackgerritMatt Riedemann proposed openstack/nova master: Delete allocations even if _confirm_resize raises  https://review.openstack.org/64756623:03
*** mriedem has quit IRC23:03
*** erlon has joined #openstack-nova23:12
openstackgerritMerged openstack/nova master: Clean up block_device_allocate_retries config option help  https://review.openstack.org/64175923:24
openstackgerritMerged openstack/nova master: Set min=0 for block_device_allocate_retries option  https://review.openstack.org/64177023:24
openstackgerritMerged openstack/nova master: Remove expiremental note in the VGPU docs  https://review.openstack.org/64751823:24
*** stakeda has joined #openstack-nova23:41
*** Sundar has quit IRC23:53
*** xek__ has quit IRC23:54

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