Tuesday, 2017-04-18

*** Apoorva_ has quit IRC00:01
*** jamesdenton has quit IRC00:01
*** Apoorva has joined #openstack-nova00:01
*** jamesdenton has joined #openstack-nova00:03
*** dharinic has quit IRC00:04
*** diga has joined #openstack-nova00:05
*** ngupta has quit IRC00:11
*** jamesdenton has quit IRC00:13
*** faizy_ has quit IRC00:15
*** jamesdenton has joined #openstack-nova00:15
*** hongbin has quit IRC00:15
*** jamesdenton has quit IRC00:19
*** jamesdenton has joined #openstack-nova00:23
openstackgerritSTEW TY proposed openstack/nova master: Transform instance.unrescue notifications  https://review.openstack.org/38827500:24
*** thorst has quit IRC00:27
*** dtp has quit IRC00:27
*** tjones has joined #openstack-nova00:28
*** jamesdenton has quit IRC00:34
*** zhurong has joined #openstack-nova00:42
*** winston-d_ has joined #openstack-nova00:43
*** gjayavelu has quit IRC00:45
*** jamesdenton has joined #openstack-nova00:49
*** crushil has joined #openstack-nova00:51
*** huanxie has joined #openstack-nova00:52
*** mriedem has quit IRC00:53
*** Swami has quit IRC01:00
*** Apoorva_ has joined #openstack-nova01:00
*** tovin07_ has joined #openstack-nova01:02
*** Apoorva has quit IRC01:04
*** Apoorva_ has quit IRC01:04
*** cNilesh has joined #openstack-nova01:05
*** ijw has joined #openstack-nova01:09
*** tjones has quit IRC01:09
*** ubuntu-mate_ has joined #openstack-nova01:11
*** ubuntu-mate_ has quit IRC01:11
*** ngupta has joined #openstack-nova01:12
*** thorst has joined #openstack-nova01:12
*** thorst has quit IRC01:12
*** kevinz has joined #openstack-nova01:13
*** ijw has quit IRC01:14
*** MasterOfBugs has quit IRC01:16
*** NikhilS has joined #openstack-nova01:20
*** jamesdenton has quit IRC01:22
openstackgerritshaofeng cheng proposed openstack/nova master: Update etherpad url  https://review.openstack.org/45719801:23
*** tbachman has quit IRC01:26
*** ijw has joined #openstack-nova01:27
*** esberglu has joined #openstack-nova01:29
*** esberglu has quit IRC01:29
*** esberglu has joined #openstack-nova01:29
*** esberglu has quit IRC01:29
*** esberglu has joined #openstack-nova01:30
*** fragatin_ has joined #openstack-nova01:30
*** fragatin_ has quit IRC01:30
*** fragatin_ has joined #openstack-nova01:31
*** fragatin_ has quit IRC01:31
openstackgerritHuan Xie proposed openstack/nova master: WIP: Fix race condition when neutron is using minimized poll  https://review.openstack.org/44423001:31
*** ngupta has quit IRC01:33
*** ngupta has joined #openstack-nova01:33
*** fragatina has quit IRC01:33
*** esberglu has quit IRC01:34
*** fragatina has joined #openstack-nova01:36
*** gcb has joined #openstack-nova01:39
*** MasterOfBugs has joined #openstack-nova01:40
*** fragatin_ has joined #openstack-nova01:40
*** fragatina has quit IRC01:41
*** fragatin_ has quit IRC01:41
*** jamesdenton has joined #openstack-nova01:41
*** ijw has quit IRC01:44
*** scottda has quit IRC01:45
*** hongbin has joined #openstack-nova01:45
*** ijw has joined #openstack-nova01:48
*** iceyao has joined #openstack-nova01:51
*** ijw has quit IRC01:52
*** ssurana has joined #openstack-nova01:54
*** jamesdenton has quit IRC01:54
*** vishwanathj has joined #openstack-nova01:56
openstackgerritTakashi NATSUME proposed openstack/nova master: api-ref: Fix response code and parameters in evacuate  https://review.openstack.org/45716701:57
*** vishwanathj has quit IRC01:58
*** vishwanathj has joined #openstack-nova01:58
*** vishwanathj has quit IRC02:03
*** iceyao has quit IRC02:03
*** vishwanathj has joined #openstack-nova02:04
*** iceyao has joined #openstack-nova02:04
*** nic has quit IRC02:08
openstackgerritKen'ichi Ohmichi proposed openstack/nova master: Remove json-schema extension variable for resize  https://review.openstack.org/45743002:10
oomichigmann: alex_xu: ^^^ is easy one02:11
*** thorst has joined #openstack-nova02:13
*** yamahata has quit IRC02:14
alex_xuoomichi: got it02:14
*** jamesdenton has joined #openstack-nova02:14
*** jamesdenton has quit IRC02:16
*** thorst has quit IRC02:18
gmannoomichi: +1, i did search final schema for resize due to that name, thanks02:19
alex_xuoomichi: done02:20
oomichigmann: alex_xu: thanks :)02:20
alex_xuoomichi: np02:21
*** jamesdenton has joined #openstack-nova02:21
oomichigmann: yeah, I found this on the review of https://review.openstack.org/45557002:21
oomichigmann: I guessed the resize jsonschema was extended from the name, but actually not. so it would be better to rename02:22
gmannoomichi: yea02:22
*** hshiina has joined #openstack-nova02:26
*** TheJulia has quit IRC02:26
*** gouthamr has quit IRC02:27
*** khappone_ has quit IRC02:27
*** khappone has joined #openstack-nova02:27
*** rajinir has quit IRC02:28
oomichitakashin: can you take a look at https://review.openstack.org/#/c/457167 ?  I am not sure the error status code 503 also is necessary for evacuate API02:28
takashinoomichi: Thank you for your review.02:29
*** TheJulia has joined #openstack-nova02:29
takashinoomichi: I don't know 503 is necessary or not, too.02:30
*** rajinir has joined #openstack-nova02:30
oomichitakashin: I did some investigation now and actually APIs which could return 503 are fping and tenant-network only02:33
oomichitakashin: the corresponding api-ref contains it on these APIs.02:33
oomichitakashin: the other api-ref which includes this case should be invalid I think now02:34
takashinoomihi: Thanks. I will remove 503 in evacuate API reference.02:34
oomichitakashin: cool, thanks02:34
*** hongbin_ has joined #openstack-nova02:34
*** hongbin_ has quit IRC02:36
*** hongbin has quit IRC02:36
*** hongbin has joined #openstack-nova02:37
*** jamesdenton has quit IRC02:46
*** eliqiao has joined #openstack-nova02:48
oomichigmann: about https://review.openstack.org/#/c/456430  I did think about it before, but I don't have strong opinion about that02:48
oomichigmann: the enum list clearly says the type is string even if not having 'type'02:48
*** iceyao has quit IRC02:49
oomichigmann: it is also an option to remove 'type' from such definitions instead02:49
oomichifor consistency02:49
gmannoomichi: actually, enum values can be accessed  with index so it was confusing to me. but yes json schema defien enum always a string i think02:50
oomichigmann: it also would be fine to add type to all schema, but current patch seems necessary to be updated anyways02:53
openstackgerritTakashi NATSUME proposed openstack/nova master: api-ref: Fix response code and parameters in evacuate  https://review.openstack.org/45716702:55
gmannoomichi: did not get, you mean to updated with takashin comments ?02:55
*** diga has quit IRC02:55
oomichigmann: yep02:55
*** diga has joined #openstack-nova02:55
gmannoomichi: yea i can incorporate those separately if takashin is ok :)02:56
gmanntakashin: ^^ what you say?02:56
*** coreywright has quit IRC03:00
*** gjayavelu has joined #openstack-nova03:01
takashingmann: You can do it separately. But it is small changes. So it is good for reviewers to do it together.03:02
*** zhurong has quit IRC03:03
*** tonyb has quit IRC03:04
*** dave-mccowan has quit IRC03:05
*** nicolasbock has quit IRC03:05
*** iceyao has joined #openstack-nova03:06
*** tjones has joined #openstack-nova03:07
*** sudipto has joined #openstack-nova03:08
*** sudipto_ has joined #openstack-nova03:08
*** tonyb has joined #openstack-nova03:09
gmanntakashin: sure, ll do03:09
*** gjayavelu has quit IRC03:09
*** ngupta has quit IRC03:10
*** tonyb has quit IRC03:12
*** zhurong has joined #openstack-nova03:12
*** tonyb has joined #openstack-nova03:13
*** thorst has joined #openstack-nova03:14
*** coreywright has joined #openstack-nova03:18
*** thorst has quit IRC03:18
*** iceyao has quit IRC03:20
*** iceyao has joined #openstack-nova03:21
*** amotoki has joined #openstack-nova03:22
*** imacdonn has quit IRC03:28
*** tonyb has quit IRC03:28
*** imacdonn has joined #openstack-nova03:28
*** tonyb has joined #openstack-nova03:28
oomichitakashin: one question about https://review.openstack.org/#/c/414926/39/nova/tests/functional/test_servers.py03:30
oomichitakashin: why do we need to specify a certain image_uuid for these test cases?03:30
takashinoomichi: Just a moment, please.03:31
oomichitakashin: New tests seem to require the same host only, so I could not understand why we need to specify image_uuid03:31
*** iceyao has quit IRC03:35
*** iceyao has joined #openstack-nova03:36
*** links has joined #openstack-nova03:40
*** iceyao has quit IRC03:42
*** Dinesh_Bhor has joined #openstack-nova03:44
*** hshiina has quit IRC03:47
*** kaisers has joined #openstack-nova03:49
*** eliqiao has quit IRC03:50
*** sridharg has joined #openstack-nova03:51
*** trinaths has joined #openstack-nova03:53
openstackgerritHuan Xie proposed openstack/nova master: WIP: XenAPI use os-xenapi V2 in nova  https://review.openstack.org/45349303:54
takashinoomichi: Image API was deprecated in API version 2.36.03:55
takashinoomichi: So an error is raised in https://github.com/openstack/nova/blob/5a556a720f5a7394cab4c84fa6202976c6190b23/nova/tests/functional/integrated_helpers.py#L141 .03:55
oomichitakashin: does that mean 2.36+ functional tests should specify image_uuid, right?03:56
takashinoomichi; And I modified _build_minimal_create_server_request method in _IntegratedTestBase,03:57
*** fragatina has joined #openstack-nova03:57
takashinoomichi: Yes. (in my modification.)03:57
oomichitakashin: I see, thanks. Then it would be better to have NOTE on https://review.openstack.org/#/c/414926/39/nova/tests/functional/integrated_helpers.py03:58
oomichito explain the above your comment03:58
takashinoomichi: Thank you for your review. I will add a note.03:59
oomichitakashin: thanks again :)03:59
*** zhurong has quit IRC04:00
*** tjones has quit IRC04:00
*** hshiina has joined #openstack-nova04:01
*** kaisers has quit IRC04:02
*** iceyao has joined #openstack-nova04:03
*** hongbin has quit IRC04:06
*** iceyao has quit IRC04:08
*** ngupta has joined #openstack-nova04:10
*** esberglu has joined #openstack-nova04:11
*** thorst has joined #openstack-nova04:15
*** esberglu has quit IRC04:15
*** gyee has quit IRC04:17
*** zhurong has joined #openstack-nova04:17
*** thorst has quit IRC04:19
*** zhurong has quit IRC04:25
*** yongjiexu has joined #openstack-nova04:28
*** ijw has joined #openstack-nova04:29
*** takashin has left #openstack-nova04:31
*** udesale has joined #openstack-nova04:32
*** huanxie has quit IRC04:32
*** psachin has joined #openstack-nova04:33
*** fragatina has quit IRC04:35
*** fragatina has joined #openstack-nova04:36
*** yogesh_ has joined #openstack-nova04:36
*** yogesh_ has quit IRC04:37
*** ayogi has joined #openstack-nova04:38
*** diga has quit IRC04:40
*** huanxie has joined #openstack-nova04:42
*** phuongnh has joined #openstack-nova04:43
*** ratailor has joined #openstack-nova04:44
*** Jack_Iv has joined #openstack-nova04:45
*** Jack_Iv has quit IRC04:50
*** yongjiexu has quit IRC04:57
*** yongjiexu has joined #openstack-nova04:57
*** zhurong has joined #openstack-nova05:00
*** kaisers has joined #openstack-nova05:03
*** yongjiexu has quit IRC05:03
*** yongjiexu has joined #openstack-nova05:04
*** esberglu has joined #openstack-nova05:08
*** yongjiexu has quit IRC05:08
*** esberglu has quit IRC05:08
*** esberglu has joined #openstack-nova05:08
*** bmace has quit IRC05:12
*** jamielennox is now known as jamielennox|away05:12
*** esberglu has quit IRC05:13
*** bmace has joined #openstack-nova05:13
*** ijw has quit IRC05:14
openstackgerritHuan Xie proposed openstack/nova master: XenAPI: Create linux bridge in dest host during live migration  https://review.openstack.org/45165705:14
*** thorst has joined #openstack-nova05:15
*** jamielennox|away is now known as jamielennox05:17
*** sudipto_ has quit IRC05:18
*** sudipto has quit IRC05:18
*** sudipto_ has joined #openstack-nova05:19
*** sudipto has joined #openstack-nova05:19
*** sudipto_ has quit IRC05:19
*** sudipto has quit IRC05:19
*** thorst has quit IRC05:20
*** prateek has joined #openstack-nova05:23
*** fragatina has quit IRC05:31
*** Jack_Iv has joined #openstack-nova05:33
*** gcb has quit IRC05:33
openstackgerritHuan Xie proposed openstack/nova master: WIP: XenAPI use os-xenapi V2 in nova  https://review.openstack.org/45349305:37
*** yasemin has left #openstack-nova05:38
*** ekuris has joined #openstack-nova05:38
*** gcb has joined #openstack-nova05:46
*** iceyao has joined #openstack-nova05:47
*** crushil has quit IRC05:48
*** mdnadeem has joined #openstack-nova05:50
openstackgerritHuan Xie proposed openstack/nova master: WIP: XenAPI use os-xenapi V2 in nova  https://review.openstack.org/45349305:56
*** karthiks has joined #openstack-nova06:04
*** Oku_OS-away is now known as Oku_OS06:04
*** rcernin has joined #openstack-nova06:06
*** sridharg has quit IRC06:07
*** ijw has joined #openstack-nova06:14
*** thorst has joined #openstack-nova06:16
*** sandanar has joined #openstack-nova06:18
*** sandanar__ has joined #openstack-nova06:18
*** sandanar__ has quit IRC06:20
*** adisky_ has joined #openstack-nova06:20
*** ijw has quit IRC06:21
*** iceyao has quit IRC06:22
openstackgerritHuan Xie proposed openstack/nova master: WIP: XenAPI use os-xenapi V2 in nova  https://review.openstack.org/45349306:24
*** sudipto_ has joined #openstack-nova06:26
*** sudipto has joined #openstack-nova06:26
openstackgerritHuan Xie proposed openstack/nova master: WIP: XenAPI use os-xenapi V2 in nova  https://review.openstack.org/45349306:26
*** bkopilov has joined #openstack-nova06:30
*** ngupta_ has joined #openstack-nova06:32
*** wxy has joined #openstack-nova06:33
*** ngupta has quit IRC06:34
*** vishwanathj has quit IRC06:34
*** vishwana_ has joined #openstack-nova06:34
*** Shunli has joined #openstack-nova06:34
*** iceyao has joined #openstack-nova06:35
*** Shunli has quit IRC06:35
*** thorst has quit IRC06:36
*** Shunli has joined #openstack-nova06:36
*** Shunli has quit IRC06:37
*** Shunli has joined #openstack-nova06:38
*** tesseract has joined #openstack-nova06:40
*** ltomasbo has joined #openstack-nova06:42
*** udesale__ has joined #openstack-nova06:51
*** udesale has quit IRC06:52
*** gabor_antal_ has joined #openstack-nova06:55
*** voelzmo has joined #openstack-nova06:59
*** pcaruana has joined #openstack-nova06:59
*** brault has joined #openstack-nova07:00
*** sridharg has joined #openstack-nova07:06
*** damien_r has joined #openstack-nova07:07
*** voelzmo has quit IRC07:08
*** Jack_Iv has quit IRC07:09
*** CristinaPauna has quit IRC07:09
*** coreywright has quit IRC07:16
*** ijw has joined #openstack-nova07:18
*** yushb has joined #openstack-nova07:19
*** Jack_Iv has joined #openstack-nova07:20
*** CristinaPauna has joined #openstack-nova07:21
*** ijw has quit IRC07:23
*** mlakat has joined #openstack-nova07:27
openstackgerritAlex Xu proposed openstack/nova master: Deprecate Multinic, floatingip action and os-virtual-interface API  https://review.openstack.org/45718107:28
*** markus_z has joined #openstack-nova07:31
*** thorst has joined #openstack-nova07:32
*** jamielennox is now known as jamielennox|away07:34
*** coreywright has joined #openstack-nova07:34
openstackgerritZhenyu Zheng proposed openstack/nova master: Support tag instances when boot  https://review.openstack.org/39432107:35
*** thorst has quit IRC07:37
*** haplo37- has quit IRC07:39
openstackgerritshaofeng cheng proposed openstack/nova master: Update nova version newton to ocata in upgrade.rst  https://review.openstack.org/45719707:39
openstackgerritGábor Antal proposed openstack/nova master: Transform instance.volume_attach.error notification  https://review.openstack.org/45580107:39
*** jpenag is now known as jpena07:40
*** faizy has joined #openstack-nova07:41
*** yushb has quit IRC07:41
*** haplo37_ has joined #openstack-nova07:41
gcbalex_xu:  please help review  https://review.openstack.org/457188 , that fixes http://logs.openstack.org/periodic/periodic-nova-py35-with-oslo-master/74800d1/testr_results.html.gz07:43
gcbalex_xu:  this blocks we release oslo.config 4.0, hope we can fix it in Nova side before we release new version of oslo.config07:45
*** ralonsoh has joined #openstack-nova07:46
*** priteau has joined #openstack-nova07:55
*** karthiks has quit IRC07:58
*** lucas-afk is now known as lucasagomes07:59
*** zzzeek has quit IRC08:00
*** zzzeek has joined #openstack-nova08:00
*** jaosorior has joined #openstack-nova08:03
*** karimb has joined #openstack-nova08:05
*** ssurana has quit IRC08:05
*** ssurana has joined #openstack-nova08:08
*** zhurong has quit IRC08:09
*** ssurana has quit IRC08:10
*** karthiks has joined #openstack-nova08:10
*** bauwser is now known as bauzas08:12
*** iceyao has quit IRC08:13
*** abalutoiu has joined #openstack-nova08:13
*** zenoway has joined #openstack-nova08:14
*** iceyao has joined #openstack-nova08:15
*** iceyao has quit IRC08:17
*** litao has joined #openstack-nova08:17
*** iceyao has joined #openstack-nova08:18
*** MasterOfBugs has quit IRC08:19
*** karimb has quit IRC08:20
*** ijw has joined #openstack-nova08:20
*** karthiks has quit IRC08:21
*** dmk0202 has joined #openstack-nova08:22
*** ijw has quit IRC08:25
*** iceyao has quit IRC08:26
*** zhurong has joined #openstack-nova08:26
openstackgerritLei Zhang proposed openstack/nova master: Add sync traits command for placement  https://review.openstack.org/45012508:27
*** derekh has joined #openstack-nova08:27
openstackgerritLiChaoLei proposed openstack/nova master: Fix bug of delete image_base_image_ref after rebuild instance  https://review.openstack.org/45751408:27
*** jamielennox|away is now known as jamielennox08:28
*** efoley has joined #openstack-nova08:29
*** sandanar_ has joined #openstack-nova08:30
*** openstackgerrit has quit IRC08:33
*** efoley_ has joined #openstack-nova08:34
*** sandanar has quit IRC08:34
*** baoli has joined #openstack-nova08:35
*** efoley has quit IRC08:37
*** baoli has quit IRC08:39
*** litao has quit IRC08:40
*** litao has joined #openstack-nova08:41
*** esberglu has joined #openstack-nova08:46
*** esberglu has quit IRC08:46
*** esberglu has joined #openstack-nova08:46
*** openstackgerrit has joined #openstack-nova08:50
openstackgerritGábor Antal proposed openstack/nova master: [WIP] Transform instance.live_migration_rollback notification  https://review.openstack.org/40212408:50
*** esberglu has quit IRC08:51
*** winston-d_ has quit IRC08:53
*** karimb has joined #openstack-nova08:54
*** sapcc-bot has joined #openstack-nova08:57
*** tpatzig_ has joined #openstack-nova08:57
*** dgonzalez_ has joined #openstack-nova08:57
*** carthaca_ has joined #openstack-nova08:57
*** mkoderer_ has joined #openstack-nova08:57
*** seife_ has joined #openstack-nova08:57
*** databus23_ has joined #openstack-nova08:57
*** david_1 has joined #openstack-nova08:57
*** databus23_ has quit IRC08:59
*** seife_ has quit IRC08:59
*** mkoderer_ has quit IRC08:59
*** carthaca_ has quit IRC08:59
*** dgonzalez_ has quit IRC08:59
*** tpatzig_ has quit IRC08:59
*** david_1 has quit IRC08:59
openstackgerritHuan Xie proposed openstack/nova master: WIP: XenAPI use os-xenapi V2 in nova  https://review.openstack.org/45349309:02
*** sapcc-bot2 has quit IRC09:02
*** kaisers has quit IRC09:07
*** cdent has joined #openstack-nova09:09
openstackgerritRoman Podoliaka proposed openstack/osc-placement master: tests: add a hook for functional testing in the gate  https://review.openstack.org/45212209:09
openstackgerritRoman Podoliaka proposed openstack/osc-placement master: CLI for resource providers  https://review.openstack.org/45753209:09
openstackgerritRoman Podoliaka proposed openstack/osc-placement master: CLI for inventories  https://review.openstack.org/45753309:09
openstackgerritRoman Podoliaka proposed openstack/osc-placement master: CLI for allocations  https://review.openstack.org/45753409:09
openstackgerritRoman Podoliaka proposed openstack/osc-placement master: CLI for usages  https://review.openstack.org/45753509:09
openstackgerritZhenyu Zheng proposed openstack/nova master: Support tag instances when boot  https://review.openstack.org/39432109:13
*** gszasz has joined #openstack-nova09:16
*** sambetts|afk is now known as sambetts09:19
*** ijw has joined #openstack-nova09:21
*** Robby__ has joined #openstack-nova09:22
alex_xugcb: done09:23
*** ijw has quit IRC09:26
*** xinliang_ has quit IRC09:27
*** xinliang has joined #openstack-nova09:27
*** sandanar__ has joined #openstack-nova09:32
*** thorst has joined #openstack-nova09:34
*** sandanar_ has quit IRC09:36
*** gongysh has joined #openstack-nova09:37
*** thorst has quit IRC09:38
*** moshele has joined #openstack-nova09:39
*** zhurong has quit IRC09:42
openstackgerritAlex Xu proposed openstack/nova master: Deprecate Multinic, floatingip action and os-virtual-interface API  https://review.openstack.org/45718109:43
*** fragatina has joined #openstack-nova10:01
*** NikhilS has quit IRC10:01
*** trinaths has left #openstack-nova10:03
*** kaisers has joined #openstack-nova10:03
*** nicolasbock has joined #openstack-nova10:04
openstackgerritfalseuser proposed openstack/nova master: [BugFix] Check the instance task status to release the memory quota for vram  https://review.openstack.org/45605010:05
*** tovin07_ has quit IRC10:13
*** Guest27975 is now known as BobBall10:13
johnthetubaguycdent: am I right to worry about this one? https://review.openstack.org/#/c/448791/710:15
*** phuongnh has quit IRC10:15
cdentjohnthetubaguy: reading10:15
*** hshiina has quit IRC10:16
gcbalex_xu: thanks10:17
cdentjohnthetubaguy: your comments are mostly reasonable (and you did find a bug), but I'm not sure you should "worry"?10:18
johnthetubaguycdent: heh, I am just a worrier10:18
johnthetubaguycdent: s/1.5/1.6/ I guess?10:19
cdentthe pattern for how to deal with microversions in the gabbi tests has yet to emerge, in that particular file it is "put diferences near to one another so we can compare"10:19
johnthetubaguycdent: I was curious about the gabby stuff, do we really want to modify those old tests to request a different version?10:19
cdentbut it might be better to do what you suggest "group the new version"10:19
cdentthe 1.5, 1.6 thing is the bug10:19
johnthetubaguyyeah, but those tests, we should probably best both request no version, and request 1.6 I guess?10:20
cdentthe use of a version is to be explicit in the test so that it is clear that we are instentionally saying "I want a version that has a version I know" rather than "I want the default version"10:20
cdentthe intention isn't to test that microversions work10:20
cdentthat's tested elsewhere10:20
cdentthe intention is to test that the behavior at known microversions is what we expect, and to be explicit about it10:21
cdenthowever10:21
cdentgiven that you found a bug in reading the code that the tests did not catch, there's probably an adjustment that needs to be made10:21
*** cNilesh has quit IRC10:22
johnthetubaguyI know before in nova-api we said, test bottom, test top, test change points10:22
*** ijw has joined #openstack-nova10:23
cdentthat might be a good idea, but we haven't established that yet10:23
johnthetubaguywe missed some of the test change points in the past though, and end up with a discontinuity in bits of the API being supported, i.e. we missed the "change" point that needed testing10:23
* cdent nods10:23
johnthetubaguynot in placement, I think that was assumed in nova-api10:23
cdentI'll look at making it more betterer10:23
johnthetubaguycdent: I guess I just like seeing tests not changed when I don't want the behaviour to change, if that makes sense10:24
cdentyeah, that makes sense10:24
johnthetubaguyI just don't trust my eyes to review that stuff properly10:24
*** kevinz has quit IRC10:25
cdentI think adding instead of changing is probably a good idea. It is a bit harder to do cleanly in the gabbi stuff because we're in a single session there and I really want to avoid this situation where we create giant gabbi files. Might need to do some of it in separate files.10:25
johnthetubaguytesting all those negative tests for top a middle makes no sense to me either, so clearly a middle ground there10:25
johnthetubaguyyeah, thats true10:25
*** zenoway has quit IRC10:26
*** zenoway has joined #openstack-nova10:26
*** sdague has joined #openstack-nova10:26
johnthetubaguyI was thinking you just repeat one negative test with version 1.6, to confirm it works, a test to confirm the API is removed in 1.7, just leave the old tests as they are, and test the new 1.7 in isolation, was what I was thinking?10:27
johnthetubaguynot sure if that fits with what you were thinking?10:27
*** ijw has quit IRC10:27
* cdent has not had enough coffee yet to be fully thinking10:28
*** egonzalez has joined #openstack-nova10:28
cdentit sounds reasonable, I'll have to see what comes out when I start playing with it properly.10:28
johnthetubaguyyeah10:29
cdentbut yeah, thank you, is very good input10:31
johnthetubaguyno worries, happy to help10:31
*** gongysh has quit IRC10:31
*** esberglu has joined #openstack-nova10:34
*** thorst has joined #openstack-nova10:34
*** rmart04 has joined #openstack-nova10:35
cdentjohnthetubaguy: on the RT, the fallback was something that matt said ought to happen, to be extra nice. I'm not sure about adding the warning. Is that the usual behavior? Seems noisy to me.10:37
johnthetubaguycdent: we sometimes only warn the first time, but that does overcomplicate things10:38
*** esberglu has quit IRC10:38
johnthetubaguycdent: maybe debug is best, I am just thinking about scratching my head debugging things in the future really10:38
*** thorst has quit IRC10:39
*** zenoway has quit IRC10:40
*** zenoway has joined #openstack-nova10:44
*** Jack_Iv has quit IRC10:46
*** jaosorior has quit IRC10:55
*** geekinutah has quit IRC10:58
*** geekinutah has joined #openstack-nova10:58
*** kaisers has quit IRC11:00
*** jaosorior has joined #openstack-nova11:01
*** zenoway has quit IRC11:02
*** zenoway has joined #openstack-nova11:02
*** zenoway has quit IRC11:07
*** zenoway has joined #openstack-nova11:07
*** zhurong has joined #openstack-nova11:12
*** lucasagomes is now known as lucas-hungry11:14
*** ratailor has quit IRC11:15
cdentjohnthetubaguy: ah, part of the reason for those explicit microversions is because the tests in tha file are using a default of 'latest'11:15
*** ratailor has joined #openstack-nova11:15
johnthetubaguycdent: ah... I missed that11:15
cdentI still think there are some good cleanups that can be made based on your idea though.11:16
openstackgerritMikhail Feoktistov proposed openstack/nova master: libvirt: Virtuozzo containers config drive support  https://review.openstack.org/44981811:17
*** smatzek has joined #openstack-nova11:19
*** moshele has quit IRC11:20
*** ijw has joined #openstack-nova11:24
*** med_ has quit IRC11:28
*** baoli has joined #openstack-nova11:28
*** peter-hamilton has quit IRC11:28
*** ijw has quit IRC11:29
*** med_ has joined #openstack-nova11:30
*** med_ is now known as Guest4551211:30
openstackgerritAlex Xu proposed openstack/nova master: Fix the evacuate API without json-schema validation in 2.13  https://review.openstack.org/45757711:31
alex_xusdague: ^ a easy fix, but do you have any suggestion about how to test it?11:32
*** bkopilov has quit IRC11:33
*** baoli has quit IRC11:34
*** vladikr has joined #openstack-nova11:35
*** voelzmo has joined #openstack-nova11:37
*** baoli has joined #openstack-nova11:37
*** moshele has joined #openstack-nova11:38
cdentjohnthetubaguy: you're having a banner day: you've caused me to find what might be a bug in gabbi11:39
*** karimb has quit IRC11:40
*** thorst has joined #openstack-nova11:43
*** Jack_Iv has joined #openstack-nova11:44
sdaguealex_xu: the way that stack is written, not really11:46
sdaguealex_xu: it would be a little interesting if instead of the function stack the decorator was registering alias entries for every microversion, so you could see if they were missing11:48
*** edmondsw has joined #openstack-nova11:52
*** yassine has joined #openstack-nova11:53
*** yassine is now known as Guest8617011:53
*** Guest15696 has quit IRC11:54
*** fragatina has quit IRC11:55
*** kaisers has joined #openstack-nova11:55
*** hshiina has joined #openstack-nova11:57
*** dillaman has quit IRC12:08
*** dave-mccowan has joined #openstack-nova12:08
openstackgerritChris Dent proposed openstack/nova master: Update resource tracker to PUT custom resource classes  https://review.openstack.org/45691512:17
openstackgerritChris Dent proposed openstack/nova master: [placement] Idempotent PUT /resource_classes/{name}  https://review.openstack.org/44879112:17
openstackgerritMonty Taylor proposed openstack/python-novaclient master: Add novaclient client_name and client_version to user-agent  https://review.openstack.org/45663812:17
cdentmordred: did you see the comment I've just left on ^?12:17
mordredcdent: nope! missed it - looking12:17
mordredcdent: ah- so, for that case, "app_name" is the thing the person should be setting12:18
mordredand it gets set on the Session12:18
cdentmeh, ETOOMANYKNOBS12:18
mordredcdent: (or, if they're doing something like shade and making a client that other apps use, there is another nob - but this should work in all those cases)12:19
*** salv-orlando has joined #openstack-nova12:19
mordredone could argue in favor of exposing app_name in novaclient constructor to allow a user to set it for the cases where novaclient creates the session for the user -but honestly - I think that falls into "just create the session yourself and pass it in" :)12:20
cdentso often in these things it seems like we are creating abstractions for stuff that has normal real world names and interaction mode (such as "user-agent")12:20
*** dillaman has joined #openstack-nova12:20
*** udesale__ has quit IRC12:22
*** esberglu has joined #openstack-nova12:24
*** esberglu has quit IRC12:24
*** lucas-hungry is now known as lucasagomes12:24
*** ijw has joined #openstack-nova12:26
*** ngupta_ has quit IRC12:27
*** ngupta has joined #openstack-nova12:27
*** gouthamr has joined #openstack-nova12:30
*** ijw has quit IRC12:31
mordredyah12:32
*** karimb has joined #openstack-nova12:32
mordredcdent: well, that's because abstractions make everytihng better12:32
cdentI heard that somewhere12:32
sdaguemordred: https://review.openstack.org/#/c/456344/ ... no special ports on keystone, also it was interesting what fell out of that in the process12:35
mordredsdague: zomg I'm so excited about that12:35
*** jpena is now known as jpena|lunch12:36
*** gongysh has joined #openstack-nova12:37
*** gongysh has quit IRC12:38
*** rfolco has joined #openstack-nova12:38
*** gongysh has joined #openstack-nova12:39
*** gongysh has quit IRC12:40
*** ayogi has quit IRC12:41
*** pchavva has joined #openstack-nova12:43
*** ngupta has quit IRC12:43
*** zhurong has quit IRC12:45
*** dimtruck is now known as zz_dimtruck12:49
*** lyan has joined #openstack-nova12:50
*** kylek3h has joined #openstack-nova12:50
alex_xusdague: ah, thanks, let me thinking how to make it happen12:52
*** Matias has joined #openstack-nova12:53
sdaguealex_xu: I think it would require a more substantial rewrite here12:53
sdaguehonestly, we should fix this issue12:53
*** baoli has quit IRC12:54
sdaguebut I think in general there are some changes to the way these decorators work that might make it harder to make mistakes like this12:54
*** moshele has quit IRC12:56
*** timello has joined #openstack-nova12:56
mordredsdague: on the novaclient patch above - you think docstring is a good place to document?12:57
sdaguemordred: wherever makes it so it ends up here - https://docs.openstack.org/developer/python-novaclient/api.html12:58
mordredkk12:58
*** gcb has quit IRC13:00
bauzasmordred: sdague: I think a reno patch is good enough for documenting that https://review.openstack.org/#/c/456638/313:00
bauzasof course amending the doc is the better approach, but a note would help people knowing the new possibility13:01
*** esberglu has joined #openstack-nova13:01
bauzas(and the alternative)13:01
*** Shunli has quit IRC13:03
sdaguebauzas: it's a client api, I'd rather just make it clear how to set the agent string up front13:03
openstackgerritMonty Taylor proposed openstack/python-novaclient master: Add novaclient client_name and client_version to user-agent  https://review.openstack.org/45663813:03
mordredhow's that?13:03
alex_xusdague: all the versioned method are stored in the a class method, I think I can check that list13:03
sdagueI always think about how clear it is in these docs - http://search.cpan.org/dist/libwww-perl/lib/LWP.pm#An_Example13:03
*** Jack_Iv has quit IRC13:04
sdaguemordred: works for me13:04
sdaguemordred: thanks13:04
*** sudipto has quit IRC13:04
*** sudipto_ has quit IRC13:04
*** xyang1 has joined #openstack-nova13:04
bauzassdague: I totally agree with you, I'm just advocating on a rather operator/end-user perspective13:05
mordredsdague: woot!13:05
bauzasmeaning that I should see my UA logs be changed once I start using the new release of novaclient13:06
bauzasmordred: +W'aboom13:06
*** jaosorior has quit IRC13:06
mordred\o/13:07
mordredI have made a success today!13:07
*** mdrabe has joined #openstack-nova13:08
*** ngupta has joined #openstack-nova13:09
bauzasalways a pleasure to come back from an holiday period by helping others :)13:09
*** jamesdenton has joined #openstack-nova13:10
*** mriedem has joined #openstack-nova13:10
mriedemo/13:10
bauzas'supp13:11
*** baoli has joined #openstack-nova13:13
*** ngupta has quit IRC13:14
*** jaosorior has joined #openstack-nova13:14
*** Jack_Iv has joined #openstack-nova13:15
*** smatzek has quit IRC13:21
*** prateek has quit IRC13:22
mriedembauzas: have you gone through the latest comments in the claims in scheduler spec? https://review.openstack.org/#/c/437424/13:26
bauzasmriedem: yup, I was waiting for all the folks to be around before pinging all of you13:26
bauzasmriedem: looks like the consensus changed ?13:27
bauzasmriedem: now, the compute node should HTTP get the list of allocations instead of having those passed thru RPC, correct?13:27
*** pcaruana has quit IRC13:27
*** ijw has joined #openstack-nova13:27
bauzasmriedem: also, seems like there was kind of a confusion where the POST allocations should be called, ie. in the conductor vs. scheduler13:28
openstackgerritRoman Podoliaka proposed openstack/osc-placement master: tests: add a hook for functional testing in the gate  https://review.openstack.org/45212213:28
bauzasFWIW, I thought we all agreed to have the conductor doing that13:28
bauzas(during the hangout)13:28
mriedembauzas: i thought that when i thought, incorrectly, that the conductor got the list of filtered and weighed hosts13:29
bauzasyup13:29
mriedemwe could do it in either, but it seems to me it would be better to retry by just hitting the next host in the list of already filtered hosts, in the scheduler,13:29
mriedemrather than having conductor ask the scheduler to pull a fresh new set all over again13:30
andreykurilinhi folks! Could someone look at small (+9, -5) patch to novaclient  https://review.openstack.org/#/c/450763/ ?13:30
*** eharney has quit IRC13:30
bauzastbc, the conductor only get a subset of hosts returned by the scheduler, not all the accepted nodes13:30
bauzaswhere the default subset is 113:30
bauzasmriedem: the problem wasn't really with the POST logic, rather the DELETE allocation logic when rescheduling or moving the instance13:31
mriedemright, i didn't realize that until yesterday13:31
mriedembauzas: i think it's fine to do the delete in conductor on reschedules13:31
bauzasmriedem: given the scheduler doesn't know whether it's a boot request, or a move13:31
mriedemlike we do for cleaning up bdms and ports13:31
bauzasokay13:32
bauzasfine by me then13:32
bauzasthat's 2 distinct situations13:32
mriedemok, think you can have the spec updated today?13:32
*** ijw has quit IRC13:32
bauzaswe could POST the allocation in the current synchronous method we have13:32
mriedemandreykurilin: why does that really need to change? does it just bug you? or is something building on that later?13:32
bauzasand then DELETE allocations for reschedules/moves in the conductor13:33
*** bkopilov has joined #openstack-nova13:33
bauzasmriedem: yup, was planning to13:33
mriedembauzas: post somewhere in here? https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L12413:33
bauzasnope13:33
mriedemhttps://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L80 ?13:34
bauzasmriedem: within consume_from_request https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L13113:34
bauzasbecause it's a synchronous method13:34
bauzasI mean there is a semaphore13:34
bauzassynchronous section of code13:35
*** links has quit IRC13:35
bauzasdammit, 3.5 days out of OpenStack and my English is still on holiday :/13:35
mriedemso https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L27113:35
bauzasprobablement oui13:35
bauzasbut that's an implementation detail IMHO13:36
andreykurilinmriedem: I just saw an usage of that method in some script and it was not clear what does it accept without searching at docs.o.o/nova (usually, looking at novaclient's docstring is enough)13:36
*** jpena|lunch is now known as jpena13:38
*** Oku_OS is now known as Oku_OS-away13:40
mriedemdo we have some sort of memory overhead estimate code in the virt drivers that impacts scheduling via the resource tracker?13:41
mriedemah estimate_instance_overhead13:42
*** burt has joined #openstack-nova13:42
*** Robby__ has quit IRC13:42
mriedemwow that's a fun method, it can get 1 of 3 different input parameter types13:43
mriedembauzas: hmm, so that's going to be something interesting that will have to be taken into account to do claims in the scheduler13:45
mriedemtotally coincidental but someone internal was asking about this for kvm13:45
efriedmriedem I know the PowerVM code for estimate_instance_overhead is... interesting.13:45
mriedembut i see RT.instance_claim calls estimate_instance_overhead on the virt driver13:45
mriedemso how are we going to get this information from the virt driver when we're doing it in the scheduler13:46
*** cleong has joined #openstack-nova13:46
*** iceyao has joined #openstack-nova13:47
mriedemoh it looks like sahid just implemented this for the libvirt driver13:47
*** mlavalle has joined #openstack-nova13:47
efriedmriedem Link?13:47
efriedIs this something all drivers (including OOT) will need to make changes for?13:48
mriedemhttps://review.openstack.org/#/c/385364/13:48
mriedemwait link to what?13:48
mriedemefried: claims in the scheduler spec https://review.openstack.org/#/c/437424/13:48
efriedYeah, that.  Thanks.13:48
efriedmriedem FYI: https://github.com/openstack/nova-powervm/blob/master/nova_powervm/virt/powervm/driver.py#L24913:49
*** hongbin has joined #openstack-nova13:50
mriedembtw, the fact we can pass in 3 different things to this...13:51
efriedYeah... awkward13:51
mriedemterrible13:51
mriedemif it should just always be a flavor, we should just do that13:52
mriedemi like how the powervm driver is turning it into a flavor at the start13:52
efriedmriedem If the caller(s) just changed to always use a flavor, it remains compatible, and consumers can clean out dead code at their leisure.13:53
*** zenoway has quit IRC13:53
*** zenoway has joined #openstack-nova13:54
efriedworthy of a (possibly specless) blueprint?13:55
*** Oku_OS-away is now known as Oku_OS13:55
*** hshiina has quit IRC13:57
mriedemprobably don't need a blueprint. we could also use a new method and deprecate the old one. or just as you say always pass a flavor and update the docstrings and let virt drivers get updated13:57
*** zenoway has quit IRC13:58
*** crushil has joined #openstack-nova13:58
*** zenoway has joined #openstack-nova13:59
bauzasmriedem: sorry, my IRC client crashed silently14:00
bauzasmriedem: what do you mean ?14:00
mriedemjaypipes: does memory_mb_used on the compute node find it's way into placement anywhere?14:00
bauzasyup, some virt drivers reserve some overhead, like Xen AFAIK14:01
*** sandanar__ has quit IRC14:01
mriedemi only see cn.memory_mb used for inventory on the MEMORY_MB resource class for the compute RT14:01
mriedem*RP14:01
mriedembauzas: xen, hyperv and now libvirt14:01
mriedemwhich impacts how cn.memory_mb_used is reported in the RT14:01
mriedemand cn.free_ram_mb14:01
*** kevinz has joined #openstack-nova14:01
bauzasmriedem: memory_mb_used is just summing the flavor.memory for all the running instances AFAIK14:01
bauzasmriedem: compared to the total size which is returned by the hypervisor14:02
mriedemvia get_available_resource right?14:02
mriedemor get_inventory14:02
bauzasyup14:02
bauzasformerly get_avail_resource IIRC14:03
mriedemright so when we make a claim for a new instance, https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L14414:03
bauzaswith ironic, get_inventory14:03
mriedemwe calculate the overhead for the vm14:03
mriedemand the claim.memory_mb is based on the instance.flavor.memory_mb + that overhead value from the compute driver14:04
bauzasright14:04
*** ngupta has joined #openstack-nova14:04
*** ngupta has quit IRC14:04
*** priteau has quit IRC14:04
*** eharney has joined #openstack-nova14:05
mriedemwhat i'm trying to figure out,14:05
*** ngupta has joined #openstack-nova14:05
mriedemis if this overhead estimate from the virt driver factors into scheduling decisions in the scheduler anywhere14:05
*** Guest45512 is now known as med_14:05
*** med_ has quit IRC14:05
*** med_ has joined #openstack-nova14:05
mriedemor is it something we can only determine once we're on a host, find out that with the overhead we are over the limit, and fail the claim test14:05
mriedemand trigger a retry14:05
*** efoley_ is now known as efoley14:06
bauzasmriedem: the RamFilter doesn't get that for a specific virt driver, so I'd assume no14:06
*** ekuris has quit IRC14:06
mriedemright. but do we record it in the allocation record?14:06
mriedemin placement14:06
bauzasthe overhead ?14:07
mriedeme.g. if the full allocation for MEMORY_MB for a given instance is instance.flavor.memory_mb + overhead from virt driver, do we put that into the allocation?14:07
mriedemor just instance.flavor.memory_mb?14:07
mriedemthe overhead value that comes out of virt.estimate_instance_overhead14:07
bauzaswell, all happens in _update_usage_from_instance so looking14:07
*** sudipto_ has joined #openstack-nova14:08
*** sudipto has joined #openstack-nova14:08
bauzasmriedem: looks like it's not14:08
jaypipesmriedem: yes, it's the inventory for MEMORY_MB :)14:08
bauzasmriedem: https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L15614:09
mriedemaha14:09
mriedemthen yeah that seems like a bug14:09
jaypipesmriedem: what? the overhead?14:09
mriedemyes14:10
mriedembecause https://github.com/openstack/nova/blob/master/nova/compute/claims.py#L10614:10
*** pcaruana has joined #openstack-nova14:10
mriedemwhich is tested in the claim here https://github.com/openstack/nova/blob/master/nova/compute/claims.py#L16814:10
mriedemright?14:10
bauzasjaypipes: the overhead is only calculated when calling the claim AFAICS14:10
*** peter-hamilton has joined #openstack-nova14:10
*** peter-hamilton has quit IRC14:10
mriedemrequested = self.memory_mb == instance.flavor.memory_mb + overhead['memory_mb']14:11
*** peter-hamilton has joined #openstack-nova14:11
jaypipesmriedem: meh, maybe. it's true there's a little bit of possible inconsistency. I was hoping to resolve that with claims in scheduler. but we need to know the virt driver of the target host *before* we actually allocate :( which is tarded.14:11
bauzasmriedem: well, seems like it's self-healed actually14:11
*** zz_dimtruck is now known as dimtruck14:11
mriedemjaypipes: right, so we have this whole chicken and egg14:12
bauzasmriedem: because RT._update_usage() does calculate the overhead past the allocation14:12
bauzasmriedem: and given we call _update() after _update_usage() with the resources that are taking in account that overhead, it auto-heals14:13
jaypipesmriedem: instead of doing the chicken egg thing, I think it's better to instead use the inventory record's reserved value. that may be a coarser-grained solution, but it's certainly cleaner.14:13
johnthetubaguymriedem: probably not a shock, but alot of that memory crazy is Xen related, or at least very related to when you have "hard" memory limits14:13
*** kevinz has quit IRC14:13
cdentshouldn't overhead (as a sum of potentials) be recorded within reserved and _not_ be in the consumer's allocations?14:13
* cdent jinxes with jaypipes 14:13
mriedembauzas: i'm not following the full call chain yet14:13
jaypipescdent: it's overhead *per instance*, whereas reserved is per provider/resource cllass.14:13
bauzaswhat jaypipes said14:13
mriedembauzas: but you agree we can hit ComputeResourcesUnavailable due to the overhead pushing us over right?14:13
cdentjaypipes: I know, thus the "sum of potentials"14:13
jaypipescdent: thus reserved is "more coarse-grained"14:13
cdentand thus the "jinx"14:13
jaypipescdent: right.14:13
jaypipes:)14:14
*** kevinz has joined #openstack-nova14:14
bauzasmriedem: sec, explaining14:14
johnthetubaguyjaypipes: cdent: so the memory overhead is VM specific in some cases (ducks) but I would argue we might want to ignore that14:14
mriedemjohnthetubaguy: exactly14:14
jaypipesjohnthetubaguy: ++14:14
mriedemthe overhead calculation is totally based on the flavor used14:14
bauzasmriedem: so, the RamFilter is calculating against the free ram based on what the RT reports, right?14:14
bauzasmriedem: what I'm saying is that I just saw that we do calculate the overhead when updating the usage in the RT14:15
mriedemso do you then make a generic reserved value for the RT on that provider for what you expect to land on that host flavor-wise?14:15
mriedembauzas: i thought we wanted to deprecate/remove the RamFilter?14:15
mriedembecause we use placement now14:15
johnthetubaguymriedem: yeah, I got the impression that its party host CPU model specific, but I never got a straight answer about that14:15
* cdent thinks we should just take what ever anyone provides as reserved and put a 1<random multiplier<2 on it and let it sort itself out in the wash14:15
* cdent is only half kidding14:15
bauzasmriedem: well, I'm trying to figure out the situation in a pre-placement world14:16
mriedemok, so the reason i'm even looking at this, is because someone internal is looking at this for the libvirt driver and with an example vm they calculated ~226MB of overhead14:16
jaypipesfrankly, mriedem and johnthetubaguy, we're going to end up with a similar issue with the emulator threads.14:16
mriedemwhich isn't being taken into account for scheduling14:16
johnthetubaguyjaypipes: oh, true14:17
jaypipesmriedem, johnthetubaguy: because the reserved amount of those is specific to a virt driver./14:17
openstackgerritDan Smith proposed openstack/nova master: Add functional test for two-cell scheduler behaviors  https://review.openstack.org/45200614:17
jaypipescourse, we need nested providers first, but still, thinking ahead...14:17
mriedemcan we agree that https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L156 should be taking into account the overhead?14:17
dansmithI haven't been paying attention,14:18
bauzasI'm still looking at the 100+ calls involved in the decision-making :)14:18
dansmithbut the overhead should be included in the inventory reserved amount no?14:18
jaypipesmriedem: perhaps, though that may lead to a failure to allocate.14:18
bauzasdansmith: it's per instance14:18
jaypipesdansmith: yeah, per instance...14:18
*** awaugama has joined #openstack-nova14:18
johnthetubaguyso there are a few overheads going around here14:18
dansmithhmm, I must be missing that part14:19
bauzasthe reserved bit is for a global hypervisor overhead14:19
bauzaslike a memory heap size you wanna not touch14:19
mriedemjaypipes: hmm, but what we claim would actually be more than what we report for the actual allocation, agreed?14:19
dansmithhaving allocations include per-instance overhead seems confusing to me, unless it's called out specifically14:19
mriedemor could be14:19
dansmithotherwise it will not be super helpful for use by other tools14:19
jaypipesmriedem: right, which is partly why we didn't include it in that code.14:19
mriedemjaypipes: but shouldn't be as accurate as possible in the allocation since that's going to be used by the scheduler?14:20
jaypipesmriedem: I guess, but the scheduler doesn't ask for that amount :)14:20
dansmithah, estimate_instance_overhead14:21
mriedemi'm going to need a refresher on what the scheduler asks for in placement, is it just based on inventory?14:21
bauzasyep, that's what I was trying to explain14:21
dansmithjaypipes: nor can it, right? it comes from the virt driver14:21
jaypipesmriedem: in other words, the scheduler doesn't say "I want X MEMORY_MB plus some overhead if the instance is on a Xen hypervisor"14:21
bauzasthere are two things to consider14:21
mriedemdansmith: right claims in the scheduler can't use this14:21
jaypipesdansmith: right.14:21
bauzas1/ what you request and 2/ what you have as free14:21
mriedemjaypipes: i realize, that's not what i'm saying though14:21
bauzasin the claim, we add more to request with the overhead but we don't touch 2/14:21
mriedemdo we or don't we look at allocations when figuring out which providers can serve a request in the scheduler?14:22
bauzaswhile we do later in the self-heal process, do decrease 2/14:22
jaypipesmriedem: I think the long-term solution to this is the following:14:22
*** smatzek has joined #openstack-nova14:22
bauzasso, when it comes to placement, the free space is already decremented by the sum of overheads14:22
jaypipesmriedem: add an overheads table to placement API, containing resource_provider_id, resource_class_id, and amount.14:22
bauzas(or when it comes to RAMfilter)14:22
jaypipesmriedem: each record in that table would contain the overhead for that resource class on that provider for each consumer of that resource class.14:22
*** burgerk has joined #openstack-nova14:23
dansmithjaypipes: ooh, yeah I like that14:23
jaypipesmriedem: that way, we can properly model both the inventory and allocation request in the placement API.14:23
dansmithjaypipes: make the virt driver delcare it ahead of time14:23
jaypipesdansmith: right, in the RT's init_compute_node(), etc14:23
mriedembut,14:23
dansmithjaypipes: which kinda pushes us more to a model where we speak about everything in terms of resourceclasses14:23
mriedemthe overhead is a factor of the flavor14:23
BobBalljaypipes: My understanding is the overhead on Xen for RAM is smallish.  Yes, there will be some instances where we are running very tight against total RAM that need rescheduling, but I'm not sure it's worth the code changes to fix it?14:23
dansmithmriedem: right, but make it declare how it calculates it in terms of resource classes14:24
jaypipesmriedem: no, it's a factor of the resource class.14:24
*** dave-mccowan has quit IRC14:24
jaypipesmriedem: each virt driver has a separate overhead for cpu, disk and memory.14:24
dansmithmriedem: because eventually we get rid of weirdo extra specs and it's all resource classes14:24
jaypipesmriedem: and soon, emulator_threads :)14:24
*** moshele has joined #openstack-nova14:24
mriedemhttps://github.com/openstack/nova/blob/master/nova/virt/hyperv/vmops.py#L124 is a simple case14:25
jaypipesBobBall: I think having an overheads table in the placement API containing this information is the best long-term solution. it would make the system data-driven instead of hard-coded in the virt driver.14:25
*** felipemonteiro has joined #openstack-nova14:25
mriedemso the overheads table contains the multiplier?14:25
jaypipesmriedem: right, that's not per-flavor. it's per reesource class..14:25
mriedemfor a given resource class on that provider?14:25
jaypipesyep14:25
dansmithjaypipes: well, that's crossing the line.. because it's disk = memory + N14:25
BobBalljaypipes: OK - but it's going to be a best guess at any rate.  AIUI the actual overhead will depend on the guest type as well as various other factors which we really won't want to encode in any table...14:25
dansmithjaypipes: that one is ... hard14:26
mriedemdansmith: store a lambda in the table?! :P14:26
dansmithmriedem: genius!14:26
* johnthetubaguy bingo14:26
cdentIs there some  way we can do this algorithmically based on the inventory of the node when it starts up, do a calculation, and simply add that to the reserved? Because this all sounds fragile and constantly in need of adding yet more stuff.14:27
cdentIf we know that an average use scenaior of an inventory that looks like X needs a multiplier on some scale...14:27
bauzastbh, looks very dynamic to me, since it's provided by the virt driver14:27
mriedemright, i don't know how we encode this https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L71314:27
bauzasI mean, are we sure the overhead can mathematically be given ?14:27
*** vks1 has joined #openstack-nova14:27
*** ijw has joined #openstack-nova14:29
dansmithmriedem: the libvirt one is not that bad I think, but the hyperv one is14:29
*** ratailor has quit IRC14:29
jaypipesmriedem: I think for that hyperv one, it may just be that the DISK_GB inventory record on hyperv compute nodes needs a pre-set reserved value :(14:29
dansmithalthough the libvirt one would need to be able to specify a trait that increases the cpu overhead by one, I guess14:29
cdent /o\14:30
openstackgerritChris Dent proposed openstack/nova master: Update resource tracker to PUT custom resource classes  https://review.openstack.org/45691514:30
openstackgerritChris Dent proposed openstack/nova master: [placement] Idempotent PUT /resource_classes/{name}  https://review.openstack.org/44879114:30
mriedembauzas: going back to your auto-heal, are you referring to https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L616 which eventually calls _update_usage?14:30
mriedemand then later we call https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L64814:31
jaypipesmriedem: for the emulator threads, I think we can handle that differently...14:31
bauzasmriedem: I'm saying we call https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L77414:31
bauzasbecause indeed we call https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L61614:32
*** baoli has quit IRC14:32
jaypipesmriedem: for libvirt compute nodes, we'd have a fixed number of EMULATOR_THREADS inventory, with no overcommit. For other drivers, we'd have a huge overcommit of EMULATOR_THREADS inventory.14:32
mriedembauzas: right _update_usage_from_instance calls _update_usage14:32
mriedembauzas: but _update just changes the inventory record in placement14:33
bauzasmriedem: so, _update_usage_from_instance calls placement by not adding the overhead14:33
mriedemand the total doesn't change does it?14:33
*** baoli has joined #openstack-nova14:33
bauzasmriedem: but _update updates the inventory with the values it was updated by _update_usage()14:33
* bauzas is having hard time because he's also listening at https://www.youtube.com/watch?v=hkZir1L7fSY14:33
mriedemyes, but, https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L779-L79514:34
mriedemonly sets the used/free values on the cn14:34
mriedemwhich aren't used when setting the inventory in placement for that provider14:34
*** ijw has quit IRC14:34
mriedemhttps://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L11714:34
mriedemthe inventory value comes from driver.get_available_resource/get_inventory, right?14:34
*** udesale has joined #openstack-nova14:34
bauzasmriedem: oh fuck, you're right14:35
jaypipesyes14:35
mriedemYES14:35
mriedemha, ok14:35
mriedemSO...14:35
bauzasit's just updating memory_used14:35
mriedemgoing back to https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L15614:35
bauzasso, not called to placement14:35
mriedem^ is wrong14:35
bauzasmriedem: yup14:35
bauzasmriedem: in a perfect world, we should add that to placement14:35
mriedemlet me look up the voodoo that placement does when scheduler asks for providers for a given reqspec14:35
bauzasmriedem: because RamFilter does that14:35
bauzasand we want placement to behave like the filter14:36
*** kaisers has quit IRC14:36
*** moshele has quit IRC14:37
*** baoli has quit IRC14:38
jaypipesbauzas: I don't care if placement doesn't behave exactly like the RamFilter. I just want placement to be clear, clean, and accurate without leaking implementation details (of the virt driver) out of the API.14:38
*** sudipto_ has quit IRC14:38
*** sudipto has quit IRC14:38
*** eharney has quit IRC14:38
bauzasjaypipes: I couldn't agree more, but at the moment, something could trigger a rescheduler while it could be avoided if we would ask for more14:39
mriedemso when the filter scheduler does the GET /resource_providers?resources=VCPUS:2,MEMORY_MB=4096,DISK_GB=60, it looks like it eventually joins and takes into account allocations on each provider, right?14:39
mriedemi'm lost in the sql14:39
cdentmriedem: that is correct14:39
bauzasmriedem: you're correct14:39
mriedemok14:39
mriedemthanks,14:39
jaypipesmriedem: yes, of course.14:39
mriedemso, it seems https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L156 should then be reporting the full allocation that we actually claimed on the compute node, right?14:40
bauzasso we underestimate the already taken memory14:40
mriedemcorrect14:40
*** baoli has joined #openstack-nova14:40
*** tbachman has joined #openstack-nova14:40
mriedemand we could pike a RP in the scheduler that fails the claim test on the host14:40
mriedembecause maybe we shaved off enough overheads in our allocations reporting that we screwed ourselves14:40
mriedemworst case that just triggers a retry14:40
mriedemUNTIL14:40
mriedemwe don't have retries anymore14:40
bauzasyup, retry14:40
mriedemsee where i'm going :)14:40
bauzasI know14:41
mriedemjaypipes: bauzas: cdent: can we at least agree this is a bug?14:41
jaypipesmriedem: sure :)14:41
bauzasI think we can reasonably assume it is a nice one14:41
mriedemok14:41
mriedemgood14:41
cdentmriedem: yes, there is a mismatch between reality and what's recorded14:41
mriedembecause i started this morning reading this email from a perf guy in china, not knowing anything about this overhead stuff, to realizing there is a bug,14:41
jaypipescdent: that is the plotline of my entire life.14:41
bauzasmeiwelcome in the club14:42
mriedemso i'd like to take that back to him instead of just saying, 'i have no f'ing clue what you're talking about'14:42
bauzasmriedem: welcome in the club14:42
openstackgerritGergely Csatari proposed openstack/nova master: Checking the parameters of servers-actions.inc  https://review.openstack.org/32711214:42
cdentjaypipes: I think there's a good song in there somewhere14:42
sfinucanjaypipes: I see https://review.openstack.org/#/c/361140/ didn't get in before the spec freeze. Think it's a fair candidate for the exception process?14:42
mriedemcdent: every country western song ever14:42
mriedemsfinucan: not imo14:42
cdentmriedem: need to add some tears in my ears from crying on my pillow over you14:43
jaypipessfinucan: not up to me. but I will review today regardless.14:43
sfinucanmriedem: no?14:43
bauzasoh, sfinucan reminded me one14:43
sfinucanany particular reason?14:43
mriedemsfinucan: because at this point we're overcommitted and the only exceptions i'm interested in are for priorities or things that impact all of nova, not narrow use cases14:43
bauzasmriedem: https://review.openstack.org/#/c/450122/18 is getting 2 +2s from jaypipes and me but I refrained my +W, so I leave you use your axe14:44
*** dave-mccowan has joined #openstack-nova14:44
*** nkorabli has joined #openstack-nova14:44
*** jianghuaw_ has joined #openstack-nova14:46
*** iceyao has quit IRC14:47
mriedemi'm -2 on the vgpus one also14:47
mriedemsame reason14:47
sfinucanmriedem: Those use cases are the primary use cases for a lot of our customers14:47
sfinucanthe VGPU less so. That needs more exploration, IMO14:48
mriedemsfinucan: then tell me which of the other red hat priority blueprints you'd like to defer in it's place14:48
mriedememulator threads?14:48
mriedemsecure console proxy?14:48
mriedemyour other pci scheduler one?14:48
sfinucanemulator threads is done14:48
sfinucanthe other PCI scheduler is a two patch change, ~100 line change14:49
sfinucanand, if Gerrit's logs are anything to go by, I'm going to be very fortunate to get the secure console proxy stuff in. No one wants to review it :(14:49
sfinucanthe PCI use cases are my primary focus this cycle. There's no lack of reviewer bandwidth on my end14:50
*** kfarr has joined #openstack-nova14:51
*** eharney has joined #openstack-nova14:53
*** marst has joined #openstack-nova14:54
openstackgerritPeter Hamilton proposed openstack/nova master: Add configuration options for certificate validation  https://review.openstack.org/45767814:56
mriedemsfinucan: you can work with artom on the tagged attach/detach stuff then14:56
mriedemsfinucan: honestly look at what we've already approved https://blueprints.launchpad.net/nova/pike14:57
voelzmo@johnthetubaguy I've updated https://review.openstack.org/#/c/416997 with some comments, not sure how we should continue the discussion14:57
johnthetubaguyvoelzmo: here is fine, for me it was a case of consistency14:59
sfinucanmriedem: Yeah, I've been horse trading with him for reviews on the secure console proxy stuff, heh :)14:59
*** dharinic has joined #openstack-nova14:59
johnthetubaguyvoelzmo: its a strange API to only support this for half of the nic types, thats really hard API docs and validation, etc14:59
johnthetubaguyvoelzmo: but maybe I am seeing it all wrong15:00
*** kevinz has quit IRC15:00
*** tjones has joined #openstack-nova15:00
mriedemspeaking of deleting ports,15:00
mriedemlet's fix latent bugs https://review.openstack.org/#/c/452577/15:00
*** baoli has quit IRC15:00
voelzmo@johnthetubaguy I understand the consistency argument, I just fear that it adds scope that I didn't mean to include. Not sure how special the documentation and code really will get. From what I've seen it is already pretty special in the sense that it sets the 'remove port' flag based on whether nova creates it or the user passed it in15:01
sfinucanmriedem: Also get your point about being oversubscribed, but these are the things I'm paid to care about. If push came to shove, could we drop the secure console proxy work in favour of that15:01
*** baoli has joined #openstack-nova15:01
johnthetubaguyvoelzmo: but saying you can customise only one of those cases seems strange.15:02
sfinucan*that 'share-pci-between-numa-nodes' spec?15:02
voelzmo@johnthetubaguy I agree that for the sake of symmetry that would make sense. Have you heard of someone wanting to keep ports created by nova?15:03
*** timello has quit IRC15:04
*** dharinic has quit IRC15:04
mriedemsfinucan: well, melwitt was also saying in here yesterday that accurately reporting boot from volume disk usage was important for red hat customers, and the answer to fixing that has been claims in the scheduler and shared storage pool resource aggregates15:04
openstackgerritGábor Antal proposed openstack/nova master: Fix the FakeDriver using same hypervisor names  https://review.openstack.org/45623715:05
openstackgerritGábor Antal proposed openstack/nova master: [WIP] Transform instance.live_migration_rollback notification  https://review.openstack.org/40212415:05
mriedemsfinucan: and that's a thing melwitt has been trying to get resolved since at least newton, and we keep saying, "once this is done, and once this is done..."15:05
mriedemand it keeps getting pushed out15:05
*** kfarr has quit IRC15:07
sdagueoomichi: I'm confused by your -1 here - https://review.openstack.org/#/c/454854/215:07
sfinucanmriedem: I can't speak as to the relative importance of the two so I guess I better go ask :)15:08
sfinucanCrucially though, if either of those took precedence would you be OK with us dropping secure console proxy in favour of one of them?15:08
*** rcernin has quit IRC15:09
*** vks1 has quit IRC15:10
johnthetubaguyvoelzmo: I know I wanted that to re-use an IP a few times15:10
voelzmo@johnthetubaguy and you knew that during VM creation already? Because that's where the user will be able to specify this flag15:11
voelzmoChanging it after the fact is not a thing, currently15:11
*** ngupta has quit IRC15:11
mriedemsfinucan: maybe, but it sounds like that's something you need to discuss with your entire team first,15:11
mriedembecause there are several blueprints your team is involved in15:12
mriedemand you guys are going to need to agree before you start proposing something to drop i think15:12
*** udesale has quit IRC15:13
sfinucanmriedem: Yup, we've a team meeting tomorrow. I'll bring that up then and see what the story is15:13
*** ngupta has joined #openstack-nova15:13
*** iceyao has joined #openstack-nova15:14
*** crushil has quit IRC15:15
*** kevinz has joined #openstack-nova15:16
*** markus_z has quit IRC15:17
*** eharney has quit IRC15:19
*** iceyao has quit IRC15:19
*** mdrabe has quit IRC15:20
*** kfarr has joined #openstack-nova15:21
*** kevinz has quit IRC15:21
*** mdnadeem has quit IRC15:21
*** Guest86170 has quit IRC15:21
*** crushil has joined #openstack-nova15:21
*** catintheroof has joined #openstack-nova15:22
*** rmart04 has quit IRC15:22
*** Guest86170 has joined #openstack-nova15:25
*** mdrabe has joined #openstack-nova15:27
*** Jack_Iv has quit IRC15:27
*** Jack_Iv has joined #openstack-nova15:27
*** mvk has quit IRC15:28
*** scottda has joined #openstack-nova15:30
*** ijw has joined #openstack-nova15:30
*** tjones has quit IRC15:30
*** tjones has joined #openstack-nova15:31
*** felipemonteiro has quit IRC15:31
*** kaisers has joined #openstack-nova15:32
*** abalutoiu has quit IRC15:32
*** kaisers has quit IRC15:34
*** kaisers has joined #openstack-nova15:34
*** ijw has quit IRC15:35
*** eharney has joined #openstack-nova15:38
johnthetubaguyvoelzmo: the other part is making this like the delete_on_termination we have for volumes, but I don't 100% remember the details15:38
openstackgerritSylvain Bauza proposed openstack/nova master: Destroy the ReqSpec object when deleting the instance  https://review.openstack.org/39106015:39
*** pcaruana has quit IRC15:41
*** zenoway has quit IRC15:42
*** ngupta has quit IRC15:46
*** ngupta has joined #openstack-nova15:46
*** salv-orl_ has joined #openstack-nova15:49
*** rfolco has quit IRC15:50
*** jianghuaw_ has quit IRC15:50
*** fragatina has joined #openstack-nova15:51
*** salv-orlando has quit IRC15:51
edleafeTrying to create a functional test that simulates 1000 computes. Would I do this by creating a single n-cpu service and 1000 ComputeNode objects? If so, how do I add those ComputeNode objects to the service's ResourceTracker?15:52
edleafeOr am I completely lost?15:52
mriedemedleafe: did you see my reply about this to cdent's placement update in the ML?15:53
mriedemedleafe: i'm not sure a functional test makes sense for this, since it's just a report, it wouldn't actually fail15:53
mriedemedleafe: i dug out yingxin's tool from the austin summit when he was testing the filter scheduler vs the caching scheduler,15:53
mriedemit might need some tweaking, but the readme says you can run it against a single-node devstack15:53
mriedemso i'd probably start there15:53
edleafemriedem: no, didn't see your reply yet15:54
*** rfolco has joined #openstack-nova15:54
*** iceyao has joined #openstack-nova15:54
bauzasedleafe: I agree with mriedem, I'm pretty sure our infra wouldn't like to have a job faking 1000 nodes for each patch15:54
*** chyka has joined #openstack-nova15:54
mriedembauzas: ed was working on an in-tree functional test i think15:54
mriedemwhich just simulates things in the db15:54
mriedemand runs the scheduler15:54
edleafewhy wouldn't it fail? If you have inventory/allocations that don't meet the request, shouldn't it fail?15:54
mriedemedleafe: i mean the test doesn't really fail15:55
mriedemit's a perf test which is used to compare results15:55
mriedemso with an actual TestCase, what do you compare it to for the benchmark?15:55
mriedemthat's all i mean15:55
edleafeAnd this wasn't going in-tree - it was more of a tool to test our assumptions15:55
mriedemedleafe: ok, that tool already exists15:55
bauzasmriedem: not sure I understand the reasoning behind running 1000 nodes15:55
mriedemwe should re-use it15:55
edleafeit does?15:55
bauzasand we already have all the infra for running functional tests15:55
*** vishwana_ has quit IRC15:56
bauzasyou can just castascall and run all your services with the fake driver15:56
bauzasplus all the fixtures15:56
edleafebauzas: the question was whether claiming in scheduler or conductor was better when hitting the race situation15:56
*** gfhellma has joined #openstack-nova15:57
bauzasedleafe: so, that's not needing a functional test - it's different15:57
bauzaswhat you need is to run a testbed for verifying some things15:57
*** Kevin_Zheng has quit IRC15:57
edleafebauzas: ok, functional "tool"15:57
bauzasyou can write that using the existing fixtures15:57
*** damien_r has quit IRC15:57
edleafemriedem: which tool are you referring to?15:58
bauzasbut I think it should rather be something for the implementation :)15:58
mriedemedleafe:15:58
mriedemhttp://lists.openstack.org/pipermail/openstack-dev/2017-April/115553.html15:58
bauzasFWIW, I think discussing about whether the claim post should be in the conductor or the scheduler is an implementation detail that needs verification during the implementation phase15:58
bauzasI was actually planning to do so15:58
*** Jack_Iv has quit IRC15:59
mriedemedleafe: https://github.com/cyx1231st/nova-scheduler-bench15:59
*** iceyao has quit IRC15:59
mriedembauzas: that's why this came up15:59
bauzashonestly, I don't want to defer the spec acceptance by that15:59
edleafemriedem: thanks - I'll dig into this16:00
mriedemi.e. is it better to retry in the scheduler where we already have the hosts, or conductor which requires the full retry16:00
mriedembauzas: i don't either16:00
bauzashaving the scheduler or the conductor calling the placement seems an implementation detail16:00
edleafebauzas: you could simply add "to be determined"16:00
bauzasedleafe: I was *on* the spec given I made a promise to mriedem :p16:00
mriedembauzas: i'd like to say we're going to start with retry in scheduler, but mention an alternative16:00
bauzasmriedem: jinxed16:00
mriedemand say both can be tested16:00
*** Jack_Iv has joined #openstack-nova16:01
dansmithmriedem: that pushes the claim to placement into the scheduler too16:01
mriedemdansmith: i know16:01
dansmithhmm.16:01
mriedemthat's where we have the list of filtered  and weighed hosts16:01
dansmithI know16:01
mriedemso if we have to retry, it's faster16:01
mriedemwell, theoretically it's faster16:02
dansmithor it might be much worse, depending on how you race16:02
dansmithwe could also, you know, return more information from that scheduler interface16:02
mriedemsure, if host[1] and host[2] in the list are now used up too16:02
dansmithlike "here are the top 5, weighed in order"16:02
mriedemdansmith: i thought about that yesterday too16:02
mriedemselect_destinations could just return the hosts16:02
*** ngupta has quit IRC16:02
dansmith...yeah16:02
mriedemi'd return whatever CONF.max_attempts is16:03
bauzasthere are 2 implementation possibilites16:03
dansmithit already returns multiples now if num_instances is >1, so just return N plus some.. yeah16:03
bauzaseither we put POST in consume_from_request()16:03
mriedemjaypipes: cdent: bauzas: https://bugs.launchpad.net/nova/+bug/168385816:03
openstackLaunchpad bug 1683858 in OpenStack Compute (nova) "Allocation records do not contain overhead information" [High,Triaged]16:03
bauzasor, we do POST right after scheduler returns a destination to conductor16:03
*** ngupta has joined #openstack-nova16:04
mriedembauzas: the post isn't the problem, it's where to retry16:04
jaypipesmriedem: thx16:04
bauzaseither way, like I discussed with mriedem, we need to DELETE allocations in the conductor on a reschedule/move operation16:04
bauzasmriedem: like I said to you, the scheduler doesn't know whether it's a move or a single boot16:04
bauzasfor it, it just answers a specific question which is "which host(s) matches my request"16:05
bauzas*why* we ask the scheduler this question is totally unrelated to it16:05
*** voelzmo has quit IRC16:05
*** egonzalez has quit IRC16:05
edleafebauzas: either way, the resources on the selected host will have to be claimed16:05
bauzasedleafe: in the PS I'm writing, I'm decoupling the DELETE and the POST16:06
*** ngupta has quit IRC16:06
*** voelzmo has joined #openstack-nova16:06
*** sridharg has quit IRC16:06
*** ngupta has joined #openstack-nova16:06
bauzasedleafe: in the conductor, I'm planning to GET allocations for that instance and DELETE those if existing, before calling scheduler which would POST the new allocations for that instance16:06
openstackgerritJon Bernard proposed openstack/nova master: Add tempest-dsvm-ceph-rc  https://review.openstack.org/45629216:07
*** Apoorva has joined #openstack-nova16:07
*** Apoorva has quit IRC16:07
*** Apoorva has joined #openstack-nova16:08
efriedsfinucan Got a sec to talk through https://review.openstack.org/#/c/455710/8/nova/api/openstack/placement/handler.py@184 ? (andymccr cdent)16:08
*** gyee has joined #openstack-nova16:09
*** nic has joined #openstack-nova16:09
sfinucanefried: Sure16:09
* cdent listens16:09
efriedsfinucan First, assertion that we don't need .get(..., '')16:09
efriedWhyzat?  Is something upstack guaranteeing that var will be present (even if empty) in the env?16:09
*** voelzmo has quit IRC16:10
sfinucanefried: '.get' will return 'None' even if the key isn't a dictionary16:10
sfinucanwhich is different from the dict[key] notation16:11
sfinucan*isn't in a given dictionary16:11
efriedmm, fair16:11
cdentthis has been through enough iterations I'm not sure if we haven't lost the original point16:12
cdentor maybe points16:12
andymccrsfinucan: so if i understand your point correctly, the subsequent .get()'s after line 183 are not required in that format since we are certain by now that the var does exist.16:13
andymccralthough the last one is probably required still since that's for CONTENT_TYPE rather than CONTENT_LENGTH?16:13
efriedI wasn't a fan of leaving the int() to raise TypeError/ValueError, but that was the original behavior that supposedly wasn't wanting to be changed.16:13
efriedandymccr Right, but leave out the  , ''16:13
cdentefried: no we don't want that. we don't want a lose exception to raise16:13
cdentloose16:13
andymccrefried: because it would return None anyway- ok cool i understand16:14
efriedcdent Yeah, just thought we might want it to be a better exception16:14
*** salv-orl_ has quit IRC16:14
efriedcdent Like HTTPBadRequest16:14
andymccri can add in a try/raise if needed16:14
cdentandymccr: my advice would be to start from a test that demonstrates the bug you're experiencing16:15
cdentmake that, make it fail, then fix it16:15
cdentyou can do that by faking an environ that you pass to the PlacementHandler class16:15
cdent(as a callable)16:15
*** lucasagomes is now known as lucas-afk16:15
efriedYeah, mahbad for suggesting all the  , '' / , 0  stuff.  There's some other builtin that raises if you don't use that second var (can't remember which, now) that I was confusing with dict.get().16:16
andymccrcdent: yeah my plan is to cover a few test cases there. i think it should be doable i just need to carve out some time. but to confirm when i propose the next patch set it would be better to have a try block around the int()16:17
cdentI can't remember :)16:17
efriedandymccr IMO, yes; cdent may not agree.16:18
*** sudipto_ has joined #openstack-nova16:18
*** sudipto has joined #openstack-nova16:18
cdentgo for it16:18
andymccrefried: it makes sense to me so i'll do it and can always revise :)16:18
efriedBasically, we don't want a CONTENT_LENGTH that's not an int.16:18
cdenti think once you get tests in place, the solutions will be pretty clear16:18
andymccryeah agreed16:18
*** marst_ has joined #openstack-nova16:19
efriedThanks guys.  Felt like we were going around in circles a bit trying to have this conversation via gerrit.16:19
andymccrhaha yeah probably - and thanks for the pointers/help on that one.16:20
*** marst has quit IRC16:20
openstackgerritdane-fichter proposed openstack/nova master: Add trusted certificates to InstanceExtras  https://review.openstack.org/45771116:21
efriedandymccr cdent sfinucan Aha - it was getattr() I was confusing with.  If you don't provide the default there, it raises.  <facepalm>16:21
sfinucanefried: Yup, I only realized last week that you could even use a default. Had been using a 1-2 hasattr/getattr combo up to that point16:22
*** swebster_ has joined #openstack-nova16:23
*** swebster has quit IRC16:23
cdentefried: thanks for that linking16:27
efriedyahyoubetcha16:27
*** ijw has joined #openstack-nova16:32
openstackgerritStephen Finucane proposed openstack/nova master: conf: Add three new '[libvirt] live_migration_*' options  https://review.openstack.org/45657116:33
openstackgerritStephen Finucane proposed openstack/nova master: conf: Gather 'live_migration_scheme', 'live_migration_inbound_addr'  https://review.openstack.org/45657216:33
openstackgerritStephen Finucane proposed openstack/nova master: conf: Convert 'live_migration_inbound_addr' to HostAddressOpt  https://review.openstack.org/45657316:33
openstackgerritStephen Finucane proposed openstack/nova master: conf: Set default for live_migration_scheme  https://review.openstack.org/45771616:33
johnthetubaguymriedem: I have some questions on https://review.openstack.org/#/c/452577 I just took a look16:34
johnthetubaguymriedem: I am trying to workout why the existing logic doesn't work correctly16:34
*** moshele has joined #openstack-nova16:36
*** ijw has quit IRC16:37
*** moshele has quit IRC16:40
*** dave-mccowan has quit IRC16:41
*** gjayavelu has joined #openstack-nova16:42
*** jaosorior has quit IRC16:43
*** dave-mccowan has joined #openstack-nova16:45
*** baoli has quit IRC16:45
efriedmriedem jaypipes Clarification on https://review.openstack.org/#/c/454983/ (Service catalog for endpoints): Do we *want* to include config options like [cinder]catalog_info for all the services, or just use a hardcoded service_type?16:46
*** karimb has quit IRC16:47
jaypipesefried: I'd prefer to use a hard-coded service type, from the service-types-authority: https://github.com/openstack/service-types-authority/16:48
jaypipesefried: unfortunately cinder isn't in there :(16:48
efriedjaypipes Okay, I dig the idea of having fewer conf settings.  But edmondsw also had concerns about hardcoding the endpoint_type.16:48
jaypipesefried: but cinder is proposed for "block-storage": https://review.openstack.org/#/c/436178/16:49
*** litao has quit IRC16:49
jaypipesefried: for Cinder, specifically, we'll need to have a list of hard-coded service types and try them in order.16:49
jaypipesefried: for instance, try "block-storage", then "volumev2", then "volume", etc16:50
jaypipesefried: because Cinder is the odd man out of all this.16:50
*** harlowja_ has joined #openstack-nova16:50
*** harlowja has quit IRC16:52
mriedemefried: the whole point is we don't want catalog_info16:52
mriedemso we're going to deprecate that once we start using ksa16:52
jaypipesright16:52
mriedemand we just have a service_type and interface option16:52
jaypipesbingo16:52
mriedemso service_type=cinderv3, interface=public16:52
*** dmk0202 has quit IRC16:52
mriedemor whatever16:52
jaypipesand frankly, even the interface is questionable... but meh. :)16:52
mriedeminterface defaults to None in nova.conf, which defaults to public in ksa16:52
mriedemsure16:52
*** ssurana has joined #openstack-nova16:52
mriedemi only mention interface b/c of the one we added for placement for andymccr16:52
jaypipesya16:53
mriedemjohnthetubaguy: ok will look after the notifications meeting16:53
mriedemwhere i'm sure we'll talk about loading instance.tags by default16:53
mriedemso dansmith might want to be there16:53
dansmith"want"16:53
mriedem"so i want dansmith to be there"16:54
mriedembetter?16:54
dansmithyes16:54
mriedemsorry i'm midwestern16:54
mriedemand therefore passive aggressive16:54
openstackgerritSylvain Bauza proposed openstack/nova-specs master: Claims in the scheduler  https://review.openstack.org/43742416:54
bauzasmriedem: dansmith: edleafe: cdent: jaypipes: BOOOM ^16:55
bauzasthat said, \o16:55
jaypipesbauzas: k, thx. will re-review shortly.16:55
mordredTIL novaclient validates payloads more in python3 than in python216:55
*** felipemonteiro has joined #openstack-nova16:56
*** derekh has quit IRC16:56
sdaguemordred: interesting...16:56
sdaguemordred: define more?16:56
*** amotoki has quit IRC16:57
mordredsdague: http://logs.openstack.org/48/457548/2/check/gate-shade-python35/0b68957/testr_results.html.gz - the test failure there only fails on python3 - in python3 it passed. the error is that I was returning the wrong top-level key in my response16:57
mordred(was returning security_groups and not security_group)16:58
sdagueweird16:59
*** baoli has joined #openstack-nova17:00
*** ralonsoh has quit IRC17:01
*** baoli has quit IRC17:01
*** baoli has joined #openstack-nova17:02
mordredyah17:03
mordredI mean, it's neat that novaclient in python3 double-checked that for me - it caught a bug :)17:03
sdagueyeh, I wonder what actually is different there17:03
edmondswmriedem, are you saying we would still have service_type and interface options in conf?17:05
mriedemedmondsw: yes17:05
mriedembecause we need to know if you're going to use cinderv2 or cinderv317:05
mriedemor cinderv417:05
edmondswmriedem, ok, good... I would even be fine with (at least eventually) hardcoding service_type... but not interface17:06
mriedemdetails are in the spec17:06
edmondswmriedem well that's the thing... I read the spec and this was far from clear17:06
edmondswunfortunately I read it after it was merged17:06
mordredsdague: I can't see anything different in the code17:06
*** cdent has quit IRC17:07
*** efoley has quit IRC17:07
edmondswefried, so see mriedem's reply above... service_type and interface would still be in conf17:07
efriededmondsw Hm, see jaypipes from 20min ago17:08
*** yamahata has joined #openstack-nova17:09
edmondswefried he seemed to agree at 12:5217:10
jaypipesedmondsw: gimme 10 minutes and I'll disagree with myself.17:10
edmondsw:)17:10
*** Jack_Iv has quit IRC17:10
efriededmondsw Oh, I misunderstood, thought that was params to the function, not conf options.17:10
edmondswjaypipes I like a man who can change his mind when it makes sense17:11
jaypipesedmondsw: I totally disagree.17:11
edmondswlol17:11
jaypipes:P17:11
*** Jack_Iv has joined #openstack-nova17:11
edmondsw"interface" is what I was calling "endpoint_type" in our conversation because that's what the spec had called it17:13
edmondswefried ^17:13
*** ociuhandu has joined #openstack-nova17:13
efriededmondsw Yeah, I've picked up on that dual naming.17:13
*** fragatina has quit IRC17:14
efriededmondsw It's either-or all over the place.17:14
*** ltomasbo is now known as ltomasbo|away17:15
edmondswefried keystone calls it "interface"... at least in v3, I don't remember in v217:16
*** ociuhandu has quit IRC17:16
*** mdrabe has quit IRC17:17
*** mdrabe has joined #openstack-nova17:18
mordredyah. interface is the 'correct' term, endpoint_type is the legacy type17:18
mordredfwiw, I would vote for not having service_type in the conf myself, but that's just me perhaps17:18
*** kaisers has quit IRC17:19
efriedmordred The concern was that we would then have to try some number of service types (in some possibly-arbitrary order) before we find the right one.17:19
mordredmriedem: I do not think you need to have service_type so that you know cinderv2/cinderv3 - since that's in the cinder discovery doc17:19
mordredefried: yes. you may have to do that - but that is fairly cheap. whereas continuing to allow configuration of service_type perpetuates the idea that it's ok for people to set them to something other than the one thing they should be set to17:20
mordredbut, as I said, i'm the extremist view on all of this17:20
mriedemmordred: but i thought the service type in the catalog was cinder/cinderv2/cinderv3?17:20
mriedemand cinder == v117:21
mordredmriedem: yes. well, this is a tragedy of history that is hopefully soon rectified17:21
mordredsince it causes baby bunnies to weep regularly17:21
*** Jack_Iv has quit IRC17:21
mordred(and it's volume, volumev2 and volumev3)17:21
mriedemoh right17:21
mriedemwe have that hard-coded in the nova request context code too \o/17:22
mordredbut you can _easily_ try all three of those from the catalog, since it's a local dict lookup17:22
mordredand, in fact, I even already have the logic for that written up :)17:22
*** Jack_Iv has joined #openstack-nova17:22
*** Jack_Iv has quit IRC17:22
*** jpena is now known as jpena|off17:24
efriedmordred mriedem Where can I get the exhaustive list of service_type values?17:25
*** nkorabli has quit IRC17:25
*** nkorabli has joined #openstack-nova17:25
mordredefried: https://review.openstack.org/#/q/project:openstack/service-types-authority is the beginning of collecting them17:26
*** gfhellma_ has joined #openstack-nova17:26
mordredefried: there is also an unofficial list here: http://git.openstack.org/cgit/openstack/os-client-config/tree/os_client_config/constructors.json17:26
mordredalthough hopefully we can make that go away and rely on s-t-a once it coalesces17:27
*** gszasz has quit IRC17:27
*** baoli has quit IRC17:27
* mordred is so looking forward to adding block-storage to the list of things we try for volume things17:27
*** baoli has joined #openstack-nova17:28
efriedmordred Will service-types-authority be complete and definitive in pike (in time to be used for this impl)?17:28
mordreddoubful - can you point me to the spec you're talking about?17:28
efriedmordred https://review.openstack.org/#/c/454983/7/specs/pike/approved/use-service-catalog-for-endpoints.rst17:29
mordredthanks!17:29
*** gfhellma has quit IRC17:29
efriedThank _you_.  I'm very much struggling just to understand the context here.  Any guidance is much appreciated.17:29
*** ijw has joined #openstack-nova17:33
*** burgerk has quit IRC17:38
*** ijw has quit IRC17:38
efriedjaypipes mriedem Suggestions for where the new get_service_url() method should live?17:39
*** mlavalle has quit IRC17:39
jaypipesefried: nova/utils.py?17:39
efriedight17:39
efriedjaypipes Not service.py, service_auth.py, or context.py, then.17:40
jaypipesefried: I think nova/utils.py is a fine home. we can always move it in the future if need be.17:41
efriedrgr17:41
mriedemyeah nova.utils is fine17:43
*** ociuhandu has joined #openstack-nova17:46
*** fragatina has joined #openstack-nova17:47
*** fragatina has quit IRC17:47
*** fragatina has joined #openstack-nova17:48
efriedconcern: circular imports...17:49
*** ociuhandu has quit IRC17:50
openstackgerritMonty Taylor proposed openstack/nova-specs master: Fix old terminology  https://review.openstack.org/45774617:51
openstackgerritMonty Taylor proposed openstack/nova-specs master: Implement use-service-catalog-for-endpoints differently  https://review.openstack.org/45774717:51
mordredjaypipes, efried, mriedem: ^^ there is me arguing17:51
*** fragatina has quit IRC17:53
*** ociuhandu has joined #openstack-nova17:53
mriedemmordred: publicURL is in the config defaults right now https://github.com/openstack/nova/blob/master/nova/conf/cinder.py#L2617:53
mriedemthat's why it was in the spec17:53
mordredmriedem: I totally understand. but publicURL is a keystonev2 holdover17:54
mriedemyeah that's fine, we could change the default config option17:54
mriedemwe already changed cinderv2 to cinderv3 in that option in pike17:54
mriedemmordred: you could propose the change and get your ATC badge17:54
mordredah - so I totally misunderstood taht the config option already existed17:55
mriedemright17:55
*** ociuhandu has quit IRC17:55
mordredso - my sugestion of 2 new options still stands - but if this is already a thing I guess there is no point in doing a double migration17:55
mriedemjaypipes: efried: so i guess we lost something in one of the patch sets on that spec where it listed the options we'd provide as overrides, like service_type and interface17:56
mriedemwhich is maybe why edmondsw was confused17:56
*** fragatina has joined #openstack-nova17:57
*** ociuhandu has joined #openstack-nova17:57
mriedemedmondsw: mordred: see https://review.openstack.org/#/c/454983/4..7/specs/pike/approved/use-service-catalog-for-endpoints.rst@a7617:58
mriedemps4 on the original spec called some of this out17:58
*** ekhugen has quit IRC17:58
*** patriciadomin has quit IRC17:58
efriedSo if service_type is provided, use it.  If interface is provided, use it.  If not provided, cycle through them (if neither provided, does it matter which is inner and which is outer loop?)17:59
macszbug team meeting in 2 minutes @ openstack-meeting-417:59
efriedIs the service catalog guarateed to present at most one hit for a given service?17:59
*** baoli has quit IRC17:59
mriedemefried: i've been in other meetings so didn't follow any of the discussion about iterating things18:00
efriedSorry, I mean I guess e.g. glance can provide multiple endpoints - but only for one service_type/interface combo?18:00
efriedmriedem Yeah, so jaypipes (I think) suggested having a hardcoded list of service_type values and trying them in (what?) order.18:00
*** nicolasbock has quit IRC18:01
efried...or is service_type required (defaulting to something "sensible" for each service)?18:01
mordredstarting with "nicest" default - that is, whatever is in service-type-authority - and then falling back to other items in preferred order18:02
*** baoli has joined #openstack-nova18:02
jaypipesmordred: right, xactly what I think is appropriate.y18:02
efriedAnd for further fun, continue supporting existing conf options, with deprecation warnings, through pike.18:03
mordredbtw - I'm writing a quick spec for "just use os-client-config" - which I started hacking on but it's entirely possible that none of you know that, since I didn't write a spec18:03
efriedmordred Is there an example somewhere of os-client-config being used for something like this?18:04
mriedemefried: novaclient functional tests18:04
mriedemhttps://github.com/openstack/python-novaclient/blob/master/novaclient/tests/functional/base.py#L15718:04
*** Jack_Iv has joined #openstack-nova18:07
*** sudipto has quit IRC18:07
*** sudipto_ has quit IRC18:07
mriedemso what is the list of service types for cinder?18:07
mriedemand this is a ListOpt or what?18:07
*** gfhellma_ has quit IRC18:07
mriedem[cinder]service_types=volumev3,volumev2,cinderv3,cinderv2?18:07
*** sambetts is now known as sambetts|afk18:08
*** patriciadomin has joined #openstack-nova18:09
mriedemmordred: "ditch the concept of a single value that is a colon separated tuple, since that form is not used to indicate an OpenStack service pretty much anywhere else" is adorable18:10
mriedemmordred: cinder copied that from nova, and manila copied that from cinder18:10
jaypipesmriedem: in case you were wondering, I'm working on patches that add get_inventory() implementation for all the non-Ironic virt drivers.18:10
*** faizy has quit IRC18:11
mriedemjaypipes: ok18:12
mriedemi'm working on reviewing already approved specs18:12
mriedemso we can rewrite them18:12
jaypipeslol18:13
*** bkopilov has quit IRC18:22
*** tesseract has quit IRC18:22
*** felipemonteiro has quit IRC18:23
*** felipemonteiro has joined #openstack-nova18:25
*** nicolasbock has joined #openstack-nova18:27
mordredmriedem: heh. I meant in the world of people consuming openstack services18:28
openstackgerritMonty Taylor proposed openstack/nova-specs master: Add spec for using os-client-config for service clients  https://review.openstack.org/45776018:29
*** nkorabli has quit IRC18:29
*** ngupta_ has joined #openstack-nova18:31
openstackgerritMonty Taylor proposed openstack/nova-specs master: Fix old terminology  https://review.openstack.org/45774618:32
*** felipemonteiro has quit IRC18:34
*** ngupta has quit IRC18:35
*** ijw has joined #openstack-nova18:35
*** nkorabli has joined #openstack-nova18:37
*** ijw has quit IRC18:41
*** abalutoiu_ has joined #openstack-nova18:42
*** mnestratov has quit IRC18:43
openstackgerritMatt Riedemann proposed openstack/nova master: Fix docstring in _validate_requested_port_ids  https://review.openstack.org/45776718:44
*** Sukhdev has joined #openstack-nova18:46
*** nkorabli has quit IRC18:46
*** ngupta has joined #openstack-nova18:47
*** adisky_ has quit IRC18:49
*** ngupta_ has quit IRC18:51
*** mlavalle has joined #openstack-nova18:52
*** ekhugen has joined #openstack-nova18:55
openstackgerritDan Smith proposed openstack/nova master: Make server groups api aware of multiple cells for membership  https://review.openstack.org/45733818:57
openstackgerritDan Smith proposed openstack/nova master: Sort CellMappingList.get_all() for safety  https://review.openstack.org/44317418:57
openstackgerritDan Smith proposed openstack/nova master: Clean up ClientRouter debt  https://review.openstack.org/44448718:57
openstackgerritDan Smith proposed openstack/nova master: Add workaround to disable group policy check upcall  https://review.openstack.org/44273618:57
*** cdent has joined #openstack-nova18:58
*** gfhellma has joined #openstack-nova19:00
*** JayF has left #openstack-nova19:04
*** dave-mccowan has quit IRC19:06
mriedemjohnthetubaguy: i went through https://review.openstack.org/#/c/452577/ and short answer is i don't know why the existing code isn't working :(19:06
mriedemunless the info cache is getting concurrent updates and some stale data overwrites our update with the newly attached port19:07
*** dtp has joined #openstack-nova19:08
*** dtp has quit IRC19:14
*** jamesdenton has quit IRC19:25
*** jamesdenton has joined #openstack-nova19:29
*** dave-mccowan has joined #openstack-nova19:32
*** mdrabe has quit IRC19:33
*** mdrabe has joined #openstack-nova19:34
*** jamesdenton has quit IRC19:35
openstackgerritJay Pipes proposed openstack/nova master: placement: implement get_inventory() for libvirt  https://review.openstack.org/45778219:36
*** mdrabe has quit IRC19:36
*** mdrabe has joined #openstack-nova19:37
*** mdrabe has quit IRC19:38
*** mdrabe has joined #openstack-nova19:40
*** awaugama has quit IRC19:40
openstackgerritMonty Taylor proposed openstack/nova-specs master: Add spec for using os-client-config for service clients  https://review.openstack.org/45776019:41
*** mdrabe has quit IRC19:46
*** felipemonteiro has joined #openstack-nova19:47
*** slaweq_ has joined #openstack-nova19:47
*** jdurgin has quit IRC19:47
*** Jack_Iv has quit IRC19:47
*** mdrabe has joined #openstack-nova19:48
*** slaweq_ has quit IRC19:48
*** Jack_Iv has joined #openstack-nova19:49
openstackgerritJon Bernard proposed openstack/nova master: Add tempest-dsvm-ceph-rc  https://review.openstack.org/45629219:49
*** iceyao has joined #openstack-nova19:50
*** Jack_Iv has quit IRC19:51
openstackgerritJon Bernard proposed openstack/nova master: Add tempest-dsvm-ceph-rc  https://review.openstack.org/45629219:53
*** david-lyle has joined #openstack-nova19:53
*** iceyao has quit IRC19:54
*** Laszlo_ has joined #openstack-nova19:55
*** Jack_Iv has joined #openstack-nova19:55
Laszlo_hello19:55
Laszlo_I've run into an interesting situation with Newton:19:56
Laszlo_I have a user user1 in project119:56
Laszlo_the user is creating a VM19:56
Laszlo_then the admin user in the admin project is creating a volume19:56
Laszlo_next the admin user is attaching the volume using the ID of the VM (server) created by the user and the ID of the voulme created by admin19:57
Laszlo_all fine, the volume is visible inside the server.19:58
mriedemuser tries to detach the volume or delete the instance and it blows up because the user doesn't have access to GET the volume19:59
mriedemby design19:59
Laszlo_next the user is deleting the server (actually is deleting the entire stack that has created the server)19:59
Laszlo_openstack stack delete lab219:59
Laszlo_no errors so far20:00
*** Jack_Iv has quit IRC20:00
*** jdurgin has joined #openstack-nova20:00
Laszlo_but when I'm looking at the volume created by the admin user I can still see it as being attached ....20:00
mriedembecause nova failed to detach it20:00
mriedembecause the instance user doesn't have access to the volume20:00
Laszlo_I see ...20:01
mriedemfails here https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L226720:01
Laszlo_can I run the detach as admin? (now the VM is already gone .... )20:01
mriedemyou should see one of those warnings in the logs20:01
mriedemyou'd have to detach the volume as admin before deleting the server20:01
mriedemyou can't detach it after the server is gone20:02
mriedemotherwise you need to force a reset of the volume state on the cinder side20:02
Laszlo_is there a way out from this situation?20:02
mriedemLaszlo_: i think you have to use the os-reset_status API on the cinder side in that case20:03
*** Apoorva_ has joined #openstack-nova20:03
*** Jack_Iv has joined #openstack-nova20:03
mriedemhttps://developer.openstack.org/api-ref/block-storage/v2/index.html#reset-volume-statuses20:04
Laszlo_mriedem: OK. I will chack it. I have not used this before20:04
mriedemit's really a backdoor hack20:04
mriedemwhen something goes wrong20:04
mriedemyour root problem is that you have the admin creating and attaching a volume to a server it does not own20:04
mriedemso when the server is deleted, the owner of the server does not have access to detach the volume20:05
mriedemb/c it can't get access to the volume20:05
mriedemsince the admin owns it20:05
mriedemso either, use a single tenant, or make sure your tooling has the admin detach the volume before the server is deleted20:05
*** eharney has quit IRC20:06
*** Apoorva has quit IRC20:06
Laszlo_mriedem: I understood the problem. currently the issue is not big because I was just playing with a newton lab install20:07
*** mnestratov has joined #openstack-nova20:07
mriedemwhew20:08
Laszlo_so it's a good chance to learn about how to solve the issue if I will have it in real life situation ... :)20:08
*** dtp has joined #openstack-nova20:13
*** Jack_Iv has quit IRC20:14
*** Jack_Iv has joined #openstack-nova20:14
*** mvk has joined #openstack-nova20:15
*** smatzek has quit IRC20:17
*** eharney has joined #openstack-nova20:21
openstackgerritVladik Romanovsky proposed openstack/nova master: Add spice-native type  https://review.openstack.org/45494020:21
*** ildikov is now known as hypothermic_cat20:22
*** ijw has joined #openstack-nova20:24
*** dimtruck is now known as zz_dimtruck20:27
smcginnisLaszlo_: In case you don't want to make API calls directly, here's the client info: https://docs.openstack.org/cli-reference/cinder.html20:29
*** ijw has quit IRC20:29
*** xyang1 has quit IRC20:30
*** xyang1 has joined #openstack-nova20:31
*** iceyao has joined #openstack-nova20:31
Laszlo_smcginnis: thank you! that makes our life much easyer ... :)20:32
*** Apoorva_ has quit IRC20:32
smcginnis;)20:32
*** openstackgerrit has quit IRC20:33
Laszlo_so the right command would be: cinder reset-state --state available --attach-status detached  right?20:33
*** Apoorva has joined #openstack-nova20:33
smcginnisLaszlo_: Not having done it lately and not having access to tests right now... yes, I believe so. :)20:33
Laszlo_one sec .. I'll tell you ... :)20:34
*** gfhellma_ has joined #openstack-nova20:35
Laszlo_it worked! of course I had to specify the vol_id also ...20:35
Laszlo_thank you!20:35
*** pchavva has quit IRC20:35
*** iceyao has quit IRC20:36
*** ngupta has quit IRC20:36
*** gfhellma has quit IRC20:36
*** slaweq_ has joined #openstack-nova20:37
*** Jack_Iv has quit IRC20:38
*** slaweq_ has quit IRC20:39
*** slaweq_ has joined #openstack-nova20:39
*** gjayavelu has quit IRC20:42
*** cleong has quit IRC20:43
mriedemgmann: did you ever start this? https://blueprints.launchpad.net/nova/+spec/nova-microversion-functional-tests20:44
*** slaweq_ has quit IRC20:44
*** slaweq_ has joined #openstack-nova20:44
*** jdurgin has quit IRC20:45
*** marst_ has quit IRC20:45
*** salv-orlando has joined #openstack-nova20:45
*** sean-k-mooney has quit IRC20:46
*** gfhellma__ has joined #openstack-nova20:46
*** gfhellma_ has quit IRC20:47
*** vladikr has quit IRC20:48
*** zz_dimtruck is now known as dimtruck20:48
*** david-lyle has quit IRC20:49
*** slaweq_ has quit IRC20:50
*** slaweq_ has joined #openstack-nova20:51
mriedemdansmith: jaypipes: so i think i'm going to push a change to deprecate the TypeAffinityFilter, there wasn't much reply in the mailing list on it, but as noted there it's broken by design if you ever change your flavors20:58
mriedemhttp://lists.openstack.org/pipermail/openstack-operators/2017-April/013131.html20:58
*** jdurgin has joined #openstack-nova21:00
jaypipesmriedem: cool with me, but then again, I'm pro-removal-of-most-things. ;)21:01
*** sdague has quit IRC21:04
dansmithmriedem: yes, me as well21:05
*** slaweq has quit IRC21:05
*** slaweq_ is now known as slaweq21:07
*** cdent has quit IRC21:07
*** david-lyle has joined #openstack-nova21:10
*** slaweq has quit IRC21:10
*** slaweq has joined #openstack-nova21:10
*** edmondsw has quit IRC21:11
*** dmk0202 has joined #openstack-nova21:11
*** thorst has quit IRC21:11
*** edmondsw has joined #openstack-nova21:11
*** Laszlo_ has left #openstack-nova21:12
*** rfolco has quit IRC21:12
*** rfolco has joined #openstack-nova21:13
*** rfolco has quit IRC21:13
*** iceyao has joined #openstack-nova21:14
*** Sukhdev has quit IRC21:15
*** xinliang has quit IRC21:16
*** edmondsw has quit IRC21:16
*** Sukhdev has joined #openstack-nova21:17
*** marst_ has joined #openstack-nova21:18
*** gjayavelu has joined #openstack-nova21:18
*** jamesdenton has joined #openstack-nova21:19
*** iceyao has quit IRC21:19
*** lyan has quit IRC21:19
melwittanyone else seen random failures of nova.tests.unit.virt.ironic.test_driver.IronicDriverConsoleTestCase.test__get_node_console_with_reset_wait_timeout locally?21:22
dansmithnot locally, but have seen it twice in the last few hours in infra21:23
*** jamesdenton has quit IRC21:23
melwittsomething is afoot, it's not just me21:24
* dansmith scowls21:24
melwitt:)21:24
mriedemjaypipes: dansmith: btw, why do we still have ram/disk filters in enabled_filters?21:28
mriedemplacement replaces those now21:28
mriedemyeah?21:28
dansmithyeah, might should remove them21:28
dansmithI hear jaypipes loves ramfilter though, so maybe he wants to keep it21:28
* dansmith runs21:28
mriedemEXCEPT21:29
mriedemramfilter checks host_state.free_ram_mb21:29
mriedemwhich has that overhead thing in it from the virt drivers21:29
mriedemand placement doesn't21:29
*** xinliang has joined #openstack-nova21:29
*** eharney has quit IRC21:30
mriedemso maybe we can't remove it until that bug is fixed21:30
dansmithweren't we going to stop writing the RT data in pike though?21:30
mriedemwell, remove it from default21:30
mriedemwriting what rt data?21:31
dansmithall the existing stuff we're duplicating in placement now21:32
mriedemmelwitt: https://github.com/openstack/nova/commit/213f7120c483a37317091b7478dfb99495619ce4 ?21:32
mriedemfor that ironic thing21:32
*** thorst has joined #openstack-nova21:32
mriedemdansmith: oh writing to the compute nodes table?21:32
dansmithyeah, all the stats we compile in the RT from the instances, available resources, etc21:33
mriedemi don't remember that specifically21:33
mriedemfor pike21:33
mriedemi remember deprecating the ram/disk/cpu filters21:33
mriedemand sylvain had the nova-status thing for it kind of21:33
dansmithbecause right now we're keeping track of the data twice, which we needed for the upgrade, but at pike we don't,21:33
dansmithunless we're going to keep it for the ramfilter, but that would suck21:33
mriedemhttps://review.openstack.org/#/c/427200/21:34
mriedemyeah this was the thing where the filters are enabled (which ram and disk are by default), and they had allocation ratios set21:34
mriedembecause you didn't set reserved=9999 on your provider21:35
mriedemanyway, seems we should take those out of the default enabled filters21:36
mriedembut probably need to fix that overhead bug first21:36
*** thorst has quit IRC21:37
*** Apoorva_ has joined #openstack-nova21:38
*** esberglu has quit IRC21:38
*** stvnoyes has quit IRC21:40
*** ijw has joined #openstack-nova21:40
*** ngupta has joined #openstack-nova21:40
*** crushil has quit IRC21:41
*** Apoorva has quit IRC21:42
*** baoli has quit IRC21:43
*** tbachman has quit IRC21:45
*** Sukhdev has quit IRC21:47
*** Sukhdev has joined #openstack-nova21:48
*** salv-orl_ has joined #openstack-nova21:48
*** tbachman has joined #openstack-nova21:49
*** gouthamr has quit IRC21:50
*** lyan has joined #openstack-nova21:50
*** salv-orlando has quit IRC21:50
*** gfhellma__ has quit IRC21:51
*** mnestratov has quit IRC21:53
*** thorst has joined #openstack-nova21:53
*** MasterOfBugs has joined #openstack-nova21:55
*** david-lyle has quit IRC21:55
*** iceyao has joined #openstack-nova21:56
*** gfhellma has joined #openstack-nova21:57
*** thorst has quit IRC21:58
*** openstackgerrit has joined #openstack-nova21:58
openstackgerritSteven Webster proposed openstack/nova master: Fix mitaka online migration for PCI devices  https://review.openstack.org/45639721:58
openstackgerritSteven Webster proposed openstack/nova master: Fix port update exception when unshelving an instance with PCI devices  https://review.openstack.org/45393821:58
*** dmk0202 has quit IRC21:59
*** iceyao has quit IRC22:00
*** marst_ has quit IRC22:00
*** gfhellma has quit IRC22:01
*** marst_ has joined #openstack-nova22:01
*** catintheroof has quit IRC22:01
*** mdrabe has quit IRC22:03
*** abalutoiu_ has quit IRC22:04
*** abalutoiu_ has joined #openstack-nova22:04
*** fragatin_ has joined #openstack-nova22:05
*** marst_ has quit IRC22:05
*** fragatina has quit IRC22:08
*** ianw_pto is now known as ianw22:12
*** amotoki has joined #openstack-nova22:13
*** xyang1 has quit IRC22:14
openstackgerritMatt Riedemann proposed openstack/nova master: Deprecate TypeAffinityFilter  https://review.openstack.org/45781222:17
*** Sukhdev has quit IRC22:17
*** ijw has quit IRC22:21
mriedemnova.tests.unit.virt.ironic.test_driver.IronicDriverConsoleTestCase.test__get_node_console_with_reset_wait_timeout is definitely failing due to something changing with the enforce_type stuff in https://review.openstack.org/#/c/457188/ <- gcb22:23
mriedemoh because it changed from a 0.1 to a 122:23
*** Apoorva_ has quit IRC22:24
mriedemand _CONSOLE_STATE_CHECKING_INTERVAL is set to 0.0522:24
*** Apoorva has joined #openstack-nova22:24
mriedemjitter=0.5 in the driver22:25
*** felipemonteiro has quit IRC22:30
mriedemhttps://bugs.launchpad.net/nova/+bug/168395322:33
openstackLaunchpad bug 1683953 in OpenStack Compute (nova) "IronicDriverConsoleTestCase.test__get_node_console_with_reset_wait_timeout intermittently fails since 4/18" [Medium,Confirmed]22:33
*** Jack_Iv has joined #openstack-nova22:38
*** thorst has joined #openstack-nova22:41
*** Jack_Iv has quit IRC22:42
*** thorst has quit IRC22:43
*** thorst has joined #openstack-nova22:43
*** jianghuaw_ has joined #openstack-nova22:43
*** tjones has quit IRC22:43
*** jaypipes has quit IRC22:46
*** thorst has quit IRC22:47
*** jianghuaw_ has quit IRC22:48
*** salv-orl_ has quit IRC22:48
*** tjones has joined #openstack-nova22:50
*** tjones has quit IRC22:52
*** artom has quit IRC22:53
*** artom has joined #openstack-nova22:53
*** david-lyle has joined #openstack-nova22:53
*** david-lyle has quit IRC22:56
*** aloga has quit IRC22:57
*** ijw has joined #openstack-nova22:59
*** aloga has joined #openstack-nova23:03
*** ijw has quit IRC23:03
*** fragatin_ has quit IRC23:05
*** fragatina has joined #openstack-nova23:06
*** vladikr has joined #openstack-nova23:08
*** gjayavelu has quit IRC23:11
*** thorst has joined #openstack-nova23:15
*** slaweq has quit IRC23:16
*** ngupta has quit IRC23:23
*** ngupta has joined #openstack-nova23:24
*** ngupta has quit IRC23:28
*** mlavalle has quit IRC23:30
*** chyka has quit IRC23:33
*** gouthamr has joined #openstack-nova23:33
gmannmriedem: not yet, i am planning after summit and once we have extensions removal in good progress and more people can join hands there23:34
*** Sukhdev has joined #openstack-nova23:35
*** amotoki has quit IRC23:37
*** aloga has quit IRC23:37
*** tjones has joined #openstack-nova23:38
*** baoli has joined #openstack-nova23:38
*** tjones has quit IRC23:39
*** aloga has joined #openstack-nova23:41
*** Nakato has quit IRC23:45
*** Nakato has joined #openstack-nova23:46
mriedemok23:47
*** vladikr has quit IRC23:49
*** artom has quit IRC23:49
*** artom has joined #openstack-nova23:50
*** amotoki has joined #openstack-nova23:50
*** artom has quit IRC23:52
*** artom has joined #openstack-nova23:52
*** hongbin has quit IRC23:55
*** rfolco has joined #openstack-nova23:56
*** rfolco has quit IRC23:56
*** ijw has joined #openstack-nova23:59

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