Wednesday, 2018-08-29

*** macza has joined #openstack-nova00:33
*** macza has quit IRC00:37
*** gyee has quit IRC00:42
openstackgerritMatt Riedemann proposed openstack/nova master: Retry on MessagingTimeout to init compute RPC API during n-cpu start  https://review.openstack.org/59733000:44
*** mriedem has quit IRC00:44
openstackgerritMatt Riedemann proposed openstack/nova master: Retry on MessagingTimeout to init compute RPC API during n-cpu start  https://review.openstack.org/59733000:46
openstackgerritMatt Riedemann proposed openstack/nova master: Retry on MessagingTimeout to init compute RPC API during n-cpu start  https://review.openstack.org/59733000:48
*** tetsuro has joined #openstack-nova00:52
*** liuyulong has joined #openstack-nova00:56
*** donghm has joined #openstack-nova01:02
*** itlinux is now known as itlinux-away01:09
*** alex_xu has joined #openstack-nova01:14
*** fungi has quit IRC01:18
*** imacdonn has quit IRC01:18
*** fungi has joined #openstack-nova01:19
*** imacdonn has joined #openstack-nova01:19
*** odyssey4me has quit IRC01:19
*** dosaboy has quit IRC01:19
*** zioproto has quit IRC01:19
*** beagles has quit IRC01:19
*** dtantsur|afk has quit IRC01:19
*** beagles has joined #openstack-nova01:19
*** odyssey4me has joined #openstack-nova01:20
*** itlinux-away is now known as itlinux01:21
*** dtantsur has joined #openstack-nova01:22
*** itlinux is now known as itlinux-away01:22
*** gbarros has joined #openstack-nova01:22
*** itlinux-away is now known as itlinux01:24
*** itlinux is now known as itlinux-away01:24
*** yonglihe has quit IRC01:25
*** Bhujay has joined #openstack-nova01:25
*** yonglihe has joined #openstack-nova01:25
*** itlinux-away is now known as itlinux01:27
*** itlinux is now known as itlinux-away01:27
*** itlinux-away is now known as itlinux01:28
*** itlinux is now known as itlinux-away01:29
*** dpawlik has joined #openstack-nova01:29
*** dpawlik has quit IRC01:33
*** erlon has quit IRC01:35
*** Dinesh_Bhor has joined #openstack-nova01:45
*** hongbin has joined #openstack-nova01:48
*** ujjain has quit IRC01:49
*** pas-ha has quit IRC01:49
*** simondodsley_ has quit IRC01:49
*** ianw has quit IRC01:49
*** johanssone has quit IRC01:49
*** andreykurilin has quit IRC01:49
*** zigo has quit IRC01:49
*** spsurya has quit IRC01:49
*** jbernard has quit IRC01:49
*** geekinutah has quit IRC01:49
*** rm_work has quit IRC01:49
*** jbernard has joined #openstack-nova01:49
*** andreykurilin has joined #openstack-nova01:49
*** itlinux-away is now known as itlinux01:51
*** itlinux is now known as itlinux-away01:51
*** ccdevil has joined #openstack-nova01:52
*** ujjain has joined #openstack-nova01:53
*** ianw has joined #openstack-nova01:53
*** rm_work has joined #openstack-nova01:55
*** bhagyashris has joined #openstack-nova01:56
*** ccdevil has left #openstack-nova01:57
*** lei-zh has joined #openstack-nova01:57
*** Dinesh_Bhor has quit IRC01:58
*** lei-zh has quit IRC02:00
*** lei-zh has joined #openstack-nova02:00
*** itlinux-away is now known as itlinux02:01
*** ianw has quit IRC02:03
*** ianw has joined #openstack-nova02:04
*** vishakha has quit IRC02:08
*** Dinesh_Bhor has joined #openstack-nova02:09
*** itlinux is now known as itlinux-away02:11
*** psachin has joined #openstack-nova02:16
*** hamzy has quit IRC02:17
*** hamzy has joined #openstack-nova02:18
*** itlinux-away is now known as itlinux02:29
*** itlinux is now known as itlinux-away02:29
*** sapd1 has joined #openstack-nova02:34
*** openstack has joined #openstack-nova02:51
*** zzzeek has joined #openstack-nova02:52
*** ChanServ sets mode: +o openstack02:52
*** itlinux-away is now known as itlinux02:53
*** itlinux is now known as itlinux-away02:53
*** itlinux-away is now known as itlinux02:54
*** manjeets has quit IRC02:55
*** dtroyer has joined #openstack-nova02:57
*** jhesketh has joined #openstack-nova02:57
*** openstackstatus has joined #openstack-nova03:01
*** ChanServ sets mode: +v openstackstatus03:01
*** psachin has quit IRC03:13
*** bhagyashris has quit IRC03:14
*** psachin has joined #openstack-nova03:14
*** hongbin has quit IRC03:51
*** Dinesh_Bhor has quit IRC03:52
*** spsurya has joined #openstack-nova03:53
*** nicolasbock has quit IRC03:58
*** udesale has joined #openstack-nova03:59
*** tetsuro has quit IRC04:04
*** tetsuro has joined #openstack-nova04:26
*** dpawlik has joined #openstack-nova04:29
*** Dinesh_Bhor has joined #openstack-nova04:31
*** dpawlik has quit IRC04:49
*** dpawlik has joined #openstack-nova04:50
*** dpawlik has quit IRC04:56
*** tetsuro has quit IRC05:04
*** janki has joined #openstack-nova05:09
*** itlinux has quit IRC05:31
*** ratailor has joined #openstack-nova05:35
*** macza has joined #openstack-nova05:36
*** macza has quit IRC05:40
*** maciejjozefczyk has joined #openstack-nova05:40
*** maciejjozefczyk has quit IRC05:41
*** hongda has joined #openstack-nova05:44
*** hongda has quit IRC05:45
*** alexchadin has joined #openstack-nova05:47
*** links has joined #openstack-nova05:48
*** Luzi has joined #openstack-nova05:51
openstackgerritzhangyangyang proposed openstack/nova master: Replace assertRaisesRegexp with assertRaisesRegex  https://review.openstack.org/59737805:54
*** dpawlik has joined #openstack-nova06:01
*** ccamacho has joined #openstack-nova06:03
*** dpawlik has quit IRC06:03
*** dpawlik has joined #openstack-nova06:03
*** dpawlik has quit IRC06:04
*** dpawlik has joined #openstack-nova06:04
*** BlackDex has joined #openstack-nova06:05
*** udesale has quit IRC06:07
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: [placement] Use osloutils uuidsentinel  https://review.openstack.org/59414406:15
*** sahid has joined #openstack-nova06:18
*** alexchadin has quit IRC06:26
*** alexchadin has joined #openstack-nova06:33
*** adrianc has joined #openstack-nova06:35
*** markvoelker has joined #openstack-nova06:39
openstackgerritTakashi NATSUME proposed openstack/nova master: Fix a broken conf file description in networking doc  https://review.openstack.org/59739106:47
*** kashyap has joined #openstack-nova06:47
*** takashin has left #openstack-nova06:48
*** pcaruana has joined #openstack-nova06:50
*** maciejjozefczyk has joined #openstack-nova06:52
*** tssurya has joined #openstack-nova06:53
*** udesale has joined #openstack-nova06:55
*** rcernin has quit IRC07:00
*** maciejjozefczyk has quit IRC07:11
*** maciejjozefczyk has joined #openstack-nova07:13
*** takamatsu has quit IRC07:16
*** ratailor_ has joined #openstack-nova07:19
*** ratailor has quit IRC07:20
*** moshele has joined #openstack-nova07:20
moshelestephenfin: hi, can you review https://review.openstack.org/#/c/595592/ ?07:21
*** udesale has quit IRC07:31
*** crazik has left #openstack-nova07:32
*** ttsiouts has joined #openstack-nova07:45
*** ttsiouts has quit IRC07:49
*** threestrands has quit IRC07:50
*** jpena|off is now known as jpena07:51
*** zigo has joined #openstack-nova07:56
openstackgerritMerged openstack/nova master: Mention (unused) RP generation in POST /allocs/{c}  https://review.openstack.org/59730407:57
stephenfinmoshele: I can08:07
openstackgerritStephen Finucane proposed openstack/nova stable/rocky: Don't use '_TransactionContextManager._async'  https://review.openstack.org/59742108:08
stephenfinefried: For when you're about https://review.openstack.org/59742108:09
*** owalsh_ is now known as owalsh08:10
*** ccamacho has quit IRC08:13
*** ccamacho has joined #openstack-nova08:14
*** ttsiouts has joined #openstack-nova08:16
*** alexchadin has quit IRC08:27
*** cdent has joined #openstack-nova08:39
*** Dinesh_Bhor has quit IRC08:51
*** ccamacho has quit IRC08:55
*** ccamacho has joined #openstack-nova08:56
*** Dinesh_Bhor has joined #openstack-nova08:56
*** dpawlik has quit IRC09:03
*** dpawlik has joined #openstack-nova09:04
stephenfinmoshele: Picked myself up a connect x-4 NIC and things are slightly...different to what I'm used to09:05
stephenfinmoshele: I'm seeing "No net device was found for VF xxx" in the logs. I assume there's something I need to do to resolve this?09:05
*** Bhujay has quit IRC09:10
kosamaraefried: I'm here now09:11
*** moshele has quit IRC09:12
*** moshele has joined #openstack-nova09:15
openstackgerritMerged openstack/nova master: [placement] Add /reshaper handler for POST  https://review.openstack.org/57692709:22
openstackgerritMerged openstack/nova master: Document no content on POST /reshaper 204  https://review.openstack.org/59649409:22
*** dpawlik has quit IRC09:24
*** maciejjozefczyk has quit IRC09:25
*** dpawlik has joined #openstack-nova09:28
*** maciejjozefczyk has joined #openstack-nova09:28
*** moshele has quit IRC09:28
*** holser_ has joined #openstack-nova09:30
openstackgerrithuanhongda proposed openstack/nova master: List soft-deleted instances by "--status" option  https://review.openstack.org/59743409:31
*** priteau has joined #openstack-nova09:46
*** kosamara has quit IRC09:50
*** sambetts_ is now known as sambetts|afk09:51
*** udesale has joined #openstack-nova09:52
*** mdbooth has joined #openstack-nova09:55
mdboothlyarwood: Do you happen to remember why we're running qemu-img on volumes?09:55
mdboothlyarwood: I'm assuming that's the context of the MIN_LIBVIRT_MULTIATTACH thing?09:55
*** adrianc has quit IRC09:57
lyarwoodmdbooth: I'm not sure that we are on volumes, I just assumed the MIN_LIBVIRT_MULTIATTACH downstream thing we were talking about was just a locking bug between two domains using the same disk etc09:59
*** kosamara has joined #openstack-nova09:59
*** ttsiouts has quit IRC10:07
mdboothlyarwood: Ok, so it's not just qemu-img?10:12
*** davidsha has joined #openstack-nova10:14
*** adrianc has joined #openstack-nova10:14
*** ratailor_ has quit IRC10:23
*** psachin has quit IRC10:28
*** adrianc_ has joined #openstack-nova10:34
*** adrianc has quit IRC10:34
*** moshele has joined #openstack-nova10:38
openstackgerritChen proposed openstack/nova master: Fix filter servers with SOFT_DELETED status  https://review.openstack.org/59744310:40
*** moshele has quit IRC10:46
*** hshiina has joined #openstack-nova10:46
openstackgerritBalazs Gibizer proposed openstack/nova-specs master: Placement: any traits in allocation_candidate query  https://review.openstack.org/56573010:46
openstackgerritBalazs Gibizer proposed openstack/nova-specs master: Placement: support mixing required traits with any traits  https://review.openstack.org/56574110:46
openstackgerritRadoslav Gerganov proposed openstack/nova master: doc: add info how to troubleshoot vmware specific problems  https://review.openstack.org/59744610:49
*** maciejjozefczyk has quit IRC10:49
*** dave-mccowan has joined #openstack-nova10:50
*** maciejjozefczyk has joined #openstack-nova10:58
*** maciejjozefczyk has quit IRC10:59
*** macza has joined #openstack-nova11:01
*** udesale has quit IRC11:04
*** macza has quit IRC11:06
*** Dinesh_Bhor has quit IRC11:08
*** brinzhang has quit IRC11:09
*** nicolasbock has joined #openstack-nova11:11
*** lpetrut has joined #openstack-nova11:13
*** maciejjozefczyk has joined #openstack-nova11:16
*** ttsiouts has joined #openstack-nova11:20
*** dpawlik has quit IRC11:21
*** Dinesh_Bhor has joined #openstack-nova11:31
*** Dinesh_Bhor has quit IRC11:31
*** moshele has joined #openstack-nova11:37
*** jpena is now known as jpena|lunch11:37
openstackgerritBalazs Gibizer proposed openstack/nova master: Transform missing delete notifications  https://review.openstack.org/41029711:40
openstackgerritBalazs Gibizer proposed openstack/nova master: Send soft_delete from context manager  https://review.openstack.org/47645911:40
openstackgerritMerged openstack/nova master: Refix disk size during live migration with disk over-commit  https://review.openstack.org/53635111:42
openstackgerritMerged openstack/nova master: Fix a broken conf file description in networking doc  https://review.openstack.org/59739111:42
*** alex_xu has quit IRC11:49
*** fanzhang_ has quit IRC11:50
openstackgerritJay Pipes proposed openstack/os-traits master: clean up CUDA traits  https://review.openstack.org/59717011:54
*** vivsoni has quit IRC11:58
kosamarajaypipes: I think a sentence spilled over11:58
jaypipeskosamara: crap.11:58
kosamaraI'm doing a change inline11:58
*** vivsoni has joined #openstack-nova11:59
openstackgerritJay Pipes proposed openstack/os-traits master: clean up CUDA traits  https://review.openstack.org/59717011:59
jaypipeskosamara: done :)12:00
openstackgerritKonstantinos Samaras-Tsakiris proposed openstack/os-traits master: clean up CUDA traits  https://review.openstack.org/59717012:03
kosamarajaypipes: ok?12:04
*** vivsoni has quit IRC12:05
jaypipeskosamara: ty sir!12:05
jaypipeskosamara: I must have badly fat-fingered the copy-paste in vim! :)12:05
*** vivsoni has joined #openstack-nova12:05
*** vivsoni has quit IRC12:06
*** janki has quit IRC12:06
kosamarahaha!12:06
*** vivsoni has joined #openstack-nova12:07
*** ccamacho has quit IRC12:07
*** ccamacho has joined #openstack-nova12:09
*** beagles has quit IRC12:12
*** beagles has joined #openstack-nova12:13
*** dpawlik has joined #openstack-nova12:14
*** udesale has joined #openstack-nova12:14
*** udesale has quit IRC12:16
*** udesale has joined #openstack-nova12:19
*** udesale has quit IRC12:19
*** udesale has joined #openstack-nova12:28
*** udesale has quit IRC12:28
*** janki has joined #openstack-nova12:30
*** udesale has joined #openstack-nova12:31
*** mchlumsky has joined #openstack-nova12:35
*** erlon has joined #openstack-nova12:36
*** mriedem has joined #openstack-nova12:42
openstackgerritChris Dent proposed openstack/nova master: DNM: [placement] Make _ensure_aggregate context not independent  https://review.openstack.org/59748612:42
*** jpena|lunch is now known as jpena12:46
*** eharney has joined #openstack-nova12:47
*** awaugama has joined #openstack-nova12:48
moshelemriedem: can you review https://review.openstack.org/#/c/595592/ ? we update the macvtap and SR-IOV CIs with the rx_queue_size/tx_queue_size and they both passing with this patch12:53
zigoI'm currently trying to validate Rocky Debian packages.12:56
zigoWhen I try to boot a new instance, I got the scheduler spitting in the logs:12:57
zigoGot no allocation candidates from the Placement API. This could be due to insufficient resources or a temporary occurrence as compute nodes start up. select_destinations /usr/lib/python3/dist-packages/nova/scheduler/manager.py:15012:57
zigoWhat should I look into then?12:57
zigoI normally do have enough resources on that machine ...12:57
zigojaypipes: ^ Help ? :)12:57
zigoIs there a placement client somehow?12:58
*** ccamacho has quit IRC12:58
*** ccamacho has joined #openstack-nova12:59
*** dtantsur is now known as dtantsur|bbl13:04
openstackgerritChen proposed openstack/nova master: Fix filter server list with SOFT_DELETED status  https://review.openstack.org/59744313:04
*** pcaruana has quit IRC13:04
cdentzigo: there's an osc-placement plugin for the openstack client13:15
cdentzigo: did you do a discover_hosts?13:15
cdentbut more likely it sounds like your compute node hasn't reported resources yet13:16
cdent'openstack resource provider list' might work13:16
zigocdent: It's puppet-openstack that I'm running, so normally, yeah ...13:16
cdents/work/provide some insight/13:16
zigoThanks, trying.13:16
zigocdent: So, I should package that osc-placement in Debian then?13:17
mriedemhttps://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-list13:17
mriedempackaging osc-placement would be nice for anyone that wants to deploy nova yeah13:17
mriedemscheduling in nova has been critically dependent on placement since ocata13:17
mriedemif this is a single-node setup, there should be 1 resource provider for the compute node13:18
zigodiscover_host was ran, so that's not the issue.13:18
zigoI'm doing the packaging right away for placement client.13:18
zigoWhy was it called osc-placement, rather than python-placementclient btw?13:19
mriedemb/c it's an openstack client plugin13:19
mriedemand that's the naming convention13:19
mriedemit's not a python API binding / sdk type thing like novaclient13:19
zigomriedem: So it will be renamed once placement is extracted from Nova?13:20
mriedemno13:20
mriedemit's only cli, not any python bindings13:20
zigook13:20
mriedemthere is no python binding client for placement, maybe openstacksdk is working on one, would have to ask mordred or edleafe13:20
mriedemi don't see a placement dir in the sdk yet https://github.com/openstack/openstacksdk/tree/master/openstack13:24
mriedemnot sure about plans for one though13:24
zigoFYI, I don't bother doing py2 clients anymore. :)13:26
zigosphinx>=1.2.1,!=1.3b1,<1.4 # BSD <--- test-requirements.txt needs upgrade ...13:27
zigo:P13:27
*** ttsiouts has quit IRC13:34
mriedemtest-reqs in osc-placement?13:36
zigoyep13:36
mriedemplease report a bug https://bugs.launchpad.net/placement-osc-plugin13:37
edleafemriedem: AFAIK that is not being worked on13:38
mriedemedleafe: yeah i didn't see any open reviews13:38
*** ttsiouts has joined #openstack-nova13:40
openstackgerritMatt Riedemann proposed openstack/osc-placement master: Random names for functional tests  https://review.openstack.org/54274513:43
zigohttps://bugs.launchpad.net/placement-osc-plugin/+bug/178964913:45
openstackLaunchpad bug 1789649 in placement-osc-plugin "test-requirements out of date" [Undecided,New]13:45
mriedemzigo: thanks13:45
zigomriedem: Now that I have the package built and installed, how do I test if placement has resources ?13:46
mriedemas an admin,13:47
mriedemopenstack resource provider lst13:47
mriedem*list13:47
zigoOk, found my host, then?13:47
zigoShow it?13:48
mriedeminventory is more useful13:48
zigoHum... not much thing shows up then...13:48
mriedemopenstack resource provider inventory show <rp_uuid>13:48
mriedemoh wait13:48
mriedemopenstack resource provider inventory list <rp_uuid>13:48
mriedemhttps://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-inventory-list13:48
mriedemyou should see VCPU, MEMORY_MB and DISK_GB13:49
zigoIt works...13:49
zigohttp://paste.openstack.org/show/729051/13:49
zigoBut then? How come placement didn't find resources?13:49
mriedemlet's make sure the compute node in nova is matching that same uuid13:50
mriedemfrom nova cli,13:50
mriedemas admin,13:50
mriedemnova hypervisor-list13:50
zigoI see my host, and it's up and enabled.13:50
zigoI did all this before asking! :P13:50
mriedemdoes it's id equal f9716941-356f-4a2e-b5ea-31c3c1630892 ?13:51
zigoYup.13:51
mriedemok what type of flavor did you use when you tried creating the server?13:51
zigoIs it normal that I get allocation_ratio 0.0 for all resources?13:51
mriedemso,13:51
mriedemthat sounds exactly like the same problem the xenserver CI guys are having in the ML right now13:51
mriedemand no,13:51
mriedemcpu should be 16.0,13:52
zigo256 RAM, 5 GB HDD, 1 VCPU13:52
mriedemram and disk should also be > 013:52
mriedemjaypipes: efried: naichuans: ^13:52
*** markvoelker has quit IRC13:53
mriedemzigo: using libvirt right?13:53
zigomriedem: Yeah, normal qemu in a virtualbox right now.13:54
zigomriedem: Also using it in the OpenStack CI with puppet-openstack stuff ...13:54
zigomriedem: Is there a way to force something in the allocation_ratio to fix things?13:55
mriedemyes via osc-placement, but i'd have to look it up quick13:55
*** lbragstad has quit IRC13:56
mriedemhttps://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-inventory-class-set13:56
mriedemso: openstack resource provider inventory class set --allocation_ratio 16.0 --total 4 f9716941-356f-4a2e-b5ea-31c3c1630892 VCPU13:56
mriedemcdent: ever remember talking about making allocation_ratio a minimum of 1.0 in placement?13:57
mriedemallowing anything to set that to 0.0 seems like a bad idea13:57
*** dtantsur|bbl is now known as dtantsur13:58
gibimriedem: having < 1.0 could make sense for handling overhead, but I agree that 0.0 doesn't make sense13:59
zigomriedem: The max_unit for VCPUs looks funny now: http://paste.openstack.org/show/729052/13:59
cdentmriedem: the only vague tickle I have in my mind was "if you have a float, how do you set a min_unit that is the min-est"13:59
zigoShouldn't it be num-of-vcpu * allocation_ratio ?13:59
cdentWhat i'm not clear on is how/what is coming along with these 0s13:59
*** Luzi has quit IRC13:59
mriedemcdent: i guess it couldn't be done with jsonschema and would have to be in python14:00
mriedemif allocation_ratio <= 0.0: 40014:00
mriedemor use a custom jsonschema validator14:00
zigoCan I consider there's a bug somewhere, and wait for the fix? :)14:00
mriedemso clearly something in nova is creating resource providers with 0.0 allocation ratios from nova.conf, which is the default, but it should be getting the values from the ComputeNode object14:00
cdentI can't remember any specific conversation about this, but I wonder if 0 was allowed as a way to disable inventory?14:01
mriedemzigo: yes14:01
mriedemzigo: naichuans: if you haven't already, it would be great to have a nova bug for tracking this14:01
cdent(while still keeping a record of the "actual" inventory)14:01
mriedemyeah idk, maybe jaypipes remmebers14:01
mriedemso https://github.com/openstack/nova/blob/6522ea3ecfe99cca3fb33258b11e5a1f34e6e8f0/nova/compute/resource_tracker.py#L84 in the RT is what is supposed to set the default allocation ratio for each inventory on the compute node provider14:02
*** knikolla has joined #openstack-nova14:02
mriedemassuming the virt driver doesn't provide an allocation ratio override, which neither libvirt nor xenapi do14:02
zigomriedem: cdent: What is max_unit supposed to represent? Isn't it total * allocation_ratio?14:02
jaypipesmriedem: sorry, reading back was on a call14:02
cdentzigo: no, it is an expression of the largest amount any individual resource allocation can allocate14:02
jaypipeszigo: max_unit is not total * allocation_ratio, no14:02
cdentso in the case of something like disk or vcpu it is generally the max physical amount14:03
cdentas you don't want a single instance to have more than is physically available, regardless of allocation ratio14:03
zigoAh, great, meaning I can have hosts with up to 2 billion VCUPs ! :)14:03
zigoI can start writing another bug, ok.14:04
cdenttotal: the real physical amount, allocation ratio: multiplier for over or under commit, min_unit: smallest individual request, max_unit: largest individual request, reserved: what the system is using for itself14:04
mriedemi wonder if there is a bug in ProviderTree.update_inventory where it's not updating the allocation_ratio when we create/update the provider in placement14:06
mriedemzigo: you're testing with rocky right?14:07
*** lbragstad has joined #openstack-nova14:07
*** mlavalle has joined #openstack-nova14:08
zigohttps://bugs.launchpad.net/nova/+bug/178965414:10
openstackLaunchpad bug 1789654 in OpenStack Compute (nova) "placement allocation_ratio initialized with 0.0" [Undecided,New]14:10
zigomriedem: Correct !14:10
zigomriedem: Fresh packages just built this and last week in a record time.14:11
zigoIt took me less than 2 weeks, this time ... :P14:11
openstackgerritMerged openstack/osc-placement master: Update reno for stable/rocky  https://review.openstack.org/58611514:11
mriedemso i thought we used to log something when inventory changed on a provider...14:13
mriedemnot seeing that14:13
mriedemfrom one of the failed xenserver ci logs, the RP is created here http://logs.openstack.org/41/590041/17/check/tempest-full/b3f9ddd/controller/logs/screen-n-cpu.txt.gz#_Aug_27_14_18_25_58051714:13
mriedemthen the generation changes twice but we don't log why14:14
zigomriedem: If you want the full logs and everything, you can find it here: https://review.openstack.org/#/c/597175/14:14
mriedemany of those failed jobs?14:14
zigoThat commit just switches repo from queens to rocky for Debian and puppet-openstack.14:14
zigoYep.14:15
zigoThe first one for example.14:15
mriedemyup so in this case we create the RP here http://logs.openstack.org/75/597175/1/check/puppet-openstack-integration-4-scenario001-tempest-debian-stable-luminous/fd38fcf/logs/nova/nova-compute.txt.gz#_2018-08-28_17_09_40_68614:15
mriedemhere we POST to placement http://logs.openstack.org/75/597175/1/check/puppet-openstack-integration-4-scenario001-tempest-debian-stable-luminous/fd38fcf/logs/nova/nova-placement-api.txt.gz#_2018-08-28_17_09_40_68314:16
zigomriedem: What I can do is artificially change the default 0.0 allocation ratio in the package. Would you advise me to do that?14:16
mriedemhere we add inventory http://logs.openstack.org/75/597175/1/check/puppet-openstack-integration-4-scenario001-tempest-debian-stable-luminous/fd38fcf/logs/nova/nova-placement-api.txt.gz#_2018-08-28_17_09_40_79414:17
mriedemzigo: i would probably not recommend that at this time no14:18
mriedemi personally would like to figure out what we're dealing with first14:18
cdentagreed14:18
cdentas far as I can tell the nova-compute is never logging when it sets inventory?14:18
mriedemno, it used to14:18
openstackgerritMerged openstack/osc-placement master: Add image link in README.rst  https://review.openstack.org/58683914:20
efriedstephenfin: Done (though I'm not a stable core): https://review.openstack.org/59742114:20
stephenfinefried: Ah, indeed. Good enough though14:20
dansmithmriedem: we did discuss having the compute node not override the allocation ratio set on a provider, only use that value when creating it14:21
dansmithdid that ever happen?14:21
dansmithI don't see those extra values in conf/compute14:22
mriedemi don't remember that happening no14:22
dansmithhttps://review.openstack.org/#/c/552105/14:22
mriedemyup, i have unanswered questions in there14:23
dansmithyep, just offering evidence that it didn't14:23
mriedemefried: would be helpful if provider tree's _update_generation method took an "operation" param or something,14:24
mriedemi.e. we're updating the generation b/c inventory was updated or something14:24
sean-k-mooneymriedem: i might add a live migration item to the nova-neutron ptg slot.14:24
sean-k-mooneymriedem: i have stated to address the neutron bugs i have found but looks like there are other nova ones too14:24
efriedkosamara: I started going through the spec to make some content, but found it's really going to be easier if we can both post our updates to gerrit.14:24
efriedkosamara: I also wanted to know how much you'd looked at the cyborg project, if at all.14:25
mriedemzigo: let me know if/when you have a nova bug posted and i can push some debug patches14:25
mriedemso,14:25
efriedmriedem: I would expect the report client side to be logging what it's doing there.14:26
zigomriedem: Yeah, here: https://bugs.launchpad.net/nova/+bug/178965414:26
openstackLaunchpad bug 1789654 in OpenStack Compute (nova) "placement allocation_ratio initialized with 0.0" [Undecided,New]14:26
mriedemmy guess is that update_from_provider_tree is somehow not pushing inventory changes which include the updated allocation_ratio b/c of a cache14:26
openstackgerritMerged openstack/osc-placement master: Resource provider examples  https://review.openstack.org/55346114:26
zigomriedem: I can add some debian specific patches to my package, and rerun puppet, if you like.14:26
efriedmriedem: Ahem, libvirt's update_provider_tree is not setting allocation ratio.14:27
mriedemefried: i know14:27
mriedemthe RT does14:27
mriedemsee the _normalize method14:27
efriedno14:27
zigoRT stands for what?14:27
mriedemResourceTracker14:27
efriedthat doesn't get run if you implemented update_provider_tree14:27
mriedemsure it does14:27
efriedThat said, it should be getting defaulted to 1.0, per handler/inventory14:27
mriedemhttps://github.com/openstack/nova/blob/6522ea3ecfe99cca3fb33258b11e5a1f34e6e8f0/nova/compute/resource_tracker.py#L90114:27
mriedemand we don't log anything in the report client when we go to flush provider tree inventory changes if the provider tree doesn't think inventory has changed14:28
efriedoh wtf...14:28
efriedI totally traced this exact thing like last week and was sure we weren't hitting that. /me needs to rework a thing...14:28
mriedemif we didn't call _normalize_inventory_from_cn_obj in this case, libvirt/xen/ironic wouldn't ever have allocation_ratio or reserved values set14:28
*** moshele has quit IRC14:29
mriedemand it looks like in some racey cases we never update the inventory b/c the provider tree cache never thinks there is a change14:29
openstackgerritKonstantinos Samaras-Tsakiris proposed openstack/nova-specs master: Placement model for passthrough devices  https://review.openstack.org/59103714:29
efriededmondsw: Redundant goofy code alert --^14:29
kosamaraefried: No problem, we'll coordinate.14:30
efriedmriedem: Are you saying it's "normal" for us to set alloc ratio to 0.0 for a sec, because we expect the next update to hit _normalize and then push the updated inventory?14:32
kosamaraefried: I had looked at Cyborg in spring, but haven't been following it since. The primary use case that I saw Cyborg enabling was FPGA function-aaS.14:32
mriedemefried: i don't know what is pushing the initial inventory data14:32
efriedkosamara: Yes, that's kind of the initial motivator, but the project is supposed to subsume all device management.14:32
mriedemso i can't really say14:32
mriedemwe don't log anything14:32
mriedemso i'm going to push some debug patches so we can .... debug14:33
efriedack, let me know if I can help.14:33
mriedemmy guess is the local provider tree cache is current but remote is not, and we never update14:33
efriedmriedem: Well, looking at has_inventory_changed, it *should* be paying attention to alloc ratio updates, whether the field exists and is being changed, or doesn't exist and is being added.14:39
*** maciejjozefczyk has quit IRC14:39
efriedand has_inventory_changed being false is the only way we would avoid sending the update down to placement.14:40
efried...barring actual errors which we would see in the compute log14:40
openstackgerritMatt Riedemann proposed openstack/nova master: Log the operation when updating generation in ProviderTree  https://review.openstack.org/59755314:43
efriedmriedem: FYI: http://paste.openstack.org/show/729053/  <== looks fine.14:44
*** markvoelker has joined #openstack-nova14:44
*** lpetrut has quit IRC14:45
kosamaraefried: Does that mean that instead of proposing improvements to the way Nova manages devices, we should contribute this functionality to Cyborg, because in the future Cyborg will have exclusive responsibility in that domain?14:47
efriedkosamara: Well, that's what needs to be discussed, really.14:47
efriedI am pretty far behind on the massive volume of cyborg specs that are out there14:47
efriedbut I haven't yet seen one where they deal with discovery and whitelisting.14:48
kosamaraefried: I was going to ask if you have any pointers to similar work there14:48
efriedIt's entirely likely that they've got that proposed and I just haven't gotten to it yet.14:48
kosamaraand modelling in Placement with RPs?14:48
efriedoh, yes, that's definitely their plan.14:48
*** sahid has quit IRC14:49
efriedI'm going to try to ask about it in #openstack-cyborg, if you'd like to join me there.14:49
kosamaraBut can Cyborg create RPs now, or it has to happen through nova, like neutron does in the network bandwidth providers spec?14:49
kosamaraok14:49
*** pcaruana has joined #openstack-nova14:50
efriedkosamara: Yeah, that's the question. The providers are intended to be created and "owned" by cyborg code, but I'm still not 100% clear whether that's at the behest/prompting of a nova flow or totally independent.14:50
efriedkosamara: Because obviously somebody has to coordinate those device RPs being parented to the compute node RP.14:51
openstackgerritSurya Seetharaman proposed openstack/nova master: Making instance listing skipping down cells configurable  https://review.openstack.org/59242814:54
openstackgerritMatt Riedemann proposed openstack/nova master: Add debug logs for when provider inventory changes  https://review.openstack.org/59756014:56
mriedemnaichuans: efried: cdent: jaypipes: zigo: ^ hopefully we can learn something from this14:56
mriedemzigo: i updated your patch with a depends-on to that nova change14:57
efriedmriedem: dig14:57
cdentmriedem: do we have a way of setting our test environments so they are more like what zigo and naichuans were experiencing? because apparently our test environments are configuring too much to reflect reality?14:57
mriedemcdent: xenserver ci uses devstack14:58
mriedemit's pretty stock outside of saying use the xen driver rather than libvirt14:58
zigomriedem: cdent: Would it help if I added these patches to my package and re-run puppet?14:58
mriedemzigo's is using puppet and non-ubuntu but with libvirt14:58
mriedemzigo: so my depends-on nova change won't get pulled into that CI run?14:59
zigonon-ubuntu: Debian Stretch ... :P14:59
cdentmriedem: I get that. The root of my question is: How come we didn't fail tempest or functional?14:59
mriedemcdent: well that's what i'm trying to figure out...14:59
zigodeb http://stretch-rocky.debian.net/debian stretch-rocky-backports main + deb http://stretch-rocky.debian.net/debian stretch-rocky-backports-nochange main14:59
mriedemwe do'nt configure allocation ratios in nova.conf in devstack14:59
cdentI know, I'm not being a dick (at least I hope not), I'm just questioning-out-loud15:00
openstackgerritSurya Seetharaman proposed openstack/nova master: Add scatter-gather-single-cell utility  https://review.openstack.org/59494715:00
cdentit seems that if we know what the difference is between the standard gate tests and e.g. the xen tests, we can make our tests fail and work from that15:01
mriedemas far as i know, the xen tests are mostly stock15:02
mriedemthey did not hard-code the allocation ratios until jay told them to in the ML as a workaround15:02
mriedemwhich makes me think, my debug patch probably won't fail the xen ci now b/c of that...15:02
*** janki has quit IRC15:04
openstackgerritMerged openstack/osc-placement master: Random names for functional tests  https://review.openstack.org/54274515:04
openstackgerritKonstantinos Samaras-Tsakiris proposed openstack/nova-specs master: Placement model for passthrough devices  https://review.openstack.org/59103715:05
openstackgerritChris Dent proposed openstack/nova master: [placement] Make _ensure_aggregate context not independent  https://review.openstack.org/59748615:10
mriedemanyone remember were the hell the xenserver CI repo is in github?15:11
*** ttsiouts has quit IRC15:11
mriedemguessing https://github.com/citrix-openstack/qa15:13
*** knikolla has quit IRC15:14
*** knikolla has joined #openstack-nova15:15
*** tbachman has quit IRC15:17
*** tbachman has joined #openstack-nova15:22
jaypipesmriedem: sorry?15:22
*** dklyle has quit IRC15:22
*** dklyle has joined #openstack-nova15:23
*** manjeets has joined #openstack-nova15:23
openstackgerritDan Smith proposed openstack/nova master: DNM: Tester for grenade job  https://review.openstack.org/59756615:24
*** ttsiouts has joined #openstack-nova15:28
*** sahid has joined #openstack-nova15:28
openstackgerritChris Dent proposed openstack/nova master: [placement] Make _ensure_aggregate context not independent  https://review.openstack.org/59748615:30
*** READ10 has joined #openstack-nova15:31
dansmithmriedem: tssurya: melwitt: do we need a cells meeting? my patches merged, I think we got melwitt's from last week as well, and tssurya and I are crushing the down cell stuff15:32
*** macza has joined #openstack-nova15:32
dansmithand when I say we, I mean tssurya is doing it and I'm throwing tomatoes15:32
tssuryaI am okay to skip, sorry about the slow-ness in the spec imple; its because I am a litte stuck with the US visa stuff for the next week15:32
tssuryabut it should be settled tomorrow finally!15:33
mriedemi don't really have any news; some info is coming in on the cross-cell migration stuff and i'm trying to probe internally (yes wording intended) on how our product team did this for cascading aka cells v115:33
dansmithtssurya: oh so you'll be in denver yeah?15:33
tssuryayes :)15:33
mriedemKevin_Zheng knows more about what our product team did than i ever will15:34
dansmithtssurya: that's cool, although I'm disappointed you'll be seeing the least nice venue in our fair country :/15:34
tssuryadansmith: haha really ? its actually gonna be my first time in your country15:34
dansmithtssurya: I know, which is why I'm disappointed :/15:35
mriedemif i remember kevin's email correctly, tl;dr was that ports and volumes are accessible across cells for them15:35
mriedemcolorado is "nice" depending on where you are15:35
mriedemout by the airport is not so much15:35
dansmithyes, colorado is for sure15:35
dansmithbut the hotel and area we're in sucks15:35
tssuryaheh, I booked into the same venue as the conference15:35
tssuryaoops15:35
mriedemeveryone did15:35
dansmithunless you like living next to a freeway onramp with a big train15:36
dansmithtssurya: you have to be there, yeah15:36
dansmithtssurya: it'snot close to anything, which is part of the problem15:36
mriedemi just hope you like ihop15:36
mriedemevery15:36
mriedemmorning15:36
dansmithmriedem: don't think we're not15:36
mriedemoh i know15:36
mriedemmy stretch pants are on order15:36
dansmithwe will put 20lbs on tssurya before she's gone15:36
tssuryarolf15:36
dansmithher family won't recognize her15:36
tssurya:P that is gonna be hard considering the amount I eat15:37
dansmithtssurya: the denver ptg comes with a complimentary case of type 2 diabetes15:37
kashyapLOL15:37
tssurya:D15:37
mriedemluckily she probably gets free health care in switzerland15:37
dansmiththey won't know what to do with her15:37
kashyapIs the venue so bad?  I read somethings about a train being noisy apparently last time.15:37
dansmiththey don't have the IHOP antidote15:38
mriedemkashyap: that is reportedly fixed15:38
kashyap(And you're in the same venue this time -- assuming that problem is fixed)15:38
kashyapmriedem: Ah, I see.15:38
tssuryayou both are making it sound really bad, hopefully you are just kidding15:38
dansmithmriedem: med made it sound like maybe not15:38
dansmithtssurya: it's pretty bad15:38
mriedemi'm bringing my white noise machine either way15:38
jrollthat's an odd name for your child15:38
tssurya:(15:38
dansmithtssurya: last year my room had a hole in the wall because they weren't finished with the remodel15:38
tssuryareally ?!15:39
tssuryaso its not really gonna like the Dublin PTG then..15:39
dansmithtssurya: the foundation got a *smashing* deal..15:39
dansmithtssurya: probably less snow, but no promises15:39
jrollI missed the last one in denver, dansmith is making me so excited15:39
tssuryaheh,15:39
dansmithjroll: HOOOOOOOOOONK15:40
*** tbachman has quit IRC15:40
dansmithjroll: HOOOOOOOOOOOOOOOOOOOOOOOOOOOONK15:40
jroll:P15:40
dansmithevery ten minutes15:40
dansmithevery15:40
dansmithten15:40
dansmithminutes15:40
tssuryaI will be there on Thursday, so I have like 4 days to go around, maybe I can see the nice part of colorado15:40
dansmithsometimes at night I still hear it15:40
* jroll wonders how much beer it takes to sleep through a train15:40
dansmithjroll: you know it's bad when at checkin they hand you a noise machine and earplugs15:41
dansmithliterally.15:41
dansmithuntil they ran out of course15:41
jrollyeah, so I heard15:41
edleafetssurya: Rocky Mountain National Park may help you if you're missing the Alps15:41
jrollI get in monday night. so. I guess I'll bring my own15:41
tssuryaedleafe: nice I will see if I can go there, just waiting for the visa to be in my hand..15:42
mriedemtssurya: you're in luck! https://www.google.com/search?q=denver+broncos+schedule&ie=utf-8&oe=utf-8&client=firefox-b-1-ab#sie=m;/g/11hdb0xw6z;6;/m/059yj;dt;fp;115:42
mriedemyou can go watch the broncos get destroyed at home!15:42
tssuryamriedem: ha!15:43
mriedemhttps://deadspin.com/why-your-team-sucks-2018-denver-broncos-182807888615:43
*** ttsiouts has quit IRC15:43
*** fnordahl has joined #openstack-nova15:45
cfriesenmriedem: the "four friends kitchen" in Denver is really good, but a bit further away.15:46
*** cdent has quit IRC15:47
*** r-daneel has joined #openstack-nova15:48
*** markvoelker has quit IRC15:48
*** tbachman has joined #openstack-nova15:50
*** cdent has joined #openstack-nova15:51
mriedemgibi: i think i know what's going on in https://bugs.launchpad.net/nova/+bug/178164815:54
openstackLaunchpad bug 1781648 in OpenStack Compute (nova) "heal_allocations test randomly failing with "ValueError: Field `compute_node_uuid' cannot be None"" [Medium,Confirmed]15:54
mriedemwe're racing with the caching scheduler starting up and initializing the cache of compute nodes15:54
mriedemso by the time we hit the scheduler, the cache is empty15:54
gibimriedem: that sounds like a reasonable explanation. I guess I missunderstood the logs when I stated in the bug that the host creation overlaps with the scheduling15:56
*** efried is now known as efried_rollin15:57
gibimriedem: so I guess the fix is that we need to wait in the test a bit15:59
openstackgerritMatt Riedemann proposed openstack/nova master: Restart scheduler in TestNovaManagePlacementHealAllocations  https://review.openstack.org/59757116:00
mriedemsort of ^16:00
mriedemi thought about also changing this https://github.com/openstack/nova/blob/master/nova/scheduler/caching_scheduler.py#L78 to "if not self.all_host_states:" to handle the empty list case, but that could still be a weird race failure if we have 1 host but not both in the cache16:02
gibimriedem: your proposed start / stop is way better than a simple sleep in the test16:02
mriedemi learned it from watching you gibi16:02
gibi:)16:04
*** tssurya has quit IRC16:04
melwitt.16:05
gibimriedem: I'm wondering how many other functional tests uses CachingScheduler and therefore might be affected by the same race16:05
mriedemgibi: some do, but they might start the scheduler after the computes, i was just starting to audit that16:06
gibimriedem: cool16:06
*** adrianc_ has quit IRC16:10
*** slaweq has quit IRC16:11
mriedemmlavalle: smcginnis: on this cross-cell cold migration thing nova will definitely need some pre-validation of the selected host,16:14
*** links has quit IRC16:14
mriedemi'm wondering if simply trying to create a volume attachment/port binding on the selected target host *in another cell* would be enough to tell us if that's not going to work for storage/networking16:15
mriedemor in the case of port bindings, will neutron only fuss when we try to activate the target host port binding?16:15
*** slaweq has joined #openstack-nova16:16
*** udesale has quit IRC16:16
jaypipeszigo, mriedem: we have a rough timeframe of when this began occurring (the allocation ratio 0 thing...)?16:16
*** READ10 has quit IRC16:16
mriedemearliest i know of is when naichuans reported it in the ML16:17
*** READ10 has joined #openstack-nova16:17
mlavallemriedem: the port binding is the result of asking the mechanism managers if they can bind the port in the indicated host. so the binding process is what you call the pre-validation of the selected host16:18
melwittdansmith: +1 to meeting skippage16:18
mlavallemechanism drivers^^^^16:18
mlavalleso when you say create_port_binding, you are asking the mechanism drivers whether any of them can bind the port in the designated host16:19
mriedemmlavalle: and if the network that the port is in doesn't cover that dest host, the port binding creation should fail?16:20
sean-k-mooneymriedem: it will fail of non of the ml2 driver can bind the port to the correct network16:20
mlavallemriedem: correct. the question that the drivers ask themselves is whether they can a segment of the network reachable in that host16:20
mlavallethey have a segment^^^^16:21
*** slaweq has quit IRC16:21
melwittcan anyone confirm whether PCI and SRIOV PCI devices are treated the same as far as the scheduler is concerned?16:21
sean-k-mooneymlavalle: that segment is only relevent for provider networks with the multi segment network extention correct normmal it 1 segment per network16:21
sean-k-mooneymlavalle: as in in the pci filter?16:22
sean-k-mooneymelwitt: ^16:22
sean-k-mooneymelwitt: they are more or less treated the same but they do have a different type in the pci manager (type-pci for passthough and type-PF or type-VF for sriov)16:23
melwittsean-k-mooney: maybe? just in general, for NUMA scheduling, if SRIOV PCI devices are treated differently at all or no16:23
mlavallesean-k-mooney: but regardless, today we can bind a port in multiple cells deployments, right?16:23
melwittsean-k-mooney: I see, thank you16:24
sean-k-mooneymelwitt: from a numa perspctive they are treated the same. we store the numa node info the same way in the db16:25
sean-k-mooneymlavalle: yes i think so but never tried it16:25
*** tbachman has quit IRC16:26
mlavallesean-k-mooney: so that means that the mechanism drivers are being able to answer the question, can I bind a port here or not? in multiple port bindings, we are asking that same question, it's just that the port is also bound somewhere else16:26
sean-k-mooneymlavalle: cells is a nova only ting. neutron has availablity zones. if you had a different neutron availableity zone per cell can a netowrk span neutron availablity zones16:26
*** READ10 has quit IRC16:26
mriedemi would think,16:27
sean-k-mooneymlavalle: well we are talking about cross cell cold migration so jsut like the live migration case we will have multiple port bindings so from a neutron point of view it should be identical16:28
mriedemwhen we have an attached port, bound to the source host,16:28
mriedemnova puts the az on the port binding information,16:28
mriedemand neutron would be relying on that to know if we can bind to another host in another a16:28
mriedem*az16:28
mlavallesean-k-mooney: that is what I say16:28
jaypipesmriedem: I have a sneaking suspicion this patch is the cause: https://github.com/openstack/nova/commit/c9b74bcfa09d11c2046ce1bfb6dd8463b3a2f3b016:28
mriedemjaypipes: that's only in master16:28
mriedemzigo is hitting this in rocky16:28
sean-k-mooneymlavalle: yep i am agreeing :)16:28
mlavallesean-k-mooney: LOL16:28
mriedembtw, is it strange we don't have a cross_az_attach=False thing for nova/neutron like we have for nova/cinder?16:29
mlavallesean-k-mooney: will you be in Denver?16:29
sean-k-mooneymriedem: neutron does not use the nova AZ as part of port bininging just the hostname16:29
sean-k-mooneymlavalle: yes i will16:29
mriedemso why do we set the device_owner on the port?16:29
mlavalleGreat!16:29
mriedemusing the instance az?16:29
mlavallebecause you want to keep track of where it is, on the Nova side, but I am just speculating16:30
sean-k-mooneymriedem: that is a good question to which i do not know the answer16:30
mriedemit might be used by the neutron callback code16:30
jaypipesmriedem: oh... I thought you said this only recently occurred..16:31
mriedemjaypipes: it is only recently reported16:31
mriedembut i also thought about that _update change but it's master only16:31
mriedemand zigo said he's hitting it on rocky16:31
*** jpena is now known as jpena|off16:31
sean-k-mooneymriedem: im pretty sure its not used by neutron at all. my geuess is this might be from nova networks and we just kept doing it16:31
sean-k-mooneythe AZ that is16:32
jaypipesmriedem: ack16:32
mriedemnova net doesn't have any kind of device_owner thing16:32
*** davidsha has quit IRC16:32
mlavalleyeah, the device_owner stuff is a Neutron port concept16:32
sean-k-mooneymriedem: oh i was going to specalte we might of needit to do the nova-net multhost thing16:32
mriedembingo http://git.openstack.org/cgit/openstack/neutron/tree/neutron/notifiers/nova.py#n7716:32
mriedemit's what i said it was16:32
mriedemamong apparently a lot of other things16:33
sean-k-mooneymriedem: i dont see why we need the az form that16:33
mriedemwe probably dont16:34
mlavallethere we only use the compute prefix16:34
mlavalleas we do in other places of the code16:34
mriedemprobably explains why https://launchpad.net/bugs/1759924 isn't that big a deal16:35
openstackLaunchpad bug 1759924 in OpenStack Compute (nova) "Port device owner isn't updated with new host availability zone during unshelve" [Medium,In progress] - Assigned to Matt Riedemann (mriedem)16:35
mriedemexcept it causes confusiong16:35
mriedem*confusion16:35
*** slaweq has joined #openstack-nova16:35
sean-k-mooneymriedem: silvanb is still on pto but i was discussing this with him a few weeks ago about should we remove setting it or not16:35
mriedembauzas you mean?16:35
sean-k-mooneymriedem: yes16:36
mriedemif there is one thing sylvain loves to talk about more than cheese and skiing, it's AZs16:36
mlavalleLOL16:36
jaypipesmriedem: zigo's using libvirt, right?16:36
mriedemyup16:36
jaypipesk16:37
sean-k-mooneythere was concern over is allowing livemigation across availablity zones breaking the contract with a user.16:37
mriedemwell that reminds me of another bug fix https://review.openstack.org/#/c/567701/16:37
sean-k-mooneythere are some open bugs where instances with floating ips break if you do this.16:37
mriedemwith neutron dvr?16:38
mriedemor just in general?16:38
sean-k-mooneyi think it was in general. i should find out i will check when i have my live migration setup running again16:38
*** psachin has joined #openstack-nova16:40
sean-k-mooneymriedem: mlavalle  actully while ye are both here i added some talking points to the nova neutron cross project session since it was blank16:40
sean-k-mooneyhttps://etherpad.openstack.org/p/nova-ptg-stein line 14716:40
*** r-daneel has quit IRC16:40
sean-k-mooneycross cell migration should proably be there16:41
mriedemcross-cell migratoin is in the cells section16:41
mriedembut sure16:41
melwittcross-cell migration will apply to the cells section, the cinder section, and the neutron section, I think16:42
mlavalleyesterday I asked rubasov,16:42
sean-k-mooneymlavalle: so just so we can confim does neutron allow neutron networks to span neutron availablitiy zones16:42
mlavallewho asked gibi, whether we needed to discuss bandwidth based scheduling, and the answer was no16:42
mlavallesean-k-mooney: I think it does but i'll confirm16:43
jaypipesmriedem: hmm, I've gone through all patches to the nova source tree in the rocky branch in the last three months and don't see anything at all that hits the code paths involved in setting allocation ratios... I'm a little stumped, to tell the truth.16:44
stephenfinjaypipes: Are you planning to work on that "move CPU tracking to placement" spec this cycle?16:44
* stephenfin wonders if it's PTG worthy16:44
jaypipesmriedem: unless this is a super latent but is just recently rearing its head... perhaps..16:44
sean-k-mooneymlavalle: i geuss if it does not and it causes port binding to fail when then that will be enough for nova to know not to schduler to that node16:45
jaypipesstephenfin: yeah, I guess I have to. I'd RATHER shove hot pokers in my eyeballs, though.16:45
mlavallesean-k-mooney: yes, that's whaat I would say16:45
mlavallesean-k-mooney: I left a comment in the etherpad, L166 regarding whther we need to discuss bandwidth based scheduling16:48
*** hshiina has quit IRC16:48
*** hshiina has joined #openstack-nova16:48
*** slaweq has quit IRC16:49
sean-k-mooneymlavalle: cool well it was more of a what is the current state of this and should we be planning to schduler review time to get this finish in stein topic.16:49
mlavallesean-k-mooney: ping them tomorrow, they are closer to your tz16:50
mlavallenow it is very late for them16:50
sean-k-mooneymlavalle: sure will do16:51
mlavalleand maybe it is getting late for you as well16:51
gibimlavalle, sean-k-mooney: I and rubasov can give a status of the bandwidth work on the PTG if needed16:52
mlavallegibi: thanks16:53
*** dtantsur is now known as dtantsur|afk16:54
*** ccamacho has quit IRC16:54
*** psachin has quit IRC16:56
*** gyee has joined #openstack-nova16:59
openstackgerritBalazs Gibizer proposed openstack/nova-specs master: Resource provider - request group mapping in allocation candidate  https://review.openstack.org/59760117:02
gibimlavalle: ^^ this spec is only impacting placement (and or Nova) but connected to the bandwidth work. I think we will discuss it in the placement related sessions rather than in the nova-neutron cross session.17:03
gibimlavalle: but you might be interested still17:03
mlavallegibi: ack, thanks for the heads up17:04
sean-k-mooneymlavalle: i tend to start late and work late.17:13
mriedemi work hard and i play hard17:14
mriedemmtreinish:17:14
sean-k-mooneygibi: sure if you want to cover that in the placement sessions then that works too. just wanted to make sure it did not slip through the cracks17:15
*** tbachman has joined #openstack-nova17:15
gibisean-k-mooney: at the moment the resource mapping does not affect Neutron it either affect placement and nova or nova only.17:16
gibisean-k-mooney: neutron will get the nework device RP uuid from nova during the port binding anyhow17:16
openstackgerritMatt Riedemann proposed openstack/nova master: (Re)start caching scheduler after starting computes in tests  https://review.openstack.org/59760617:17
sean-k-mooneygibi: previded we modify nova to pass them to you :)17:18
sean-k-mooneygibi: looking at the spec this looks pretty familar to what we discussed back in dublin17:18
gibisean-k-mooney: code is up that does passes the RP from nova to neutron https://review.openstack.org/#/c/569459/26/nova/network/neutronv2/api.py@312917:19
*** tbachman has quit IRC17:19
gibisean-k-mooney: it only works for the simple cases17:19
gibisean-k-mooney: I can make it work for the general case but it won't scale17:20
gibisean-k-mooney: so I proposed the spec to do the mapping in placement17:20
gibisean-k-mooney: I have to leave for today I happy to continue the discussion tomorrow, or on the review, and eventually on the PTG17:21
sean-k-mooneygibi: oh cool i had not seen that series. i will have to pull it down and try it out17:21
sean-k-mooneygibi: no worries have a good evening17:21
gibisean-k-mooney: same to you17:21
mriedemso my debug logging patch didn't fail xenserver ci since they hard-coded the allocation ratios in nova.conf http://dd6b71949550285df7dc-dda4e480e005aaa13ec303551d2d8155.r49.cf1.rackcdn.com/53/597553/1/check/dsvm-tempest-neutron-network/971ea88/logs/etc/nova/nova.conf.txt.gz17:24
mriedemi need to find their repo to revert that change17:24
*** gbarros has quit IRC17:25
jaypipesmriedem: my bad, sorry.17:26
mriedemhelp me find the repo17:26
*** tbachman has joined #openstack-nova17:26
sean-k-mooneymriedem: could you just hard code the nova.conf passing code to return none17:26
sean-k-mooneymriedem: or whatever it returns when its not set17:27
*** gbarros has joined #openstack-nova17:27
sean-k-mooneymriedem: they are hard coding it in the local.conf http://dd6b71949550285df7dc-dda4e480e005aaa13ec303551d2d8155.r49.cf1.rackcdn.com/53/597553/1/check/dsvm-tempest-neutron-network/971ea88/logs/local.conf.txt.gz17:29
mriedemi didn't think git://git.openstack.org/openstack/os-xenapi was it17:30
mriedemyeah it's not17:30
cdentmriedem: did you say that zigo's thing was changed to depends-on your debuggery?17:32
mriedemyeah but i'm not sure it would help17:32
dansmithmriedem: yeah that's the pack of xenapi plugins I think17:32
mriedemhttps://review.openstack.org/#/c/597175/ but that doesn't actually get the nova change into the nova package17:33
mriedemsean-k-mooney: oh you meant the allocation ratios - yes i knew that17:34
mriedemand yeah i might have to hack the nova code to ignore the config17:34
mriedembut first lunch17:34
sean-k-mooneymriedem: yes i ment hack the nova code to ignore the configs so that you can work around there hack to hard code them :)17:35
jaypipesmriedem: https://review.openstack.org/#/c/597428/17:36
sean-k-mooneyjaypipes: oh you found it. am i the only on that is bothered by the fact the repo is xenapi-os-testing when the other one is os-xenapi17:38
sean-k-mooneyjaypipes: that change is not merged however which implies the ci is not running off of master of that repo?17:39
mriedemthey might be patching that into all CI runs17:42
jaypipeswhat mriedem said.17:43
sean-k-mooneymriedem: you could see if a depends on would override it. e.g. make a noop patch to xenapi-os-testing then depend on it to force the unpatched version?17:43
jaypipessean-k-mooney: that would assume the xenserver CI is honouring depends-on, no?17:44
*** sahid has quit IRC17:44
sean-k-mooneytrue17:45
mriedemi'm pretty sure they do,17:45
mriedemi'll just revert that change and depends-on the nova logging patch17:45
sean-k-mooneyis https://bugs.launchpad.net/nova/+bug/1789654 only happenign with the xen driver by the way?17:46
openstackLaunchpad bug 1789654 in OpenStack Compute (nova) rocky "placement allocation_ratio initialized with 0.0" [High,Confirmed]17:46
mriedemno,17:47
mriedemzigo is hitting it on rocky with libvirt17:47
melwittmriedem: I'm unsure whether to +1 this rocky final releases patch given the regression you're investigating. I assume we are too late to fix it for GA, but not 100% sure https://review.openstack.org/59752917:48
mriedemmelwitt: i assume the GA ship has sailed17:49
mriedemgiven we aren't hitting this in the 'normal' gate and we don't have root cause, i don't think we can hold anything up17:50
melwittok. I wasn't clear whether the latest find in xenserver CI yielded a root cause or not. thanks17:51
sean-k-mooneymriedem: strange just looking at my devstack install everything looks fine on libvirt.17:53
sean-k-mooneymriedem: do you know how to reproduce or is that what your currently investiaging17:53
*** slaweq has joined #openstack-nova17:53
mriedem...17:53
melwittin the past, the 0.0 was supposed to be a signal for the scheduler to use different default values, which I always found confusing17:54
mriedemwhat about "don't know root cause" is ....17:54
mriedemyes it should read from hard-coded values in the compute node17:54
mriedemthis isn't the scheduler,17:54
mriedemit's what goes into the resource providers in placement,17:54
mriedemvia the RT / ComputeNode object17:54
mriedemhere is a revert on the xen ci patch https://review.openstack.org/#/c/597613/117:55
mriedemplus nova logs17:55
melwittthis is the quote I was thinking of from the config option help, "NOTE: This can be set per-compute, or if set to 0.0, the value set on the scheduler node(s) or compute node(s) will be used and defaulted to 16.0."17:57
mriedemyes17:57
mriedemthe 16.0 comes from the compute node object code17:57
melwittoh, ok17:57
mriedemhttps://github.com/openstack/nova/blob/master/nova/objects/compute_node.py#L18817:57
mriedemwhich is used here https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L10617:58
mriedemjaypipes: hmm, maybe we aren't reading from a compute node that's come out of the db17:59
melwittok, so somehow that is not being effected into the actual ratio being used (the bug)17:59
mriedemjaypipes: nvm, ComputeNode.create calls _from_db_object18:00
mriedemso those allocation ratio fields will be set after create18:00
jaypipesmriedem: yea18:02
mriedemplus if that were the case we'd always fail this in the gate18:02
*** slaweq has quit IRC18:03
sean-k-mooneymriedem: if it will help i can try to run the reporduce.sh script without the hard coded ratios in a clean vm and see if it will result in the 0.0 allocations?18:07
melwittafter it pulls the defaults from the compute node object, what is the thing that is supposed to set those default values in placement?18:08
melwittthe RT? makes a call to update the inventory? (reading from the bug)18:09
melwittok, yeah here https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L90218:11
sean-k-mooneyi would have assumed the ratios were ultimatly set in the virt driver in update_provider_tree18:11
mtreinishmriedem: ?18:13
sean-k-mooneymelwitt: oh so we get tree from placement, and pass it to the driver in the update_provider_tree call then normalise which set the defulats then the report_clinet updates placement?18:15
mriedemmtreinish: "we work hard and we play hard"18:17
sean-k-mooneymelwitt: the xenapi driver does not impmentd update provider tree yet so we are hittig the excpet block https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L907-L92118:18
mriedemmtreinish: if you're going to be around at all anymore, i need it to be for my quick simpsons references18:18
mriedemmelwitt: https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L902 doesn't update placement18:18
mriedemit updates a view of the provider tree locally18:18
melwittsean-k-mooney: was just thinking about that and whether it's related. does that mean it won't update placement?18:19
mriedemreportclient.update_from_provider_tree(context, prov_tree) is the call that is meant to send the changes from local to remote (placement)18:19
melwittmriedem: I see, ok, I was just about to look for that18:19
sean-k-mooneymriedem: but we dont call that in the except block...18:19
melwittmriedem: but that will fail because the xen driver has not implemented it, so then there's a fallback that will do it? trying to understand what is here18:19
mriedemi actually thought the xen driver implemented update_provider_tree, but even so, self.scheduler_client.set_inventory_for_provider( should update the thing18:20
mriedemin placement18:20
mtreinishmriedem: heh, I didn't realize you were in the steel industry18:20
mriedemrust belt baby18:20
melwittok, hm18:21
*** slaweq has joined #openstack-nova18:22
mriedemthis is likely related since the report client still relies on a provider tree for caching18:23
melwittyeah, like you mentioned in the bug. but how could the cache think the allocation ratio is already set to 16.0, for example? and think nothing changed18:24
melwittif it's currently 0.018:24
sean-k-mooneymriedem: well we dont call prov_tree.update_inventory(nodename, inv_data) in the except block you mentioned that updated the internal view18:26
mriedemso my logging patch is most likely not going to help the xen case here because it's not going down that alternative route, i'll update in a bit18:26
mriedemsean-k-mooney: no but the report client does internally18:26
cdentmriedem: what are the odds it was related to this change: https://review.openstack.org/#/c/520024/18:26
mriedemon "it's" version18:26
mriedemcdent: heh jaypipes already brought that up :)18:26
mriedemand it was the first thing i thought of today18:27
mriedembut that isn't on rocky and zigo said he hit this on rocky18:27
cdentoh, sorry, I was out walking and it crossed my mind18:27
mriedemunless of course zigo is actually hitting stein code somehow18:27
cdentI'm not certain that what zigo is experiencing is the same as what the xen stuff is experiencing18:27
melwittdo we see this log message, LOG.warning('Unable to refresh my resource provider record')? says "# NOTE(danms): Either we failed to fetch/create the RP on our first attempt, or a previous attempt had to invalidate the cache, and we were unable to refresh it. Bail and try again next time."18:27
cdentbecause it's not clear what setup zigo has or hasn't done18:27
jaypipesyeah, cdent, that was SOOOOO one hour ago, geez! :P18:28
cdentheh, I was fetching elderberries18:28
cdentwhich is like18:28
cdentso british18:28
jaypipes:)18:28
cdentit was the first thing I came across when trying to figure out why the ComputeNode after get_inventory might be wrong18:29
cdentbecause tracing the code the ComputeNode at that point has to have a cpu_allocation_ratio of 0 for us to see the results that are happening18:30
cdent(was also prepared to fetch blackberries but they aren't ready)18:30
*** slaweq has quit IRC18:31
mriedemare dingleberries in season yet?18:31
jaypipescdent: yeah, after finding out that zigo was on rocky, I went and reviewed the last 3 months of patches to rocky that could have anything at all do with allocation ratio or inventory setting and couldn't find anything at all. Also note that the patch you mentioned above isn't in Rocky18:32
jaypipesmriedem: always.18:32
mriedemha18:32
*** wolverineav has joined #openstack-nova18:32
mriedemmelwitt: http://logs.openstack.org/41/590041/17/check/tempest-full/b3f9ddd/controller/logs/screen-n-cpu.txt.gz#_Aug_27_14_18_24_078058 is a failed xen run if you want to dig for logs18:33
melwittthx18:33
openstackgerritMatt Riedemann proposed openstack/nova master: Add contributor guide for upgrade status checks  https://review.openstack.org/59690218:36
melwittnot seeing this message in the log LOG.debug('Updated inventory for %s at generation %i', which should be there if we've ever successfully updated inventory. which supports the theory that self._provider_tree.has_inventory_changed is returning False18:41
melwittI don't see any of the error log messages associated with a failure to update inventory18:41
melwittlooks like it would be helpful to have a debug message "Inventory has not changed, skipping update" when it skips18:43
sean-k-mooneyits kind of dump but im going to hard code  a not implmented excpetion here https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L895 and restack and see if i get the same behavior18:43
mriedemmelwitt: yeah that's what my debug patch is doing18:44
sean-k-mooneymelwitt: i think thi is where we check if things have changed https://github.com/openstack/nova/blob/722d5b477219f0a2435a9f4ad4d54c61b83219f1/nova/scheduler/client/report.py#L86518:44
mriedembut now i'm distracted by fracas in the tc channel18:45
melwittmriedem: yeah, just saw that and was about to say, that's what you're already doing and are going to update it to also do it for the non-provider tree route18:45
melwittsince that's where we're going for xen anyway18:45
mriedemyes in progress18:45
mriedemdespite fracas18:45
melwittsean-k-mooney: yes, that's it18:46
openstackgerritMatt Riedemann proposed openstack/nova master: Add debug logs for when provider inventory changes  https://review.openstack.org/59756018:51
mriedemupdated for alt path ^ note hyperv and vmware etc would all be failing from this as well if that alternate path is the issue18:51
sean-k-mooneymriedem: i wonder if the hyperv ci also hardcordes the allocation ratios in the conf18:54
mriedemwe can find out18:56
sean-k-mooneymriedem: the hyperv ones look ok18:58
sean-k-mooneyas in not set18:58
melwittoh, well, if xen is hard-coding values that match the 0.0 defaults, then placement would _not_ be updated right?18:58
melwittoh, nevermind. reportclient should be comparing with what's in placement18:59
sean-k-mooneymlavalle: xen were hardcoding real ratios18:59
sean-k-mooney* melwitt: ^18:59
sean-k-mooneymelwitt: http://dd6b71949550285df7dc-dda4e480e005aaa13ec303551d2d8155.r49.cf1.rackcdn.com/60/597560/1/check/dsvm-tempest-neutron-network/0b2f0a8/logs/local.conf.txt.gz18:59
sean-k-mooney[DEFAULT]19:00
sean-k-mooneydisk_allocation_ratio = 2.019:00
sean-k-mooneyram_allocation_ratio = 1.519:00
sean-k-mooneycpu_allocation_ratio = 16.019:00
melwittyeah. I was trying to think if that would appear to reportclient as "no change" and therefore not update placement19:00
sean-k-mooneyall vaild that said i would never advise setting the disk_allocation_ration over 119:00
melwittbut, reportclient should be comparing what placement has with those new values, so it should see a change. but from what we know so far, it looks like it isn't seeing a change. mriedem's debug logs will confirm19:01
sean-k-mooneymelwitt: if you could some how get the value to the report clinet as 0.0 then yes19:01
melwittright, yeah19:02
*** jamesdenton has quit IRC19:02
mriedemsean-k-mooney: they are *now*19:03
mriedemthey weren't when they reported the issue19:03
mriedemthey are hard-coding them in config as a workaround for the CI failure19:03
mriedemwhich is why i've reverted that change to try and actually get a recreate with logging19:03
sean-k-mooneyright so before they were not set19:04
cdentmriedem: have you added logs which watch the value of the cn.*_allocation_ratio in some way?19:04
cdenti'm looking at https://review.openstack.org/#/c/597560/2/nova/compute/resource_tracker.py,unified and wonder if we want more info about the state of the compute node along the way19:05
cdentwhen cn.save() is called if those values are weird for some reason the ratio adjustment stuff in _from_db_object _might_ no be behaving as expected19:06
mriedemi could add that19:06
cdent(of course you have probably already analyzed this while I was getting elderberries)19:06
melwittsean-k-mooney: yeah, so focusing on the values somehow being 0.0 _after_ the normalize from compute node object, that's what got mentioned earlier, how that could possibly happen19:06
melwittthe normalize function is supposed to be filling in with the defaults 16.0 etc19:07
sean-k-mooney... so my raise NotImplemented to force the alt path with the libvirt driver sill resulted in the correct vaules19:08
*** mrjk has quit IRC19:09
*** pcaruana has quit IRC19:09
*** mchlumsky has quit IRC19:09
melwitt? so how is xen failing? I thought it was taking the alt path19:09
sean-k-mooneymelwitt: it is but taking the alt path is apparently not enough19:09
melwittoh19:09
sean-k-mooneyi have matt's debug patch applied also but im not sure that is going to show where the default values got applied19:11
*** mrjk has joined #openstack-nova19:12
openstackgerritMatt Riedemann proposed openstack/nova master: Add debug logs for when provider inventory changes  https://review.openstack.org/59756019:12
mriedemcdent: like this? ^19:13
*** awaugama has quit IRC19:13
*** jamesdenton has joined #openstack-nova19:16
*** mrjk has quit IRC19:17
* cdent looks19:17
cdentmriedem: yeah, nice. that combined with the other stuff ought to help see the flow19:18
*** mrjk has joined #openstack-nova19:19
cdents/see/better see/19:19
cdentThe difficulty with creating an MTC for this makes me anxious19:19
*** mrjk has quit IRC19:23
*** efried_rollin is now known as efried19:26
sean-k-mooneyim restacking in offline mode (with libvirt) we are expecting to see the defaulting to ... message if the compute node object is setting the defaults right19:26
sean-k-mooneyi can deploy a xen node tommorow if needed to see if i can reporduce19:28
*** mriedem has quit IRC19:31
*** mriedem has joined #openstack-nova19:31
*** gbarros has quit IRC19:36
*** gbarros has joined #openstack-nova19:39
openstackgerritMatt Riedemann proposed openstack/nova master: Revert "libvirt: add method to configure migration speed"  https://review.openstack.org/59081419:41
cfriesenjaypipes: re the cold migration with PCI devices.  were you talking about the difference between it being theoretically supported and actually doing it?   StarlingX integration tests do cold migration with PCI/SRIOV regularly, but I realize that doesn't answer the question for upstream.19:43
sean-k-mooneycfriesen: i think i have done it in the past also i had tought it was ment to be supported. that said not sure it updated teh resouce tracker correctly19:45
jaypipescfriesen: yes, I'm referring to real-world deployments who do migrations where the instances hold on to their IP addresses, GPUs, and everything else and are migrated to a different rack/region whatever19:45
jaypipescfriesen: but whatever, I'm running from that conversation screaming.19:46
cfriesenjaypipes: :)19:46
*** gbarros has quit IRC19:51
openstackgerritMatt Riedemann proposed openstack/nova master: Add functional test for live migrate with anti-affinity group  https://review.openstack.org/58893519:55
mriedemcfriesen: upstream supports cold migration with pci devices19:56
mriedemremember moshe and ludovic got that working19:56
mriedemthere was also 3rd party ci from mellanox for it at one time i think19:57
mriedembut that might be dead now19:57
*** slaweq has joined #openstack-nova20:01
*** r-daneel has joined #openstack-nova20:01
openstackgerritMatt Riedemann proposed openstack/nova master: Delete instance_group_member records from API DB during archive  https://review.openstack.org/58894320:16
mriedemmelwitt: just noticed you had commented on this ^ test should cover the case you noted now20:16
melwittok, will look20:17
mriedemcrap forgot to update the bug reference in the commit message20:20
openstackgerritMatt Riedemann proposed openstack/nova master: Delete instance_group_member records from API DB during archive  https://review.openstack.org/58894320:21
*** mgagne has joined #openstack-nova20:22
*** priteau has quit IRC20:23
*** mrjk has joined #openstack-nova20:24
*** gbarros has joined #openstack-nova20:26
openstackgerritMatt Riedemann proposed openstack/nova master: Remove old check_attach version check in API  https://review.openstack.org/58834820:28
*** cdent has quit IRC20:28
*** gbarros has quit IRC20:33
*** luksky11 has joined #openstack-nova20:34
*** gbarros has joined #openstack-nova20:36
dansmithmelwitt: mriedem: this is going to pass tests in a few minutes: https://review.openstack.org/#/c/59720620:39
dansmithif you could ack it with a +1 (or tell me what you want changed), I will go about trying to figure out how I'm going to get that merged :)20:39
melwittwill do20:40
dansmithalso i was going to verify resource providers before/after and then realized we can't really do that since other projects might create providers, and we have no "service type" field20:43
mriedemone hack way to determine a compute node provider is via the VCPU inventory20:43
dansmithfor the moment, yeah, but meh20:44
dansmithI'd rather get this in and work on the other stuff20:44
dansmithbecause this was a PITA to get working20:44
mriedemdansmith: need to recheck https://review.openstack.org/#/c/597566/ ?20:44
dansmithjust because I don't want to run it locally20:44
dansmithmriedem: no, it's about to pass soon too20:45
mriedemok20:45
zigomriedem: As I told you, if you wish, I can push your patches into the packages...20:45
zigoPackage is building with the patch...20:45
mriedemzigo: sure, but that's not something you'll release is it? with the debug log patch?20:46
mriedemi'm just hoping to debug a recreate with ci logs20:46
zigomriedem: It just lives in my Stretch backport, until I remove the patch.20:47
zigoI don't have the intention to push that to Debian Sid / Experimental, no.20:47
zigomriedem: once the package is built by my jenkins (you can see the build process there: https://stretch-queens.infomaniak.ch/job/nova/) then we just need to re-trigger the puppet-openstack CI.20:48
*** markvoelker has joined #openstack-nova20:48
zigomriedem: Otherwise, I can teach you how to re-produce it on a local Stretch VM. It's very easy .20:50
mriedemthat's ok, looks like we have a recreate again in the xen ci https://review.openstack.org/#/c/597613/20:53
*** markvoelker has quit IRC20:55
mriedemthat doesn't have the logging i need though, so rechecking the xenserver ci job20:56
zigoSilly me, wrong jenkins ...20:57
melwittdansmith: are you intentionally not checking for DISK_GB in the verify inventory step?20:59
dansmithmelwitt: um, duh, of course I'm not20:59
dansmithI mean20:59
dansmithwho would verify DISK_GB20:59
dansmiththat'd be kinda, like, really stupid right?21:00
* dansmith looks away21:00
openstackgerritMatt Riedemann proposed openstack/nova master: Add encrypted volume support to feature matrix docs  https://review.openstack.org/57025521:00
melwittlol21:00
dansmithmelwitt: like six of those patchsets were me getting resource classes wrong21:02
*** tbachman has quit IRC21:02
dansmithmelwitt: just pushed to use a central list21:02
melwittheh. central list = good21:02
dansmithsince it takes about 90 minutes to test each one, I've been trying to make minimal change21:03
dansmithyou better hope this one works and I don't have to spend another couple days throwing things at the wall :)21:03
melwittit's gotta work21:04
*** erlon has quit IRC21:04
*** mchlumsky has joined #openstack-nova21:11
*** eharney has quit IRC21:15
openstackgerritMatt Riedemann proposed openstack/nova master: Default AZ for instance if cross_az_attach=False and checking from API  https://review.openstack.org/46967521:18
*** wolverineav has quit IRC21:20
openstackgerritMatt Riedemann proposed openstack/nova master: Time how long select_destinations() takes in conductor  https://review.openstack.org/51710821:23
zigomriedem: Package built, waiting for recheck now.21:24
zigoIt probably will end when I'll be sleeping ...21:25
*** tbachman has joined #openstack-nova21:27
mriedemyeah i'm t-15 minutes from parenting duties21:31
*** Sundar has joined #openstack-nova21:33
openstackgerritMatt Riedemann proposed openstack/nova master: Combine error handling blocks in _do_build_and_run_instance  https://review.openstack.org/54596021:40
*** liuyulong has quit IRC21:42
*** mchlumsky has quit IRC21:44
*** mriedem is now known as mriedem_away21:44
*** rcernin has joined #openstack-nova21:49
*** mriedem_away has quit IRC21:49
Sundar efried: Please ping me21:50
*** gbarros has quit IRC21:51
*** takashin has joined #openstack-nova21:51
*** luksky11 has quit IRC22:03
*** r-daneel_ has joined #openstack-nova22:05
*** r-daneel has quit IRC22:05
*** r-daneel_ is now known as r-daneel22:05
openstackgerritMerged openstack/nova master: doc: add info how to troubleshoot vmware specific problems  https://review.openstack.org/59744622:07
*** mlavalle has quit IRC22:12
*** slaweq has quit IRC22:17
*** threestrands has joined #openstack-nova22:19
*** threestrands has quit IRC22:19
*** threestrands has joined #openstack-nova22:22
*** markvoelker has joined #openstack-nova22:46
*** r-daneel has quit IRC22:56
*** macza has quit IRC23:03
openstackgerritMatt Riedemann proposed openstack/nova master: Document differences and similaries between extra specs and hints  https://review.openstack.org/58141023:09
*** slaweq has joined #openstack-nova23:11
*** markvoelker has quit IRC23:12
*** slaweq has quit IRC23:15
*** holser_ has quit IRC23:29
*** macza has joined #openstack-nova23:31
*** macza has quit IRC23:36
openstackgerritTakashi NATSUME proposed openstack/nova master: Add TODO note for mox removal  https://review.openstack.org/57675823:51

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