Thursday, 2018-08-30

*** brinzhang has joined #openstack-nova00:06
*** Sundar has quit IRC00:12
*** efried1 has joined #openstack-nova00:50
*** efried has quit IRC00:51
*** efried1 is now known as efried00:51
openstackgerritMerged openstack/nova master: [placement] Make _ensure_aggregate context not independent  https://review.openstack.org/59748600:52
*** efried has quit IRC00:58
openstackgerritMerged openstack/nova master: Add explanatory prefix to post_test_perf output  https://review.openstack.org/59185001:05
openstackgerritMerged openstack/nova master: Add trait query to placement perf check  https://review.openstack.org/59262401:12
openstackgerritMerged openstack/nova master: Restart scheduler in TestNovaManagePlacementHealAllocations  https://review.openstack.org/59757101:12
openstackgerritMerged openstack/nova master: reshaper: Look up provider if not in inventories  https://review.openstack.org/58503301:12
*** imacdonn has quit IRC01:19
*** alex_xu has joined #openstack-nova01:19
*** imacdonn has joined #openstack-nova01:19
*** efried has joined #openstack-nova01:20
*** gyee has quit IRC01:22
*** jiapei has joined #openstack-nova01:23
*** hongbin has joined #openstack-nova01:54
*** jamesdenton has quit IRC01:59
*** slaweq has joined #openstack-nova02:11
*** slaweq has quit IRC02:16
*** psachin has joined #openstack-nova02:50
*** Dinesh_Bhor has joined #openstack-nova03:17
openstackgerritMerged openstack/nova master: Make get_allocations_for_resource_provider raise  https://review.openstack.org/58459803:28
openstackgerritMerged openstack/nova master: api-ref: fix volume attachment update policy note  https://review.openstack.org/59648903:28
*** jiapei has quit IRC03:33
*** dave-mccowan has quit IRC03:38
*** nicolasbock has quit IRC03:40
*** moshele has joined #openstack-nova04:00
moshelemelwitt: hi04:00
moshelemelwitt: did I answer you question on https://review.openstack.org/#/c/595592? It an old legacy bug that was revealed because tripleo started to config th rx/tx queues be default04:02
*** moshele has quit IRC04:04
*** janki has joined #openstack-nova04:05
*** moshele has joined #openstack-nova04:25
*** markvoelker has joined #openstack-nova04:34
*** ivve has joined #openstack-nova04:47
*** hongbin has quit IRC04:56
*** moshele has quit IRC04:59
openstackgerritTakashi NATSUME proposed openstack/nova master: Fix a failure to format config sample  https://review.openstack.org/59798605:08
*** slaweq has joined #openstack-nova05:11
*** tojuvone has joined #openstack-nova05:12
*** slaweq has quit IRC05:15
openstackgerritTakashi NATSUME proposed openstack/nova stable/rocky: Fix a broken conf file description in networking doc  https://review.openstack.org/59798705:20
*** ccamacho has joined #openstack-nova05:38
*** tetsuro has joined #openstack-nova05:53
*** udesale has joined #openstack-nova05:53
*** moshele has joined #openstack-nova05:54
*** openstackgerrit has quit IRC06:07
*** udesale has quit IRC06:07
*** udesale has joined #openstack-nova06:08
*** openstackgerrit has joined #openstack-nova06:21
openstackgerrithuanhongda proposed openstack/nova master: [WIP]Forbidden non-admin user to list deleted instances  https://review.openstack.org/59801206:21
*** alexchadin has joined #openstack-nova06:23
*** janki has quit IRC06:30
*** jchhatbar has joined #openstack-nova06:30
*** hoonetorg has quit IRC06:39
*** dklyle has quit IRC06:43
*** adrianc has joined #openstack-nova06:43
*** dklyle has joined #openstack-nova06:44
*** hoonetorg has joined #openstack-nova06:46
*** hshiina has quit IRC06:47
*** luksky11 has joined #openstack-nova06:47
*** tetsuro has quit IRC07:02
*** alexchadin has quit IRC07:04
*** alexchadin has joined #openstack-nova07:04
*** alexchadin has quit IRC07:05
*** tetsuro has joined #openstack-nova07:06
*** slaweq has joined #openstack-nova07:11
*** pcaruana has joined #openstack-nova07:14
*** slaweq has quit IRC07:16
*** rcernin has quit IRC07:20
*** rtjure has quit IRC07:20
*** maciejjozefczyk has joined #openstack-nova07:20
*** slaweq has joined #openstack-nova07:23
*** Dinesh_Bhor has quit IRC07:34
*** Luzi has joined #openstack-nova07:35
*** Dinesh_Bhor has joined #openstack-nova07:35
*** janki has joined #openstack-nova07:43
*** jchhatbar has quit IRC07:44
*** sahid has joined #openstack-nova07:48
*** jchhatbar has joined #openstack-nova07:49
*** janki has quit IRC07:49
*** jpena|off is now known as jpena07:54
*** hoonetorg has quit IRC07:55
openstackgerritMerged openstack/nova stable/rocky: Fix a broken conf file description in networking doc  https://review.openstack.org/59798707:56
*** cdent has joined #openstack-nova07:59
*** maciejjozefczyk has quit IRC08:02
*** maciejjozefczyk has joined #openstack-nova08:03
bauzasgood morning Nova08:18
* bauzas is back after 3 weeks off08:18
*** tetsuro has quit IRC08:20
*** tetsuro has joined #openstack-nova08:22
*** sahid has quit IRC08:23
openstackgerrithuanhongda proposed openstack/nova master: Fix instance delete stuck in deleting task_state  https://review.openstack.org/59808408:24
*** Dinesh_Bhor has quit IRC08:25
*** sahid has joined #openstack-nova08:25
*** Dinesh_Bhor has joined #openstack-nova08:27
gibibauzas: welcome back08:29
bauzasgibi: thanks08:29
* bauzas is just depiling his emails, so please ping me directly if you want me to review some stuff08:32
*** Bhujay has joined #openstack-nova08:37
*** markvoelker has quit IRC08:38
*** luksky11 has quit IRC08:41
openstackgerritRong Han proposed openstack/nova master: Reset global variable after unit test is completed.  https://review.openstack.org/59808808:42
*** ttsiouts has joined #openstack-nova08:43
*** donghm has left #openstack-nova08:48
*** dtantsur|afk is now known as dtantsur08:49
*** panda is now known as panda|rover08:52
lyarwoodbauzas: welcome back o/08:55
bauzaslyarwood: thanks08:55
lyarwoodbauzas: https://review.openstack.org/#/q/topic:bug/1787606 - would you mind sticking that on your review queue if you have time today or tomorrow?08:55
dpawlikHello, which rules from policy.json are used by placement api? I have an another role for admin and its raising me an error on compute host that "ailed to retrieve resource provider tree from placement API for UUID 573c492d-7387-4a3a-b21c-20ce531eb483. Got 403: {"errors": [{"status": 403, "request_id": "req-50ecb39c-8bea-4f52-85f2-7b92db9ae9cf", "detail": "Access was denied to this resource.\n\n admin required  ", "title"08:56
dpawlik: "Forbidden"}]}.08:56
lyarwoodafter rm -rf'ing all of your emails obviously08:56
bauzaslyarwood: today could be difficult but I can try08:56
lyarwoodbauzas: yeah no rush08:56
bauzaslyarwood: rm -rf is one option, the other involves reading08:56
gibisean-k-mooney, melwitt: fyi, we are planning to show some demo on the PTG about the state of the bandwidth work  http://lists.openstack.org/pipermail/openstack-dev/2018-August/134015.html08:56
lyarwoodbauzas: both are WIP I just wanted to get some input on the bug and potential fix08:56
dpawlikproblem is that I changed in policy.json file that admin_api is role:my_role08:56
bauzaslyarwood: I'm not sure which one is the best08:56
dpawlikbut its not working on queens08:56
lyarwoodbauzas: ^_^ rm -rf every time08:57
lyarwoodbauzas: if it's that important people will send another email08:57
bauzasand wait for others yelling at you that you haven't replied them ? That could work08:57
kashyapYeah, "selective reading" is the way to taming e-mail.09:01
* kashyap pretty aggressively filters ("mark as read")out based on how coherently one writes.09:01
kashyapThe more meandering a message, the faster it gets marked as read.09:01
*** holser_ has joined #openstack-nova09:02
*** holser_ has quit IRC09:02
*** holser_ has joined #openstack-nova09:03
*** maciejjozefczyk has quit IRC09:05
*** dpawlik has quit IRC09:06
*** maciejjozefczyk has joined #openstack-nova09:06
*** dpawlik has joined #openstack-nova09:07
*** takashin has quit IRC09:09
*** markvoelker has joined #openstack-nova09:13
*** markvoelker has quit IRC09:15
openstackgerrithuanhongda proposed openstack/nova master: Fix instance delete stuck in deleting task_state  https://review.openstack.org/59808409:15
*** sambetts|afk is now known as sambetts09:18
*** luksky11 has joined #openstack-nova09:18
*** priteau has joined #openstack-nova09:20
*** maciejjozefczyk has quit IRC09:21
*** tetsuro has quit IRC09:23
*** udesale has quit IRC09:26
*** maciejjozefczyk has joined #openstack-nova09:31
*** maciejjozefczyk has quit IRC09:32
*** takashin has joined #openstack-nova09:34
*** takashin has left #openstack-nova09:34
*** ccamacho has quit IRC09:39
*** ccamacho has joined #openstack-nova09:39
*** adrianc has quit IRC09:46
stephenfinbauzas: Welcome back. Here's a nice, easy (low priority) review to get you started https://review.openstack.org/#/c/530924/09:51
* bauzas opening a new tab09:52
sean-k-mooneygibi: oh cool i look forward to seeing it09:52
*** alexchadin has joined #openstack-nova09:57
*** kosamara has quit IRC10:01
*** cdent has quit IRC10:02
*** kosamara has joined #openstack-nova10:03
Dinesh_Bhorsean-k-mooney: Hi, May I have your 5 min?10:04
sean-k-mooneyDinesh_Bhor: hi am sure what can i help with?10:04
Dinesh_Bhorsean-k-mooney: we have a quota for instances currently. Actually we have some hypervisors which are specifically dedicated for "Rich VM"  so we want to have separate quota for normal VM's and Rich VM's per project.10:06
Dinesh_Bhorsean-k-mooney: do you think its a good idea to submit a blueprint for this? Or can it be managed somehow with metadata's?10:07
Dinesh_BhorOr something else may be10:07
sean-k-mooneyDinesh_Bhor: this is similar to premptiable instances. in that case we also had the idea of two classes of instance that may have different sla's10:08
*** maciejjozefczyk has joined #openstack-nova10:08
sean-k-mooneyDinesh_Bhor: so if you were to submit a blueprint for this it may be worth trying to adress that usecase also so its a more general solution.10:09
sean-k-mooneyDinesh_Bhor: that said the rich vms10:09
sean-k-mooneyis there richness determined by the host they land on or is it an aspect of the flavor10:09
sean-k-mooneye.g. certin flavor you would like to have a seperate quota for.10:10
*** maciejjozefczyk has quit IRC10:10
*** deepak_mourya_ has joined #openstack-nova10:11
sean-k-mooneyDinesh_Bhor: submitting a blueprint that clearly states what your usecase is and the constraits is never a bad idea but that highlevel usecase is what we would like it to capture rather then i think it should be done X way10:11
Dinesh_Bhorsean-k-mooney: we have dedicated rich flavors which land on predefined hypervisors. Its like giving bare metal kind of experience with Rich-VMs10:12
Dinesh_Bhorsean-k-mooney: hosts are high in memory, cpus to give bare metal kind of performance. So we want Rich-Flavors to be deployed on those hosts and want to manage quota for them.10:14
Dinesh_Bhorsean-k-mooney:  similar to normal vms per project10:14
sean-k-mooneyDinesh_Bhor: right in that case rather then an instance quota the abblity to set a flavor qouta for a speific flavor would be enough to suit your partcalar usecase correct?10:14
sean-k-mooneyyou could then use flavor to host affinity to ensure those flavor got shceduled to the correct hosts10:15
Dinesh_BhorA project can have normal as well as rich vms10:15
Dinesh_Bhorsean-k-mooney:  yes, we are managing that with AggregateInstanceExtraSpecFilter10:16
Dinesh_Bhorsean-k-mooney: we are on Mitaka so can not use placement.10:16
sean-k-mooneyDinesh_Bhor: yes when i said flavor quota i ment can have 10 instances of flavor X and any number of flavors without a qota provided they dont exceed other qoutas such as cpus10:16
*** adrianc has joined #openstack-nova10:17
sean-k-mooneyDinesh_Bhor: the only non invasive way i can consive of to achive this i mitaka would be to write a schduler filter that would check you usage of the rich vms and fail all hosts if you exceed a qouta10:18
Dinesh_Bhorsean-k-mooney:  yes, but for that I thought of storing "no of rich-vms allowed" metadata in host-aggregate for per project but that will again degrade the performance of scheduler I think If we have 1000+ projects.10:21
Dinesh_Bhorsean-k-mooney: okay, let me check the flavor quota thing.10:22
Dinesh_Bhorfirst10:22
sean-k-mooneyDinesh_Bhor: yes it would degrade the performance.10:22
sean-k-mooneyDinesh_Bhor: i would speak to melwitt about this also. i belive she will be looking at how we can start to use the new keystone limmits api in nova going forward. that might help with this usecase10:23
Dinesh_Bhorsean-k-mooney: yes, thank you so much10:24
*** jaosorior has quit IRC10:25
*** jaosorior has joined #openstack-nova10:27
*** udesale has joined #openstack-nova10:33
*** dave-mccowan has joined #openstack-nova10:35
*** tbachman has quit IRC10:39
*** udesale has quit IRC10:44
*** udesale has joined #openstack-nova10:44
*** claudiub has joined #openstack-nova10:45
*** nicolasbock has joined #openstack-nova10:47
*** erlon has joined #openstack-nova10:48
*** ttsiouts has quit IRC10:56
*** priteau has quit IRC11:00
openstackgerritRong Han proposed openstack/nova master: Reset global variable after unit test is completed.  https://review.openstack.org/59808811:00
*** Dinesh_Bhor has quit IRC11:03
*** macza has joined #openstack-nova11:04
*** priteau has joined #openstack-nova11:08
*** macza has quit IRC11:09
*** holser_ has quit IRC11:14
*** holser_ has joined #openstack-nova11:15
*** cdent has joined #openstack-nova11:15
openstackgerritMerged openstack/nova master: Report client: Real get_allocs_for_consumer  https://review.openstack.org/58459911:17
*** cdent has quit IRC11:23
*** tetsuro has joined #openstack-nova11:27
*** jpena is now known as jpena|lunch11:27
*** rnm has joined #openstack-nova11:34
*** rnm is now known as rmart0411:36
openstackgerritRong Han proposed openstack/nova master: Reset global variable after unit test is completed.  https://review.openstack.org/59808811:36
*** tetsuro has quit IRC11:38
*** threestrands has quit IRC11:38
*** rmart04 has quit IRC11:40
*** rnm has joined #openstack-nova11:40
*** rnm has quit IRC11:42
*** rnm has joined #openstack-nova11:42
*** ttsiouts has joined #openstack-nova11:43
*** rnm is now known as rmart0411:43
*** cdent has joined #openstack-nova11:49
*** gouthamr has quit IRC11:49
*** alexchadin has quit IRC11:59
*** tetsuro has joined #openstack-nova12:03
bauzasstephenfin: https://review.openstack.org/#/c/530924/6 needs a new oslo.config version, right?12:04
*** tetsuro has quit IRC12:07
bauzasstephenfin: nevermind, I can see it's from oslo.config 5.2.012:07
bauzashttps://docs.openstack.org/releasenotes/oslo.config/queens.html#relnotes-5-2-0-stable-queens12:07
bauzasand nova uses the latest https://github.com/openstack/nova/blob/master/requirements.txt#L4012:08
*** udesale has quit IRC12:08
*** tetsuro has joined #openstack-nova12:08
*** dpawlik has quit IRC12:08
*** dpawlik has joined #openstack-nova12:09
*** dpawlik has quit IRC12:10
*** dpawlik has joined #openstack-nova12:10
*** udesale has joined #openstack-nova12:11
zigobauzas: Don't worry, Rocky doesn't even build with 5.2.0 anywway ... :)12:12
zigoOnce more, requirements are just plain wrong.12:12
zigoAs usual, I'd say...12:12
zigoSome packages are using oslo_config.sphinxconfiggen which isn't available in oslo.config 5.2.0.12:15
zigonetworking-bagpipe for example.12:15
bauzasstephenfin: heh, I found you a new Friday nick <finucannitbacktick> :p12:16
bauzaszigo: that's a project related issue12:17
zigobauzas: Ok, you need another example ...12:17
bauzaszigo: the reviewers should look at the needed oslo version when they merge a new feature12:17
zigobauzas: Neutron has 1700+ unit test failures with current lower bounds ! :)12:18
*** brinzhang has quit IRC12:20
*** brinzhang has joined #openstack-nova12:21
*** alexchadin has joined #openstack-nova12:28
*** oanson has joined #openstack-nova12:30
*** jpena|lunch is now known as jpena|off12:31
*** jpena|off is now known as jpena12:32
*** slaweq has quit IRC12:34
*** slaweq has joined #openstack-nova12:34
*** alexchadin has quit IRC12:38
*** udesale has quit IRC12:40
openstackgerritJay Pipes proposed openstack/os-traits master: clean up CUDA traits  https://review.openstack.org/59717012:41
*** tbachman has joined #openstack-nova12:42
stephenfinbauzas: :D12:48
stephenfinbauzas: People will eventually learn :)12:48
stephenfinzigo: What do you mean, it doesn't build?12:49
*** vivsoni has quit IRC12:49
stephenfinbauzas: Also, we have oslo.config 6.1.0 in lower-constraints so I think we're all good there12:49
*** vivsoni_ has joined #openstack-nova12:49
bauzasyep12:50
*** mchlumsky has joined #openstack-nova12:50
*** udesale has joined #openstack-nova12:53
*** mriedem has joined #openstack-nova12:54
mriedemcdent: can you remind someone internally to re-propose the spec for this for stein? https://blueprints.launchpad.net/nova/+spec/vmware-live-migration12:56
mriedemor you can if you want, it's just procedural12:56
mriedemhttps://specs.openstack.org/openstack/nova-specs/readme.html#previously-approved-specifications12:57
cdentmriedem: yeah, I think rado's gonna take care of it, he was on pto for a while12:58
*** tbachman has quit IRC12:59
openstackgerritMatt Riedemann proposed openstack/nova stable/rocky: Restart scheduler in TestNovaManagePlacementHealAllocations  https://review.openstack.org/59815212:59
brinzhangmriedem: Could you please review this specs, https://review.openstack.org/#/c/591976/? If you have time :)12:59
mriedemsure13:00
brinzhangthanks ^^13:00
*** tssurya has joined #openstack-nova13:01
cdentmriedem: is there any new insight on the allocation thing yet, or has that not come round on the radar yet?13:05
*** moshele has quit IRC13:06
mriedemi think i got a failing xen ci result last night after i knocked off for the day, was going to investigate this morning13:08
mriedem1 sip into coffee ...13:08
*** erlon has quit IRC13:08
openstackgerritChen proposed openstack/nova master: Fix filter server list by multiple vm or task states  https://review.openstack.org/59815413:09
*** mchlumsky has quit IRC13:10
*** mchlumsky has joined #openstack-nova13:12
*** brinzhang has quit IRC13:13
*** alexchadin has joined #openstack-nova13:13
mriedemalex_xu: ^ looks like a behavior change13:16
mriedemcdent: oh i remember now, i had to re-run the xen ci patch last night b/c it wasn't picking up my dependency in depends-on: <url> form b/c it's still using zuul v213:17
cdentmriedem: fun!13:18
mriedemthe logs are there in the latest failed run though13:18
mriedemhttp://dd6b71949550285df7dc-dda4e480e005aaa13ec303551d2d8155.r49.cf1.rackcdn.com/13/597613/2/check/dsvm-tempest-neutron-network/cc81140/logs/screen-n-cpu.txt.gz13:18
mriedemlooking at req-99d9d496-6720-4837-a2ee-560605fd1afe13:18
mriedemnaichuans: efried: ^13:18
mriedemAug 29 16:56:06.926641 dsvm-devstack-citrix-mia-nodepool-1379368 nova-compute[24436]: INFO nova.compute.resource_tracker [None req-99d9d496-6720-4837-a2ee-560605fd1afe None None] Using cpu_allocation_ratio 16.0 for node: 2f5a2e04-1b61-4437-ab6e-8dbbf797dc0713:19
mriedemAug 29 16:56:06.926926 dsvm-devstack-citrix-mia-nodepool-1379368 nova-compute[24436]: INFO nova.compute.resource_tracker [None req-99d9d496-6720-4837-a2ee-560605fd1afe None None] RT: Sending compute node inventory changes back toplacement for node: 2f5a2e04-1b61-4437-ab6e-8dbbf797dc0713:19
mriedemWAH WAH13:19
mriedemAug 29 16:56:06.965945 dsvm-devstack-citrix-mia-nodepool-1379368 nova-compute[24436]: INFO nova.compute.provider_tree [None req-99d9d496-6720-4837-a2ee-560605fd1afe None None] Inventory has not changed in ProviderTree for provider: 2f5a2e04-1b61-4437-ab6e-8dbbf797dc0713:19
mriedemhmm, but then it says it does update inventory13:20
mriedemAug 29 16:56:07.057208 dsvm-devstack-citrix-mia-nodepool-1379368 nova-compute[24436]: DEBUG nova.compute.provider_tree [None req-99d9d496-6720-4837-a2ee-560605fd1afe None None] Updating resource provider 2f5a2e04-1b61-4437-ab6e-8dbbf797dc07 generation from 0 to 1 during operation: update_inventory {{(pid=24436) _update_generation /opt/stack/new/nova/nova/compute/provider_tree.py:161}} Aug 29 16:56:07.057499 dsvm-devstack-citr13:20
mriedemia-nodepool-1379368 nova-compute[24436]: INFO nova.compute.provider_tree [None req-99d9d496-6720-4837-a2ee-560605fd1afe None None] Updating inventory in ProviderTree for provider 2f5a2e04-1b61-4437-ab6e-8dbbf797dc07 with inventory: {'VCPU': {'allocation_ratio': 16.0, 'total': 8, 'reserved': 0, 'step_size': 1, 'min_unit': 1, 'max_unit': 8}, 'MEMORY_MB': {'allocation_ratio': 1.5, 'total': 12795, 'reserved': 512, 'step_size': 1,13:20
mriedemn_unit': 1, 'max_unit': 12795}, 'DISK_GB': {'allocation_ratio': 1.0, 'total': 47, 'reserved': 0, 'step_size': 1, 'min_unit': 1, 'max_unit': 47}}13:20
mriedemthere the allocation ratios are all correct13:20
mriedemAug 29 16:56:07.058213 dsvm-devstack-citrix-mia-nodepool-1379368 nova-compute[24436]: DEBUG nova.scheduler.client.report [None req-99d9d496-6720-4837-a2ee-560605fd1afe None None] Updated inventory for 2f5a2e04-1b61-4437-ab6e-8dbbf797dc07 at generation 1: {'VCPU': {'allocation_ratio': 16.0, 'total': 8, 'reserved': 0, 'step_size': 1, 'min_unit': 1, 'max_unit': 8}, 'MEMORY_MB': {'allocation_ratio': 1.5, 'total': 12795, 'reserved13:21
mriedem12, 'step_size': 1, 'min_unit': 1, 'max_unit': 12795}, 'DISK_GB': {'allocation_ratio': 1.0, 'total': 47, 'reserved': 0, 'step_size': 1, 'min_unit': 1, 'max_unit': 47}} {{(pid=24436) _update_inventory_attempt /opt/stack/new/nova/nova/scheduler/client/report.py:965}}13:21
cdentgoes to zero at 16:58:05.61374113:21
cdentright after an "Inventory has not changed in ProviderTree for provider"13:23
openstackgerritRadoslav Gerganov proposed openstack/nova-specs master: VMware: add support for live migration  https://review.openstack.org/59816313:23
*** erlon has joined #openstack-nova13:24
mriedemAug 29 16:58:05.483508 dsvm-devstack-citrix-mia-nodepool-1379368 nova-compute[24436]: INFO nova.compute.resource_tracker [None req-a869fa19-aa9d-4335-9816-42ff29b64d48 None None] Using cpu_allocation_ratio 0.0 for node: 2f5a2e04-1b61-4437-ab6e-8dbbf797dc0713:24
mriedemyeah wtf13:24
mriedemthat's in the _normalize_inventory_from_cn_obj method13:25
cdentI'm gonna go with "something is being side-effecty"13:25
mriedemsomehow the ComputeNode.cpu_allocation_ratio is getting persisted as 0.0 maybe?13:25
cdentyou added a log for that didn't you?13:25
mriedemyes and i don't see either of them13:26
mriedemhttps://review.openstack.org/#/c/597560/3/nova/objects/compute_node.py.13:26
cdentw & the t & the actual f13:26
cdentwrite before the correct inventory is sent we have this line "Using cpu_allocation_ratio 0.0 for node [...]". that value, I would guess, is somehow being used for the _next_ inventory13:31
mriedemi noticed that also,13:32
cdentwe're getting update inventories within 2 ms of one another. first one right, second one wrong13:32
mriedemwe have this with the wrong value13:32
mriedemAug 29 16:58:05.483508 dsvm-devstack-citrix-mia-nodepool-1379368 nova-compute[24436]: INFO nova.compute.resource_tracker [None req-a869fa19-aa9d-4335-9816-42ff29b64d48 None None] Using cpu_allocation_ratio 0.0 for node: 2f5a2e04-1b61-4437-ab6e-8dbbf797dc0713:32
mriedemand we have a good update here:13:32
mriedemAug 29 16:58:05.525151 dsvm-devstack-citrix-mia-nodepool-1379368 nova-compute[24436]: INFO nova.compute.provider_tree [None req-a869fa19-aa9d-4335-9816-42ff29b64d48 None None] Updating inventory in ProviderTree for provider 2f5a2e04-1b61-4437-ab6e-8dbbf797dc07 with inventory: {u'VCPU': {u'allocation_ratio': 16.0, u'total': 8, u'reserved': 0, u'step_size': 1, u'min_unit': 1, u'max_unit': 8}, u'MEMORY_MB': {u'allocation_ratio':13:32
mriedem, u'total': 12795, u'reserved': 512, u'step_size': 1, u'min_unit': 1, u'max_unit': 12795}, u'DISK_GB': {u'allocation_ratio': 1.0, u'total': 47, u'reserved': 0, u'step_size': 1, u'min_unit': 1, u'max_unit': 47}}13:32
mriedemand then the bad update:13:32
mriedemAug 29 16:58:05.613741 dsvm-devstack-citrix-mia-nodepool-1379368 nova-compute[24436]: INFO nova.compute.provider_tree [None req-a869fa19-aa9d-4335-9816-42ff29b64d48 None None] Updating inventory in ProviderTree for provider 2f5a2e04-1b61-4437-ab6e-8dbbf797dc07 with inventory: {'VCPU': {'allocation_ratio': 0.0, 'total': 8, 'reserved': 0, 'step_size': 1, 'min_unit': 1, 'max_unit': 8}, 'MEMORY_MB': {'allocation_ratio': 0.0, 'tot13:32
mriedem 12795, 'reserved': 512, 'step_size': 1, 'min_unit': 1, 'max_unit': 12795}, 'DISK_GB': {'allocation_ratio': 0.0, 'total': 47, 'reserved': 0, 'step_size': 1, 'min_unit': 1, 'max_unit': 47}}13:32
*** jamesdenton has joined #openstack-nova13:38
*** awaugama has joined #openstack-nova13:39
*** davidsha has joined #openstack-nova13:40
*** eharney has joined #openstack-nova13:40
mriedemhmm https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L62213:42
mriedem^ we set the ComputeNode.cpu_allocation_ratio based on the config, which is 0.013:43
sean-k-mooneymriedem: so it had the correct allocation  ratio then it was chaged to 0.013:43
mriedemi bet that is the problem13:43
*** toabctl has joined #openstack-nova13:44
mriedem_copy_resources is called from _init_compute_node,13:45
cdentmriedem: but none of that stuff is new is it?13:45
mriedemand on initial create of the compute node record, the ComputeNode.create() method will call _from_db_object at the end and fix the 0.0 allocation ratio to the hard-coded one,13:45
openstackgerritTakashi NATSUME proposed openstack/nova master: Transform compute_task notifications  https://review.openstack.org/48262913:45
mriedemthen in a periodic run, the cn already exists, we'll copy over the busted 0.0 allocations from config, but b/c we removed the _update calls there, we don't fix the allocation ratios13:46
cdentah, there's the rub13:46
mriedemwhich is https://review.openstack.org/#/c/520024/13:46
mriedembut that doesn't explain how zigo was hitting this on rocky13:46
mriedemor how we're *not* hitting this in the normal gate13:46
openstackgerritMerged openstack/nova master: (Re)start caching scheduler after starting computes in tests  https://review.openstack.org/59760613:47
cdentdoes the normal gate set conf?13:47
mriedemno13:47
sean-k-mooneymriedem:  is there a reason we do not set the defults here https://github.com/openstack/nova/blob/master/nova/conf/compute.py#L413-L41613:47
*** Bhujay has quit IRC13:47
mriedemhttp://logs.openstack.org/24/520024/9/check/tempest-full/cbd025d/controller/logs/etc/nova/nova-cpu_conf.txt.gz13:47
mriedemsean-k-mooney: yes read the help text13:48
alex_xumriedem: yea, sounds like13:48
*** udesale has quit IRC13:49
sean-k-mooneymriedem: hum right...  so we can single to use the schduler nodes value13:49
mriedemthis was the change to make the defaults 0.0 https://github.com/openstack/nova/commit/4a9e14a7a73832b6b878160ba4a45f259d078d2713:50
*** alexchadin has quit IRC13:50
*** udesale has joined #openstack-nova13:50
*** psachin has quit IRC13:51
sean-k-mooneymriedem: "That compat mode (having ratios defaulted to 0.0) is only planned to be kept for13:51
sean-k-mooneyLiberty and will be removed in the next release (Mitaka)13:51
*** jistr is now known as jistr|call13:51
sean-k-mooneywell that never happened13:52
mriedemtalk to bauzas13:52
*** _hemna has quit IRC13:54
bauzasI'm back13:54
sean-k-mooneymriedem: its just one of those things if there is not an explit TODO in teh code you can grep for at the end of a release its easy to miss removing this stuff13:54
mriedemin a few months i'll be able to remove all the req spec compat code13:54
mriedemsean-k-mooney: there are todos13:54
mriedem# TODO(sbauza): Remove that in the next major version bump where13:54
mriedem            # we break compatibility with old Liberty computes13:54
bauzasI think the comments explained the 0.0 values13:54
bauzasit's because of an upgrade concern between Liberty and Mitaka13:55
mriedemhttps://github.com/openstack/nova/blob/master/nova/objects/compute_node.py#L18613:55
mriedemcdent: so i'm adding more debug logs to verify where i think this is breaking down and will get another xen run13:55
bauzasit was for knowing whether the operator was modifying the options directly, or using the defaults13:55
bauzassean-k-mooney: ^13:55
bauzas(a signal)13:55
cdentmriedem: sounds like a good plan13:55
sean-k-mooneybauzas: yes the commit and comments make that clear but presumably we should have deleted it before rocky13:56
bauzasindeed13:56
*** gbarros has joined #openstack-nova13:56
sean-k-mooneybauzas: i assume the reason that there was not a explcit optin bool flag was so that we did not need modify the configs to get the new behavior if the operator had not overriden it before13:57
*** adrianc has quit IRC13:58
bauzassean-k-mooney: it was because we changed so the options were per compute13:58
mriedemin case you haven't noticed, the allocation ratio stuff is still biting us in the ass, so this isn't a very clear "now we can just remove stuff" case13:58
mriedemi think jaypipes has at least 10 specs for dealing with this13:58
bauzasmriedem: because we now use the ratio values directly without using the ComputeNode object13:59
mriedemand this is such a mine field i'm afraid to change anything13:59
jaypipesmriedem: yeah. :(13:59
mriedembauzas: not really13:59
mriedembauzas: this is where we get the allocatoin ratio to put into placement inventory https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L10714:00
mriedemif that's what you're referring to14:00
mriedemwhich uses the compute node facade14:00
sean-k-mooneythe main issue we have at the moment is we have 2 different sets fo defaults that get applied depending on the code path we take for the same value14:00
*** tetsuro has quit IRC14:00
mriedemand because of https://review.openstack.org/#/c/520024/ it looks like we've side-stepped the facade from breaking us14:00
*** mlavalle has joined #openstack-nova14:03
bauzasmriedem: I'm trying to understand the problems, I should look at jaypipes's specs14:03
openstackgerritMatt Riedemann proposed openstack/nova master: Add debug logs for when provider inventory changes  https://review.openstack.org/59756014:03
mriedemposted debug notes in https://bugs.launchpad.net/nova/+bug/178965414:04
openstackLaunchpad bug 1789654 in OpenStack Compute (nova) rocky "placement allocation_ratio initialized with 0.0" [High,Confirmed]14:04
mriedemif the allocation ratio in the db record is 16.0 but the object value in the RT is 0.0, we know that _copy_resources is what's changing our in-memory value and we're not persisting the change14:05
sean-k-mooneymriedem: well we dont actully want to persist the change to the db in this case14:06
*** Luzi has quit IRC14:06
sean-k-mooneythe db has the correct default14:06
mriedemthe db values are likely actually NULL14:06
mriedemwhich is what the compute node object keys off of14:07
bauzasmriedem: so we directly change the object value without reading it from the DB thru the facade ?14:07
mriedemhttps://github.com/openstack/nova/blob/f534495a427d1683bc536cf003ec02edbf6d8a45/nova/objects/compute_node.py#L19414:07
sean-k-mooneythe db perhaps but the object that is constrted form the db entry gets defaulted correctly14:07
sean-k-mooneyyep that is the line i was thinking of14:07
mriedemsean-k-mooney: yes but my theory is we're not "fixing" the allocation ratios within the object after setting the values to 0.014:07
mriedembecause of https://review.openstack.org/#/c/520024/14:07
mriedemzigo: is it possible that you have ^ in your nova package somehow?14:08
sean-k-mooneyright because we removed the update call which update the resouce tracker14:08
mriedemzigo: iow, are your nova rocky packages based on stable/rocky or 18.0.0 tags rather than just pulling from master?14:08
sean-k-mooneymriedem: we proably should have kept the self._update on line 57414:09
mriedemthat wouldn't have helped us in this case,14:09
mriedemthat's for a nova-compute restart where the cn record already exists,14:09
mriedemwhat we're hitting is the condition above14:10
bauzasmriedem: just to be clear, https://github.com/openstack/nova/blob/f534495a427d1683bc536cf003ec02edbf6d8a45/nova/objects/compute_node.py#L199-L207 is only intended to be executed if on nova-scheduler14:10
bauzasmriedem: because https://github.com/openstack/nova/blob/f534495a427d1683bc536cf003ec02edbf6d8a45/nova/objects/compute_node.py#L198 will always tell you a value if you're on nova-compute14:10
mriedemumm14:10
mriedemthat will also always tell you a value if you're on nova-scheduler14:11
mriedemb/c conf is global14:11
mriedemand the value defaults to 0.0 in config14:11
bauzasif executed in separate workers, CONF.cpu_allocation_ratio wouldn't be defined for nova-scheduler14:12
bauzasoh wait, sec14:12
mriedemit doesn't need to be defined in config, we have a default14:12
mriedemwhich is global14:12
mriedemanyway, that doesn't really matter for this bug14:13
mriedemthe compute reports the inventory to placement and is reporting 0.0 allocation ratios14:13
cdentmriedem: one thing that remains unclear for me (becuase apparently I can't read python code) is why the second inventory PUT (the one with the 0.0) is happening at all (and so soon)14:14
*** adrianc has joined #openstack-nova14:14
*** adrianc has quit IRC14:17
bauzasmriedem: I think your working theory you stated in the bug comment is valid14:18
bauzasI'm trying to wrap my head around on exactly when we pull the DB values14:18
openstackgerritMatt Riedemann proposed openstack/nova master: Revert "Update resources once in update_available_resource"  https://review.openstack.org/59817614:19
*** munimeha1 has joined #openstack-nova14:19
*** alexchadin has joined #openstack-nova14:20
bauzasmriedem: I think we began having problems with https://github.com/openstack/nova/commit/7b95b4d60726b6c8d0e0fe939c408a91ada79e0c14:21
bauzasI'm not saying it's all the bugs cause14:21
*** jistr|call is now known as jistr14:21
bauzasjust that it implicitly creates a dependency on us calling .save() after it14:21
bauzasbecause if not, we would then have 0.0 values14:22
mriedemwell, it seems pretty obvious to me that we just shouldn't set 0.0 values on the compute node record in _copy_resources if the config is still just 0.014:23
bauzasmriedem: sure, we could leave the defaults14:24
bauzasbecause once we pull the object, the facade fixes it for free14:24
mriedemexcept we're no longer pulling the object in the RT14:27
mriedemwhich is i think the problem14:27
zigomriedem: Sure, let me add it.14:27
zigomriedem: Yes, I package tags.14:28
mriedemzigo: you don't want to add it14:29
bauzasmriedem: sorry, you mean we're getting the CPU, RAM and disk values out of the DB directly ?14:29
bauzasI thought we were still getting by id ?14:29
mriedemzigo: i'm asking because https://review.openstack.org/#/c/520024/ is in master only, not rocky, but it looks like the culprit of the failure - but that wouldn't then explain how you'd be failing in rocky14:29
bauzasme looks at https://github.com/openstack/nova/blob/f534495a427d1683bc536cf003ec02edbf6d8a45/nova/compute/resource_tracker.py#L8514:30
zigomriedem: I have rc2 packaged, not rc3.14:31
zigoMaybe I should update?14:31
mriedemyeah probably14:32
mriedemor just the GA14:32
mriedemwhich was released today?14:32
mriedemhttps://github.com/openstack/nova/tree/18.0.014:32
mriedemyeah 20 minutes ago http://git.openstack.org/cgit/openstack/nova/tag/?h=18.0.014:32
zigoAh, right !14:35
zigoDoing that.14:36
*** tbachman has joined #openstack-nova14:36
cdentI'm thinking that the positive way of looking at this is that the second _update has been masking a nasty bug for a long time14:36
* cdent takes more happy pills14:36
*** _hemna has joined #openstack-nova14:39
mriedemoh i'm not surprised that there would be a big pile of tight coupling tape holding this all together14:41
mriedemand why i didn't want to merge that change before the GA14:42
*** alexchadin has quit IRC14:42
*** jchhatbar has quit IRC14:43
*** vivsoni_ has quit IRC14:43
*** alexchadin has joined #openstack-nova14:44
*** lei-zh has joined #openstack-nova14:46
*** r-daneel has joined #openstack-nova14:47
bauzasmriedem: again, the more I read, the more I think we possibly had the original problem once we had https://github.com/openstack/nova/commit/7b95b4d60726b6c8d0e0fe939c408a91ada79e0c14:49
bauzasand .update() was just hiding it14:49
bauzasmriedem: so, do you want me to modify the above and only set the values if not 0.0 ?14:50
bauzasor are you working on this ?14:50
*** vivsoni has joined #openstack-nova14:51
bauzasdisclaimer: looking at a long list of openstack-dev threads14:52
*** ttsiouts has quit IRC14:55
mriedemKevin_Zheng: yikun: you might be interested in https://review.openstack.org/#/c/591976/15:00
mriedembauzas: i'm working it15:00
bauzasokay15:00
Kevin_ZhengGot it15:01
*** ttsiouts has joined #openstack-nova15:01
*** luksky11 has quit IRC15:02
zigoNova 18.0.0 built, doing a recheck...15:02
openstackgerritMerged openstack/nova master: Fix soft deleting vm fails after "nova resize" vm  https://review.openstack.org/54692015:03
*** udesale has quit IRC15:04
melwitt.15:04
*** tbachman has quit IRC15:07
*** pcaruana has quit IRC15:12
*** r-daneel has quit IRC15:13
*** r-daneel_ has joined #openstack-nova15:13
melwittstephenfin: on https://review.openstack.org/595592, if the bug is new for rocky, how did moshele run into it on OSP13 (queens)?15:16
*** r-daneel_ is now known as r-daneel15:16
stephenfinmelwitt: If he's using OSP, then it's because we backported it downstream15:16
stephenfinEven if not, I'd imagine it's a feature backport15:16
*** dpawlik has quit IRC15:18
melwittstephenfin: ohh, ok. I didn't think of that, backport of a feature15:18
mriedemefried: does any kind of nova/cyborg integration actually exist to do anything with servers in rocky/15:30
mriedem?15:30
mriedemb/c https://docs.openstack.org/releasenotes/cyborg/rocky.html says it does15:31
*** macza has joined #openstack-nova15:31
mriedem1) rocky release notes talk about queens specs15:31
mriedem2) it sounds like "we completed specs" rather than "we have functioning code"15:31
Kevin_Zhengmriedem: you made me laugh15:32
mriedemi just don't want people showing up in -nova saying "hey why can't i attach fpgas to my vm?"15:33
efriedmriedem: No, cyborg has nothing in nova atm15:38
efriedoh, yeah, that's poorly worded.15:38
Kevin_Zhengmriedem: we were talking today, about the batch when listing patch15:41
Kevin_ZhengThe batch size could vary depending on sort key and dir15:42
Kevin_ZhengLike for sort with uuid15:42
*** gyee has joined #openstack-nova15:42
Kevin_ZhengIt could be evenly distributed15:43
dansmithKevin_Zheng: you mean the *optimal* batch size?15:43
Kevin_Zhengdansmith: yeah15:43
dansmithKevin_Zheng: obviously if you're sorting by uuid it should be fairly evenly distributes and sorting by other things could be massively less well-distributed, but I'm not sure how we could (efficiently) optimize that at runtime15:44
dansmithKevin_Zheng: do you have ideas?15:44
Kevin_ZhengI was thinking a tool that analyzes dB data15:45
Kevin_ZhengAnd feed to nova periodically15:45
Kevin_ZhengBut that seems to much :)15:45
dansmithyeah :)15:45
dansmithit likely varies by tenant, sort_key, cloud layout, scheduler weights, etc15:46
Kevin_ZhengJust came up when we introduced the new approach to our product team15:46
dansmithit'd be hard to pin that down except for a single-tenant cloud I think15:46
sean-k-mooneymriedem: today i belive you can use cyborg to program a pci device and then you can use nova to pass it through via a pci passthrough flavor alisa but there is no way to force landing on the host with the device you just programed15:46
Kevin_ZhengI’d say it is a powerful tool:)15:46
dansmithKevin_Zheng: if the goal is to get larger batches from cells likely to have many results, we could do things like scale up the batch size each time you hit a cell again15:47
dansmithKevin_Zheng: so that if your query is likely to get most results from one cell, we get $batch_size, then $batch_size*2, then $batch_size*4, etc15:48
dansmithbut I think I'd want to see a benchmark showing that as worthwhile before I approved it,15:48
Kevin_ZhengHmm15:48
dansmithbecause I expect that since the db query time is so small compared to the processing time, I'm not sure it matters that much (even your hyper-optimized batch sizing tool :)15:48
Kevin_ZhengThat could be a good way15:48
Kevin_ZhengYeah, they are just guessing as always15:49
*** luksky11 has joined #openstack-nova15:49
dansmithKevin_Zheng: yeah :D15:49
dansmithKevin_Zheng: it's  common trap: One big optimization on batch size gives 60% improvement, so assume there are more 60% improvements to be gained through hyper-optimization :)15:50
openstackgerritMerged openstack/nova-specs master: VMware: add support for live migration  https://review.openstack.org/59816315:50
mriedemleave some optimizations for the enterprise fellas15:59
*** hamzy has quit IRC16:00
mriedemgibi: you were +2 on this before i robustified the test per mel's prodding https://review.openstack.org/#/c/588943/16:01
Kevin_Zhengmaybe left some place for them to be able to do that, like a call to my powerful tool backend :P16:03
mriedemis the toronto lab already working on that?16:04
mriedemresearch people gotta get grant money somehow16:05
sean-k-mooneymriedem: i will likely be fixing a few things in cyborg in the near future. do you want me to fix the releases note regarding nova inetgration16:05
mriedemneed i remind everybody https://www.openstack.org/videos/vancouver-2018/revisiting-scalability-and-applicability-of-openstack-placement-116:05
mriedemsean-k-mooney: i guess?16:05
mriedemrevising release notes is sometimes a tricky business16:06
sean-k-mooneywell we update specs retroactivly i done really see release notes as any different16:06
mriedembecause release notes are built from git history16:07
mriedemspecs are not16:07
stephenfinsean-k-mooney: Any reason we don't squash these? https://review.openstack.org/#/q/topic:bug/1759420+(status:open+OR+status:merged)16:07
sean-k-mooneystephenfin: i wanted to specifcally demonstrate that the behavior was wrong16:07
sean-k-mooneyother then that no16:07
Kevin_ZhengNo, Xian lab can work on that:)16:08
stephenfinsean-k-mooney: I'm guessing if we reverted the functional part then we'd see the test fail, right? Any chance you could squash them?16:08
*** dpawlik has joined #openstack-nova16:09
sean-k-mooneystephenfin: sure but i need to go get my car NCT tested so ill do it later this evening/tomorow16:10
stephenfinsean-k-mooney: all good16:10
sean-k-mooneyanything else you want me to change while im doing it?16:10
sean-k-mooneystephenfin:  i might add mel's notes as comments too16:11
mriedemmdbooth: are you ok with the wording here? https://review.openstack.org/#/c/596492/16:11
sean-k-mooneyanyway got to run.16:12
*** alexchadin has quit IRC16:13
*** dpawlik has quit IRC16:13
cdentsean-k-mooney: my MOT (which I guess is the same thing) is tomorrow and it's almost certainly going to fail16:14
*** tbachman has joined #openstack-nova16:15
stephenfinsahid: I've still got open comments on https://review.openstack.org/#/c/532168/16:18
*** ccamacho has quit IRC16:19
*** gaoyan has joined #openstack-nova16:27
stephenfinlyarwood: Can I move this to MODIFIED too? I'm not sure what the process is for non-hotfixes as I didn't have to kick off any builds myself https://bugzilla.redhat.com/show_bug.cgi?id=118794516:27
openstackbugzilla.redhat.com bug 1187945 in openstack-nova "[RFE] Take into account NUMA locality of physical NICs when plugging instance VIFS from Neutron networks" [Urgent,Post] - Assigned to sfinucan16:27
mnaserso i never ended up doing the full clean up from the stale cell stuff16:29
*** eharney has quit IRC16:29
mnaserbut if i have instances with an instance_mapping entry, no build_request, they don't exist in any cells (cell0 or anything else), i can just drop the instance_mapping entry to get rid of it from the listing?16:29
*** gaoyan has quit IRC16:29
lyarwoodstephenfin: ^_^16:29
dansmithmnaser: yeah16:30
dansmithmnaser: that should be the case for any instances you've deleted and then purged from the db16:30
dansmithif you've done that16:30
*** moshele has joined #openstack-nova16:30
dansmithrecently archive started nuking the BR at least16:30
mnaserdansmith: yeah they're not even purged, cell_id = NULL too16:30
dansmithnot sure about the mapping16:30
dansmithoh okay well, if they're really gone there's no need for the mapping16:30
stephenfinlyarwood: 🙈16:30
mnaserthis was a whole thing related to the adding entries into nova_api in a single transaction16:31
mnaserwhich i think i put a patch that i *think* works but i dont know how to test that it works in a single transaction16:31
*** sambetts is now known as sambetts|afk16:31
mnaserhttps://review.openstack.org/#/c/586824/1 was supposed to be backportable interim solution to avoid listing stuff that shouldnt be there and https://review.openstack.org/#/c/586742/2 was the more fundamental fix but i havent had time to look over them more16:32
*** gbarros has quit IRC16:35
*** bnemec has quit IRC16:35
*** lei-zh has quit IRC16:37
*** rmart04 has quit IRC16:41
*** gbarros has joined #openstack-nova16:41
melwittsahid: your review would be appreciated on this bug fix for handling disk_bus for root disk https://review.openstack.org/58499916:42
sahidstephenfin: surprising that it I did not noticed them :)16:42
sahidmelwitt: sure i will do that16:43
melwittthanks16:43
*** r-daneel_ has joined #openstack-nova16:47
*** r-daneel has quit IRC16:47
*** r-daneel_ is now known as r-daneel16:47
*** gouthamr has joined #openstack-nova16:49
*** gbarros has quit IRC16:49
*** sahid has quit IRC16:55
*** ccamacho has joined #openstack-nova16:58
*** ttsiouts has quit IRC16:59
*** davidsha has quit IRC16:59
*** ttsiouts has joined #openstack-nova17:00
*** dtantsur is now known as dtantsur|afk17:04
*** ttsiouts has quit IRC17:04
*** mriedem is now known as mriedem_afk17:11
*** bnemec has joined #openstack-nova17:17
cfriesenin nova/compute/flavors.py we call "from nova.api.validation import parameter_types".  This appears to be really expensive (~6 seconds in a recent test) due to the regex stuff.  One possibility would be to do the import right before the flavor creation so that it doesn't impact all nova processes.  Thoughts?17:19
openstackgerritMerged openstack/nova master: reshaper gabbit: Nix comments re doubled max_unit  https://review.openstack.org/59722017:21
*** ccamacho has quit IRC17:24
*** eharney has joined #openstack-nova17:25
*** jpena is now known as jpena|away17:27
*** hamzy has joined #openstack-nova17:28
openstackgerritMerged openstack/nova master: Fix race condition in reshaper handler  https://review.openstack.org/59649717:35
*** holser_ has quit IRC17:35
sean-k-mooneymelwitt: im just back, am would you like me to squash those two disk bus patches together?17:37
sean-k-mooneymelwitt: i used the functional regression style partly to prove to my self that the test case was corret since you pointed out my orginial test case worked without the patch applied17:38
melwittsean-k-mooney: not right now, maybe only if you need to respin. I don't have a strong opinion about it, just pointing it out17:38
melwittyeah, understood17:38
sean-k-mooneycdent: just got back and ya MOT and NCT are basically the same.17:42
sean-k-mooneycdent: happily in my case it passed the second time.17:43
sean-k-mooneycdent: that said i dont drive my car enough i have only done 8000KM/5000 miles in the last two years...17:44
cdentsean-k-mooney: my car is 21 years old. the emissions check is going to be an issue, I fear. Apparently the trick is to take it in to the test good and hot after racing around like a crazy person17:44
*** jamesdenton has quit IRC17:44
sean-k-mooneycdent: if its 21 years old it shoudl qualify as a vintage car now right?17:45
cdenthmm, that's a good point.17:45
* cdent checks17:45
sean-k-mooneyi cant remeber what the cut off is in ireland but there is an emaitions cut off at some point in ireland where provided you have converted from lead based fule to unleeded the co2 emmsions are basically ignored17:46
openstackgerritMerged openstack/nova master: Report client: get_allocations_for_provider_tree  https://review.openstack.org/58464817:46
*** eharney has quit IRC17:46
*** tssurya has quit IRC17:46
cdentsean-k-mooney: it looks like it may be 40 years here :(17:47
sean-k-mooneycdent: well hopfully it will keep running that long :)17:50
cdenti can only try17:53
cdentsean-k-mooney: in other vaguely related to sean-k-mooney news: I'm sending in my applicaiton for an irish passport today17:53
sean-k-mooneyoh. cutting it a little close with brexit no?17:54
cdenti had to get a hold of my mother's birth certificate17:54
*** r-daneel has quit IRC17:55
*** gyee has quit IRC17:56
sean-k-mooneyya i love that to get a pass port which is ment to be the most secure id you can get in the contry you need a copy of your birth cert which is the only id i have that cant even be used to by alcohol17:56
*** eharney has joined #openstack-nova17:56
cdent\o/17:56
sean-k-mooneyi know they use it in thery to prove that you our your parent are entiled to citezenship in this case but still17:56
*** moshele has quit IRC17:58
*** jamesdenton has joined #openstack-nova17:59
*** r-daneel has joined #openstack-nova17:59
sean-k-mooneyok time for food. laters o/18:00
*** r-daneel_ has joined #openstack-nova18:08
*** r-daneel has quit IRC18:09
*** r-daneel_ is now known as r-daneel18:09
*** tzumainn has joined #openstack-nova18:18
melwittdansmith or jaypipes: could one of you hit this to move rocky implemented specs? https://review.openstack.org/59262218:19
*** moshele has joined #openstack-nova18:26
openstackgerritMerged openstack/nova-specs master: Move rocky implemented specs  https://review.openstack.org/59262218:36
cfriesensean-k-mooney: stephenfin: either of you care to take a look at review.openstack.org/588657 ?   not my patch, I just think it's useful and it's stalled18:38
*** toabctl has quit IRC18:51
tzumainnhi! I'm working with ironic, and running into an issue where, after enrolling baremetal nodes, I can see them in the compute_nodes database table but they never get processed or whatever and show up when I run 'openstack hypervisor list'19:00
tzumainnthe nova-compute.log does have this error, which is suspicious:19:00
tzumainn018-08-30 17:00:51.142 7 ERROR nova.compute.manager [req-73ba9d4b-b51d-4ab7-88c8-5fc3f27fd89e - - - - -] Error updating resources for node 0e57\19:00
tzumainn05cc-e872-49aa-aff4-1a91278b5cb3.: NotImplementedError: Cannot load 'id' in the base class19:00
tzumainn2018-08-30 17:00:51.142 7 ERROR nova.compute.manager Traceback (most recent call last):19:00
tzumainn2018-08-30 17:00:51.142 7 ERROR nova.compute.manager   File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 7729, in _update_av\19:00
tzumainnailable_resource_for_node19:00
tzumainnanyone have experience with this? sorry if the questions are vague, I'm a bit new to this19:00
*** moshele has quit IRC19:07
*** toabctl has joined #openstack-nova19:07
*** awaugama has quit IRC19:08
*** mriedem has joined #openstack-nova19:11
*** mriedem_afk has quit IRC19:12
*** r-daneel has quit IRC19:17
mriedemmelwitt: jungleboyj: is there a specific nova/cinder etherpad for the ptg? i just see a topic section for cinder on thursday in the nova ptg19:17
melwittmriedem: not that I know of. I suggested people add topics on the nova ptg etherpad in the section in my email to the ML19:18
melwittwe can have a separate etherpad to link to if you want19:18
mriedemack19:21
openstackgerritEric Fried proposed openstack/nova master: Fix reshaper report client functonal test nits  https://review.openstack.org/59833019:21
melwitttzumainn: can you pastebin the full traceback?19:22
tzumainnmelwitt, it's at http://pastebin.test.redhat.com/63959619:23
melwittthanks19:25
mriedemhow about a public paste?19:27
mriedempaste.openstack.org or gist.github.com19:28
tzumainnwhoops, sorry!19:28
tzumainnmelwitt, http://paste.openstack.org/show/729177/19:29
melwittthe error is saying there's the 'id' field missing from the ComputeNode object, which means it wasn't created/obtained from the database (where the 'id' field comes from). but in the code, I see a cn.create() before _setup_pci_tracker is called, so  'id' should be populated19:29
mriedemcdent: vmware ci might be hitting the same scheduling issues? http://207.189.188.190/logs/16/270116/12/check-vote/ext-nova-zuul/7a47690/19:29
mriedemlots of novalidhost in there19:30
mriedemthat's on the live migration for vmware change19:30
melwitttzumainn: what release is this?19:30
tzumainnmelwitt, this is rocky19:30
melwittok19:30
mriedemi was going to say https://review.openstack.org/#/c/520024/ but that's not in rocky19:31
melwittheh, that patch again19:33
mriedemit's in the same code path19:34
*** dpawlik has joined #openstack-nova19:34
mriedemby the time we call _setup_pci_tracker there in that block on L563 we should have an existing instance, either created from the RT or pulled from the DB19:36
mriedem*existing compute node record19:36
melwittyeah, according to the trace, the ComputeNode object in self.compute_nodes has no 'id' field populated19:36
melwittso there must be a way we're adding things to self.compute_nodes that are object shells, not gotten from the DB or newly created19:37
*** jpena|away is now known as jpena|off19:38
*** awaugama has joined #openstack-nova19:40
openstackgerritMatt Riedemann proposed openstack/nova master: Default AZ for instance if cross_az_attach=False and checking from API  https://review.openstack.org/46967519:41
cdentthanks mriedem will do some poking and prodding19:49
*** Sundar has joined #openstack-nova19:49
openstackgerritChris Dent proposed openstack/nova master: VMware: Live migration of instances  https://review.openstack.org/27011619:49
mriedemtzumainn: which virt driver? libvirt? ironic?19:52
mriedemand are you doing anything when this happens?19:52
melwittit's ironic19:52
mriedemlike, is this on start of nova-compute or during a periodic task?19:52
mriedemhmmm, is a rebalance happening?19:52
tzumainnmriedem, ah, this is ironic - I've just enrolled four nodes, and am trying to figure out why they don't show up in 'openstack hypervisor list'19:53
mriedemthey won't show up in openstack hypervisor list until you've "discovered" them19:53
mriedemsee the nova-manage cell_v2 discover_hosts command19:54
mriedemyou'll need to discover by service19:54
*** hamzy has quit IRC19:54
*** r-daneel has joined #openstack-nova19:55
tzumainnah, okay! I wasn't aware - I'm following the instructions in http://tripleo.org/install/advanced_deployment/baremetal_overcloud.html which I guess are out of date19:55
*** hamzy has joined #openstack-nova19:55
melwittthe traceback was unrelated then. still don't see how the condition of no 'id' on a ComputeNode in self.compute_nodes can happen (thought it obviously can happen somehow)19:56
*** ttsiouts has joined #openstack-nova19:56
mriedemyeah i don't really know how that's being hit19:56
mriedemtzumainn: no idea re tripleo deployment, they have their own irc channel for that19:57
melwittremove_node removes things from the dict if orphaned, all of the setting of self.compute_nodes seem to be covered by actual DB gets or creates. weird19:57
mriedemplus like 50 red hat cores19:57
tzumainnmriedem, haha, yep - I started out talking with some ironic folks, and confusion all around has led me here : )19:58
tzumainnthanks for the information, I really appreciate it!19:58
mriedemmaybe related to https://review.openstack.org/#/c/587922/ ?19:59
jungleboyjmriedem: I don't have a separate one. Asked people to mark the topics and then I was going to collect them up.20:00
mriedemremove_node should likely be in the same semaphore as _update_available_resource_for_node20:00
mriedemi guess i already said that https://review.openstack.org/#/c/587922/2/nova/compute/resource_tracker.py20:00
mriedemso self.old_resources will default a ComputeNode object if an entry isn't in the dict...20:01
zigomriedem: Should I try your patch at https://review.openstack.org/#/c/598176/ and report the result?20:02
melwittdoes self.compute_nodes refer to self.old_resources at all?20:02
mriedemthey are compared in _resource_change20:03
mriedemto determine if we should call ComputeNode.save()20:03
mriedemzigo: we aren't going to ship that revert i don't think so probably would be a waste of your time20:03
zigomriedem: If it's only a temporary fix that I can use to validate all of Rocky, that's nice already, then I can still remove the patch...20:04
zigoHum...20:04
zigoIt doesn't apply at all anyway.20:04
zigomriedem: This wasn't in rocky.20:05
mriedemcdent: melwitt: was also wondering if this somehow is contributing to the allocation ratio bug https://review.openstack.org/#/c/518294/20:05
mriedembut that was in queens20:05
mriedemzigo: right20:05
*** mchlumsky has quit IRC20:05
melwittack20:05
zigomriedem: Could you see something with the added logs in https://review.openstack.org/#/c/597175/ ?20:06
zigoBoth your patches were added there ...20:06
zigo(the ones for logging...)20:06
mriedemi added more debug logs this morning after a recreate in the xen ci, was just about to check those results20:08
mriedemtzumainn: you might want to report a nova bug regardless so we don't lose track of what you hit20:08
mriedemi'm not sure *how* you're hitting it, but that seems to be the theme this week with all bugs20:08
mriedem"how in the hell is this even possible?"20:09
tzumainnmriedem, hahaha - okay, I'll do that, thanks!20:09
openstackgerritMerged openstack/nova master: Report client: _reshape helper, placement min bump  https://review.openstack.org/58503420:09
mriedemdansmith: is it weird that ComputeNode.save() doesn't check to see if 'id' is changed?20:10
mriedemor not set?20:10
dansmithcreate or save?20:10
mriedemi guess if it weren't set we'd blow up20:10
mriedemsave20:10
melwittI was thinking save() would just fail if there's no id, because then how could it find the thing to update20:10
dansmithnot sure we usually check that it's set on save, but we could20:10
dansmithon create we usually check to avoid re-create20:11
mriedemmelwitt: right we'd blow up if id wasn't set on save20:11
melwittyeah20:11
mriedemyeah we check on create20:11
mriedemi was wondering if id changed though and we saved20:11
mriedemi guess we don't really check for that anywhere20:11
dansmithwe pop id out of the changes,20:11
melwitteven if we did, that doesn't explain the complete lack of an 'id' on a ComputeNode object in self.compute_nodes20:12
dansmithbut I guess we try to save anyway even if that was the only thing20:12
melwittI still don't see how we could lose that, even with the self.old_resources compare20:12
dansmithif id is actually not set then it's either an object created with no id (not from the db) or someone del'd it off an objet20:13
mriedemi don't either, i was wondering if we were getting a blank ComputeNode from old_resources which uses defaultdict and somehow shoved that blank one into self.compute_nodes20:13
mriedembut we don't20:13
melwittyeah20:13
mriedemthere is a very small window where self.compute_nodes could have a ComputeNode in it without an id20:16
mriedemin _init_compute_node20:16
mriedemself.compute_nodes[nodename] = cn20:16
mriedem        cn.create()20:16
mriedemb/c cn.create() is what sets the id20:16
mriedembut, that code is all in a lock on the same host when we call update_available_resource20:16
mriedemso not sure how anything could race and hit that20:16
melwittyeah, I wondered about that20:16
mriedemtzumainn: did you by chance have multiple nova-compute services running on the same host?20:17
mriedemno that still wouldn't do this20:17
mriedemb/c the compute nodes map is in memory20:18
mriedemi give up20:18
tzumainnmriedem, I only have one, in any case20:18
tzumainnmriedem, no worries, thanks for taking a look : )20:18
mriedemso uh, the xen ci passed this time with the debug patch https://review.openstack.org/#/c/597613/20:20
mriedemthat's nice and consistent20:20
*** erlon has quit IRC20:21
melwittgreat20:23
*** eharney has quit IRC20:24
*** mugsie has quit IRC20:25
melwittkeeping in the theme of Impossible Bug Week20:26
Sundarmelwitt: I am proposing a session for Cyborg/Nova to sort out os-acc. The main session could be in Cyborg time (Mon/Tue) and hopefully placement folks would attend. It may be helpful to get some time on Nova schedule as well to get everybody on board. What do you think?20:26
cdentsorry mriedem, I'm sort of afk: if it was was that patch from back in queens, then the twisted narrow passageways are way twisted and have a lot of explaining to do to say why it's only showing up now20:26
*** tzumainn has quit IRC20:27
melwittSundar: do you think we need two sessions? we could just join the monday or tuesday session since nova doesn't start until wednesday20:29
cdentmriedem: can you think of a way we could model the issue in a functional test? the feedback latency is hurting my head20:29
mriedemcdent: given the xen ci is now passing, i don't really know20:30
mriedemand why this isn't failing with the libvirt driver in master CI, again don't know20:31
cdentfun fun20:31
mriedemefried: we now have a new ERROR in the n-cpu logs on startup http://logs.openstack.org/98/584598/21/check/tempest-full/85acbda/controller/logs/screen-n-cpu.txt.gz?level=TRACE#_Aug_29_21_43_10_67502920:31
mriedemefried: b/c we hit ^ before the resource provider is created20:31
mriedemnew from https://review.openstack.org/#/c/584598/20:31
dansmithhmm, I got that disk not found one the other day locally20:32
dansmithI thought it was residue from my old machine20:32
dansmithis that because we're re-raising too?20:33
mriedemhttps://bugs.launchpad.net/nova/+bug/178999820:34
openstackLaunchpad bug 1789998 in OpenStack Compute (nova) "ResourceProviderAllocationRetrievalFailed ERROR log message on fresh n-cpu startup" [Low,Triaged]20:34
mriedemthe DiskNotFound during periodic is usually b/c we're deleting an instance on that host at the same time20:34
mriedemhttp://logs.openstack.org/98/584598/21/check/tempest-full/85acbda/controller/logs/screen-n-cpu.txt.gz#_Aug_29_21_51_13_05522520:35
dansmithokay this was on startup for me, which prevented it from every reporting initial inventory to placement20:35
mriedemright before the DiskNotFound20:35
mriedemAug 29 21:51:13.055225 ubuntu-xenial-rax-iad-0001643010 nova-compute[16853]: INFO nova.virt.libvirt.driver [None req-af17b138-d942-4bbf-bf67-4d03b492ed3c tempest-ImagesTestJSON-1980657675 tempest-ImagesTestJSON-1980657675] [instance: 21227895-e216-463f-8e76-998fe637bab2] Deletion of /opt/stack/data/nova/instances/21227895-e216-463f-8e76-998fe637bab2_del complete20:35
dansmithbut I had what I think was a stale disk image in my instances directory20:35
mriedemAug 29 21:51:13.167422 ubuntu-xenial-rax-iad-0001643010 nova-compute[16853]: ERROR nova.compute.manager [None req-6f4285cc-ce12-4c29-b879-99fdaaae59be None None] Error updating resources for node ubuntu-xenial-rax-iad-0001643010.: DiskNotFound: No disk at /opt/stack/data/nova/instances/21227895-e216-463f-8e76-998fe637bab2/disk20:35
dansmithnuking that fixed it, but I just had to do one more thing and then killed it all20:35
mriedemyeah on startup would be a different weirdness20:35
Sundarmelwitt: If we can settle everything in one session, that would be great. Given the quantum of reviews, we want to make sure that there is enough convergence to close the spec https://review.openstack.org/#/c/577438 after the PTG.20:37
SundarCould we keep a 30-minute placeholder?20:38
*** mugsie has joined #openstack-nova20:39
*** tzumainn has joined #openstack-nova20:40
mriedemso on the 2nd go around in the RT.update_available_resource in this xen CI run, we see the RT say the tracked compute node has changed:20:40
mriedemhttp://paste.openstack.org/show/729180/20:40
mriedemb/c of _copy_resources updating the *_allocation_ratio values to 0.020:40
mriedemAug 30 08:03:09.458344 dsvm-devstack-citrix-lon-nodepool-1379396 nova-compute[24292]: INFO nova.compute.resource_tracker [None req-9b1b9924-b89e-4a03-9a69-c9fff17594e3 None None] ComputeNode.cpu_allocation_ratio changed from 16.0 to 0.0 in _copy_resources.20:42
*** harlowja has joined #openstack-nova20:43
melwittSundar: 30-minute placeholder for monday or tuesday?20:44
melwittSundar: also, I think we should have the nova bits of the interaction proposed to nova-specs for review, that way we can more easily organize our review on that part20:46
*** tbachman has quit IRC20:46
Sundar30 min in Nova's schedule, anytime you want. Cyborg should allocate at least 1 hour on mon/tue.20:46
*** rmart04 has joined #openstack-nova20:47
SundarThe os-acc spec as a whole is Nova/Cyborg, so do we want another spec?20:47
melwittSundar: okay, so you're saying you think we need two sessions. I can try to find a 30-minute slot on our schedule20:48
melwittSundar: we need a nova spec for the proposed changes to the nova code, so the nova team can review those proposed changes20:48
Sundarmelwitt: Thanks a lot. OK, will propose a Nova spec too. BTW, I have been interacting a lot with efried and any Nova developer who gives feedback on os-acc spec.20:50
melwittnova meeting in 10 minutes20:50
melwittSundar: thanks20:50
mriedemcdent: just so you can rest easy tonight, i think we can safely confirm that we have some sort of weird multi-thread race with shared ProviderTree cache20:52
mriedemhttps://bugs.launchpad.net/nova/+bug/1789654/comments/920:52
openstackLaunchpad bug 1789654 in OpenStack Compute (nova) "placement allocation_ratio initialized with 0.0" [High,In progress] - Assigned to Matt Riedemann (mriedem)20:52
melwittmriedem: so _copy_resources is bypassing the compute node normalization routine?20:52
mriedemefried: ^20:53
mriedemmelwitt: yes, and from my log digging in that comment it shows that if we hit this in the right order, we call ComputeNode.save() which will change the CN.cpu_allocation_ratio from 0.0 (from _copy_resources) back to 16.020:53
cdentoh great, I love weird multi-thread races, especially when caches are involved20:53
mriedemwhich goes to the RT._normalize_inventory_from_cn_obj method which puts 16.0 back into the inventory dict20:53
melwittmriedem: ah, ok. nice sleuthing20:54
mriedembut there is clearly something else hitting ProviderTree.update_inventory at the same time that RT.update_available_resource is running20:54
*** takashin has joined #openstack-nova20:54
mriedemand i don't think it's coming from the RT20:54
mriedemthe only place in RT that we call ProviderTree.update_inventory is after driver.update_provider_tree, which isn't implemented for xen20:54
mriedemso i think it's the SchedulerReportClient's provider tree cache20:55
cdentI suspect (or at least hope) that efried will have some insight on the meanderings of the cache20:57
efriedI may, once I'm not trying to do several things at once.20:58
cdentefried: this seems to be an unfortunately common problem20:59
cdentlet's all quit20:59
cdent(that'll show em)20:59
mriedemmeeting in 1 min?20:59
melwittyes, I gave a 10 minute warning 9 minutes ago20:59
*** hamzy has quit IRC20:59
*** awaugama has quit IRC21:02
mriedemfar as i can tell the report client gets inventory like 500 times a second21:05
mriedemit calls _refresh_and_get_inventory *a lot*21:05
mriedemfor every _ensure_resource_provider21:05
mriedemwhere again, _ensure_resource_provider is less ensure and more "refresh the world" now21:05
openstackgerritMatt Riedemann proposed openstack/nova master: Log the operation when updating generation in ProviderTree  https://review.openstack.org/59755321:13
openstackgerritMatt Riedemann proposed openstack/nova master: Add debug logs for when provider inventory changes  https://review.openstack.org/59756021:13
openstackgerritMatt Riedemann proposed openstack/nova master: Add debug logs for when provider inventory changes  https://review.openstack.org/59756021:15
*** rmart04 has quit IRC21:16
*** dpawlik has quit IRC21:17
*** eharney has joined #openstack-nova21:17
openstackgerritDan Smith proposed openstack/nova master: WIP: Move conductor wait_until_ready() delay before manager init  https://review.openstack.org/59835321:18
dansmithmriedem: can we see if this helps? ^21:19
*** tbachman has joined #openstack-nova21:19
*** ttsiouts has quit IRC21:19
*** holser_ has joined #openstack-nova21:19
*** takashin has left #openstack-nova21:20
mriedemwe sure can21:20
*** ttsiouts has joined #openstack-nova21:20
*** ttsiouts has quit IRC21:20
*** ttsiouts has joined #openstack-nova21:20
mriedemi didn't know conductor_api.wait_until_ready existed21:21
mriedemso see, i did need you21:22
dansmithyou need better grep skills, that's all21:22
mriedemi even said in my patch after WPIing it something like "we should really wait until conductor is ready, but what makes it 'ready'"21:25
mriedemi guess this21:25
melwittwait_until_ready, of course21:25
melwitt(I didn't know about it either)21:25
mriedemConductorAPI.easy_button()21:25
mriedemwhat i'd like to do, del nova.compute.resource_tracker21:26
*** luksky11 has quit IRC21:28
melwittyou and jaypipes and bauzas and everyone else21:28
dansmithwell, so far that patch is doing super awesome in the gate21:29
*** tzumainn has quit IRC21:30
jaypipesdansmith: which patch?21:30
jaypipesdamn it, I've got more reading back to do...21:31
dansmithit's annoying that this didn't even capture some basic logs21:31
dansmithunless something else just broke real bad21:32
dansmith...which is the case, woot.21:35
*** holser_ has quit IRC21:37
*** ttsiouts has quit IRC21:37
*** ttsiouts has joined #openstack-nova21:40
* lbragstad hands mriedem https://plugins.jetbrains.com/plugin/7125-grep-console21:41
*** holser_ has joined #openstack-nova21:42
mriedemjebus h c21:42
lbragstadall the grep skillz you need is just one plugin away21:42
mriedemctrl+shift+f my man21:43
*** priteau has quit IRC21:47
efriedhow does a guy install a pycharm plugin?21:47
*** rcernin has joined #openstack-nova21:49
*** ttsiouts has quit IRC21:49
*** claudiub has quit IRC21:50
*** ttsiouts has joined #openstack-nova21:50
jaypipesefried: sudo apt install vim?21:51
lbragstadgit clone https://github.com/$USER/dotfiles21:51
efriedfound it. Thanks for nothing, snarks21:53
zigojaypipes: Real man use joe editor ...21:54
*** dpawlik has joined #openstack-nova21:54
*** dpawlik has quit IRC21:59
jaypipeszigo: luckily, I'm not a real man.21:59
dansmithmriedem: so should I just make up a fake test for that so we can merge and see if the problem goes away? presumably that's the only way we're really going to know?22:00
*** cfriesen has quit IRC22:04
mriedemdansmith: is it passing in the gate?22:04
mriedemif so, yeah sure22:05
openstackgerritMatt Riedemann proposed openstack/nova master: Avoid spurious ComputeNode.save during update_available_resource periodic  https://review.openstack.org/59836522:05
mriedemefried: melwitt: ^ is a thing related to that xen bug22:05
mriedemfor allocation ratios22:05
mriedemsince i'm not sure how we're actually racing here, i'm not sure if it will actually fix it,22:05
melwittack22:06
mriedembut it's about the only thing i can think of that would get us this which f's up the inventory in placement during the periodic:22:06
mriedemAug 29 16:58:05.483508 dsvm-devstack-citrix-mia-nodepool-1379368 nova-compute[24436]: INFO nova.compute.resource_tracker [None req-a869fa19-aa9d-4335-9816-42ff29b64d48 None None] Using cpu_allocation_ratio 0.0 for node: 2f5a2e04-1b61-4437-ab6e-8dbbf797dc0722:06
efriedmriedem: Doesn't seem to be doing what the commit title says...22:06
mriedemthat's logs from the normalize method in the RT22:06
dansmithmriedem: it's passing the stuff that isn't dead on the floor for other reasons22:07
mriedemefried: oh but you must read the full message my friend22:07
mriedemit's a rich tapestry of suck22:07
efriedyeah yeah22:07
mriedemand with that, i'm putting my lawn mowin' clothes on and hitting nature22:07
efriedI don't see it hurting anything to never write 0.0 to an allocation ratio.22:07
efriedunless, as you say, some other suckpoint is using that as a signal to refresh the real values from somewhere else.22:08
mriedemright, i don't think this hurts, it might help22:08
efriedIn which case that should be change.22:08
efriedd22:08
mriedemexcept i have that todo in there - mostly a question for reviewers to check my brain22:08
openstackgerritDan Smith proposed openstack/nova master: Move conductor wait_until_ready() delay before manager init  https://review.openstack.org/59835322:10
*** purplerbot has quit IRC22:16
*** purplerbot has joined #openstack-nova22:17
*** mriedem is now known as mriedem_lawnboy22:17
jaypipesmriedem_lawnboy, efried: prescient? https://review.openstack.org/#/c/598365/1/nova/tests/unit/compute/test_resource_tracker.py@138122:26
efriedMm22:27
efriedI thought it was a bug in the test.22:27
efriedClearly not.22:27
*** holser_ has quit IRC22:30
openstackgerritEric Fried proposed openstack/nova master: Fix nits: Compute: Handle reshaped provider trees  https://review.openstack.org/59838722:37
*** ttsiouts has quit IRC22:49
*** ttsiouts has joined #openstack-nova22:50
*** ttsiouts has quit IRC22:54
*** eharney has quit IRC22:59
*** macza has quit IRC23:08
*** cdent has quit IRC23:22
*** erlon has joined #openstack-nova23:27
*** mlavalle has quit IRC23:34
*** r-daneel has quit IRC23:36
*** rcernin has quit IRC23:56
*** rcernin has joined #openstack-nova23:56

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