Tuesday, 2017-11-28

*** ijw has quit IRC00:02
*** ankit_ has quit IRC00:05
*** penick has quit IRC00:05
*** gbarros has joined #openstack-nova00:05
*** tetsuro has joined #openstack-nova00:09
*** lei-zh has joined #openstack-nova00:10
*** salv-orlando has quit IRC00:12
*** salv-orlando has joined #openstack-nova00:13
tonybexport COMPUTE_API_VERSION=1.100:13
tonybis that ^^ even valid?  I though 2.1 was the functional minimum or am I confused?00:14
artomtonyb, I don't think that's valid00:15
artomI noticed that as well in the stuff we ship in OSP by default00:16
artomSomehow it ends up settling on latest, though, so I didn't dig further00:16
artomBut it's definitely weird00:16
*** AlexeyAbashkin has joined #openstack-nova00:17
*** salv-orlando has quit IRC00:17
*** AlexeyAbashkin has quit IRC00:21
*** gbarros has quit IRC00:23
tonybartom: I'm preety sure the version negotiation decides '1.1' isn't valid and defaults to latest.00:24
tonybartom: something to fix in queens00:25
*** ijw has joined #openstack-nova00:30
*** hongbin has quit IRC00:33
*** gbarros has joined #openstack-nova00:36
*** jmlowe has quit IRC00:39
*** jichen has joined #openstack-nova00:44
*** jmlowe has joined #openstack-nova00:46
*** Kevin_Zheng has joined #openstack-nova00:46
*** trinaths has joined #openstack-nova00:50
*** gbarros has quit IRC00:52
*** dklyle has quit IRC00:54
*** jichen has quit IRC01:01
*** MikeG451 has quit IRC01:01
*** david-lyle has joined #openstack-nova01:01
*** phuongnh has joined #openstack-nova01:06
*** suresh12 has quit IRC01:07
*** qsyqian has joined #openstack-nova01:07
*** zhouyaguo has joined #openstack-nova01:09
*** jaypipes has quit IRC01:10
*** liverpooler has joined #openstack-nova01:11
*** zhouyaguo has quit IRC01:12
*** salv-orlando has joined #openstack-nova01:14
*** yangyapeng has joined #openstack-nova01:15
*** yangyapeng has quit IRC01:16
*** yangyapeng has joined #openstack-nova01:16
openstackgerritLi Xipeng proposed openstack/nova master: Fix bug as BDM failed when booting from volume  https://review.openstack.org/52248601:17
*** salv-orlando has quit IRC01:19
*** jose-phi_ has joined #openstack-nova01:20
*** jose-phillips has quit IRC01:21
openstackgerritEli Qiao proposed openstack/nova master: Api-guide: Add Block Device Mapping  https://review.openstack.org/52208401:22
*** armax has quit IRC01:27
*** chyka_ has quit IRC01:29
*** suresh12 has joined #openstack-nova01:30
*** suresh12 has quit IRC01:35
*** dave-mccowan has joined #openstack-nova01:36
*** fragatin_ is now known as fragatina01:46
*** esberglu has joined #openstack-nova01:46
*** sdague has quit IRC01:47
*** mriedem has joined #openstack-nova01:48
*** esberglu has quit IRC01:50
openstackgerritMatt Riedemann proposed openstack/nova stable/pike: Refined fix for validating image on rebuild  https://review.openstack.org/52321201:52
openstackgerritMatt Riedemann proposed openstack/nova stable/pike: Add regression test for rebuild with new image doubling allocations  https://review.openstack.org/52321301:52
openstackgerritMatt Riedemann proposed openstack/nova stable/pike: Fix doubling allocations on rebuild  https://review.openstack.org/52321401:52
*** trinaths has left #openstack-nova01:55
openstackgerritMatt Riedemann proposed openstack/nova stable/pike: Add regression test for rebuild with new image doubling allocations  https://review.openstack.org/52321301:56
openstackgerritMatt Riedemann proposed openstack/nova stable/pike: Fix doubling allocations on rebuild  https://review.openstack.org/52321401:56
*** cheneydc has joined #openstack-nova02:00
*** suresh12 has joined #openstack-nova02:06
*** cheneydc has quit IRC02:07
*** tidwellr has joined #openstack-nova02:09
*** annp has joined #openstack-nova02:10
*** chyka has joined #openstack-nova02:13
*** salv-orlando has joined #openstack-nova02:15
*** AlexeyAbashkin has joined #openstack-nova02:16
*** chyka has quit IRC02:18
*** zhurong has joined #openstack-nova02:18
openstackgerritTakashi NATSUME proposed openstack/nova master: [placement] Add x-openstack-request-id in API ref  https://review.openstack.org/52300702:21
*** salv-orlando has quit IRC02:21
*** AlexeyAbashkin has quit IRC02:21
*** Apoorva_ has joined #openstack-nova02:21
*** yamamoto has joined #openstack-nova02:22
*** Apoorva has quit IRC02:25
*** Apoorva_ has quit IRC02:25
*** hongbin has joined #openstack-nova02:27
*** gcb has joined #openstack-nova02:27
*** lei-zh has quit IRC02:27
*** lei-zh has joined #openstack-nova02:28
*** takashin has joined #openstack-nova02:31
*** esberglu has joined #openstack-nova02:36
*** esberglu has quit IRC02:36
*** esberglu has joined #openstack-nova02:37
*** erlon has quit IRC02:41
*** esberglu has quit IRC02:41
*** qsyqian has quit IRC02:44
*** suresh12 has quit IRC02:53
*** yamahata has quit IRC02:53
*** gyee_ has quit IRC02:55
*** qsyqian has joined #openstack-nova02:57
*** ijw has quit IRC02:59
*** fragatina has quit IRC02:59
*** fragatina has joined #openstack-nova03:00
*** ijw has joined #openstack-nova03:02
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Implement query param schema for migration index  https://review.openstack.org/51864403:02
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Extract SortContext/SortWrapper of instance_list into utils  https://review.openstack.org/51887103:04
*** fragatina has quit IRC03:04
*** dave-mccowan has quit IRC03:12
*** dave-mccowan has joined #openstack-nova03:12
*** dave-mcc_ has joined #openstack-nova03:16
*** salv-orlando has joined #openstack-nova03:17
*** dave-mccowan has quit IRC03:18
*** tbachman has quit IRC03:22
*** ijw has quit IRC03:23
*** salv-orlando has quit IRC03:23
*** abhishekk has joined #openstack-nova03:26
*** sree has joined #openstack-nova03:32
openstackgerritGuoqiang Ding proposed openstack/nova master: Update the documentation links  https://review.openstack.org/52328803:33
*** ijw has joined #openstack-nova03:34
*** armax has joined #openstack-nova03:34
*** links has joined #openstack-nova03:39
*** sree has quit IRC03:43
*** diga has joined #openstack-nova03:45
openstackgerritMerged openstack/nova master: Refined fix for validating image on rebuild  https://review.openstack.org/52118603:48
*** sree has joined #openstack-nova03:49
*** yamamoto has quit IRC03:51
*** tbachman has joined #openstack-nova03:51
*** yamamoto has joined #openstack-nova03:53
*** yamamoto has quit IRC03:53
*** yamamoto has joined #openstack-nova03:54
*** yamamoto has quit IRC03:55
*** sree has quit IRC03:59
*** lei-zh has quit IRC04:03
*** yamamoto has joined #openstack-nova04:05
*** ijw has quit IRC04:08
*** ratailor has joined #openstack-nova04:10
*** udesale has joined #openstack-nova04:14
*** mdnadeem has joined #openstack-nova04:15
*** AlexeyAbashkin has joined #openstack-nova04:16
*** salv-orlando has joined #openstack-nova04:19
*** chyka has joined #openstack-nova04:21
*** AlexeyAbashkin has quit IRC04:21
*** sridharg has joined #openstack-nova04:24
*** salv-orlando has quit IRC04:25
*** chyka has quit IRC04:26
*** zhurong has quit IRC04:30
*** gouthamr has quit IRC04:31
*** hongbin has quit IRC04:32
*** liverpooler has quit IRC04:36
*** psachin has joined #openstack-nova04:37
*** takashin has left #openstack-nova04:39
*** tidwellr has quit IRC04:41
*** tidwellr has joined #openstack-nova04:41
*** dave-mcc_ has quit IRC04:42
*** yamamoto has quit IRC04:43
*** sree has joined #openstack-nova04:46
*** tbachman has quit IRC04:46
*** suresh12 has joined #openstack-nova04:53
*** tbachman has joined #openstack-nova04:53
*** yamamoto has joined #openstack-nova04:54
*** yamamoto has quit IRC04:54
*** yamamoto has joined #openstack-nova04:54
*** lei-zh has joined #openstack-nova05:05
*** janki has joined #openstack-nova05:07
*** threestrands has quit IRC05:10
*** threestrands has joined #openstack-nova05:10
*** threestrands has quit IRC05:10
*** threestrands has joined #openstack-nova05:10
*** coreywright has quit IRC05:11
*** claudiub|2 has joined #openstack-nova05:11
*** threestrands has quit IRC05:12
*** tidwellr has quit IRC05:12
*** threestrands has joined #openstack-nova05:12
*** threestrands has quit IRC05:12
*** threestrands has joined #openstack-nova05:12
*** tidwellr has joined #openstack-nova05:12
*** tidwellr has joined #openstack-nova05:13
*** coreywright has joined #openstack-nova05:16
*** tidwellr has quit IRC05:18
*** salv-orlando has joined #openstack-nova05:20
*** brault has quit IRC05:21
*** brault has joined #openstack-nova05:22
*** salv-orlando has quit IRC05:27
*** slaweq has joined #openstack-nova05:31
openstackgerritGhanshyam Mann proposed openstack/nova master: Fix 'all_tenants' & 'all_projects' type in api-ref  https://review.openstack.org/52291805:34
*** slaweq has quit IRC05:35
openstackgerritGhanshyam Mann proposed openstack/nova master: Add 'all_tenants' for GET sec group api ref  https://review.openstack.org/52291005:37
*** esberglu has joined #openstack-nova05:37
openstackgerritGhanshyam Mann proposed openstack/nova master: Fix 'all_tenants' & 'all_projects' type in api-ref  https://review.openstack.org/52291805:38
*** esberglu has quit IRC05:41
*** lei-zh has quit IRC05:45
*** lei-zh has joined #openstack-nova05:46
*** kalyan has joined #openstack-nova05:53
*** armax has quit IRC05:58
*** tbachman has quit IRC05:58
*** fragatina has joined #openstack-nova06:00
*** armax has joined #openstack-nova06:01
*** claudiub|2 has quit IRC06:01
*** armax has quit IRC06:02
*** fragatina has quit IRC06:05
*** pcaruana has joined #openstack-nova06:06
*** pcaruana has quit IRC06:06
*** zhurong has joined #openstack-nova06:06
*** lei-zh has quit IRC06:07
*** lei-zh has joined #openstack-nova06:07
*** lei-zh has quit IRC06:10
*** huanxie has joined #openstack-nova06:12
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Extract SortContext/SortWrapper of instance_list into utils  https://review.openstack.org/51887106:14
*** karthiks has joined #openstack-nova06:14
*** esberglu has joined #openstack-nova06:15
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Add cross cell sort support for get_migrations  https://review.openstack.org/51727306:16
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Implement query param schema for migration index  https://review.openstack.org/51864406:18
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Extract SortContext/SortWrapper of instance_list into utils  https://review.openstack.org/51887106:18
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Add cross cell sort support for get_migrations  https://review.openstack.org/51727306:19
*** esberglu has quit IRC06:20
*** fragatina has joined #openstack-nova06:21
*** lpetrut has joined #openstack-nova06:22
*** salv-orlando has joined #openstack-nova06:22
*** salv-orlando has quit IRC06:28
openstackgerritGhanshyam Mann proposed openstack/nova master: check query param for server groups function  https://review.openstack.org/50034706:33
*** qsyqian_ has joined #openstack-nova06:34
*** fragatina has quit IRC06:34
*** fragatina has joined #openstack-nova06:34
*** diga has quit IRC06:38
*** qsyqian_ has quit IRC06:38
*** qsyqian has quit IRC06:38
*** fragatina has quit IRC06:38
*** tojuvone has quit IRC06:39
*** bkopilov has joined #openstack-nova06:42
*** fragatina has joined #openstack-nova06:43
*** xinliang has quit IRC06:46
*** salv-orlando has joined #openstack-nova06:49
*** salv-orlando has quit IRC06:50
*** salv-orlando has joined #openstack-nova06:50
*** liuzz has joined #openstack-nova06:53
openstackgerritxulei proposed openstack/nova master: correct the resource provider log when return 409  https://review.openstack.org/52176406:55
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Add cross cell sort support for get_migrations  https://review.openstack.org/51727306:58
*** xinliang has joined #openstack-nova07:00
*** mriedem has quit IRC07:00
*** threestrands has quit IRC07:04
*** edand has joined #openstack-nova07:05
*** zhurong has quit IRC07:05
*** fragatina has quit IRC07:06
*** namnh has joined #openstack-nova07:06
*** fragatina has joined #openstack-nova07:07
*** josecastroleon has joined #openstack-nova07:08
*** suresh12 has quit IRC07:10
*** yamahata has joined #openstack-nova07:11
*** fragatina has quit IRC07:11
*** suresh12 has joined #openstack-nova07:13
*** Oku_OS-away is now known as Oku_OS07:14
*** slaweq has joined #openstack-nova07:17
*** suresh12 has quit IRC07:17
*** spectr has joined #openstack-nova07:18
*** edand has quit IRC07:20
*** spectr has quit IRC07:21
*** diga has joined #openstack-nova07:22
*** moshele has joined #openstack-nova07:23
*** slaweq has quit IRC07:25
*** sree_ has joined #openstack-nova07:28
*** claudiub|2 has joined #openstack-nova07:28
*** sree_ is now known as Guest7970107:28
*** danpawlik has quit IRC07:29
*** sree has quit IRC07:31
*** gszasz has joined #openstack-nova07:34
*** fragatina has joined #openstack-nova07:39
*** slaweq has joined #openstack-nova07:44
*** Alex_Staf has quit IRC07:48
*** AlexeyAbashkin has joined #openstack-nova07:52
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Add cross cell sort support for get_migrations  https://review.openstack.org/51727307:52
*** rcernin has quit IRC07:53
*** andreas_s has joined #openstack-nova07:58
openstackgerritHamdy Khader proposed openstack/nova master: Adding NVMEoF for libvirt driver  https://review.openstack.org/48264007:59
*** andreas_s has quit IRC08:08
*** ratailor has quit IRC08:09
*** trungnv has quit IRC08:18
*** trungnv has joined #openstack-nova08:18
*** lpetrut has quit IRC08:18
*** ralonsoh has joined #openstack-nova08:18
*** hieulq has quit IRC08:20
*** damien_r has joined #openstack-nova08:20
*** hieulq has joined #openstack-nova08:20
*** danpawlik has joined #openstack-nova08:22
*** danpawlik has quit IRC08:23
*** danpawlik has joined #openstack-nova08:24
*** slaweq_ has joined #openstack-nova08:24
*** lpetrut has joined #openstack-nova08:25
*** danpawlik has quit IRC08:26
*** ragiman has joined #openstack-nova08:28
*** pcaruana has joined #openstack-nova08:28
*** danpawlik has joined #openstack-nova08:29
*** slaweq_ has quit IRC08:29
openstackgerritJianghua Wang proposed openstack/nova master: XenAPI: get vGPU stats from hypervisor  https://review.openstack.org/51296508:30
openstackgerritJianghua Wang proposed openstack/nova master: XenAPI: provide vGPU inventory in compute node  https://review.openstack.org/51621708:30
openstackgerritJianghua Wang proposed openstack/nova master: XenAPI: create vGPU for instance  https://review.openstack.org/51689908:30
openstackgerritJianghua Wang proposed openstack/nova master: XenAPI: provide VGPU_DISPLAY_HEAD inventory in compute node  https://review.openstack.org/52334208:30
*** alexchadin has joined #openstack-nova08:31
openstackgerritJianghua Wang proposed openstack/nova master: XenAPI: provide VGPU_DISPLAY_HEAD inventory in compute node  https://review.openstack.org/52334208:37
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Add pagination and Changes-since filter support for os-migrations.  https://review.openstack.org/33040608:39
*** ratailor has joined #openstack-nova08:48
*** AlexeyAbashkin has quit IRC08:48
*** damien_r has quit IRC08:51
*** AlexeyAbashkin has joined #openstack-nova08:51
*** sahid has joined #openstack-nova08:51
*** damien_r has joined #openstack-nova08:51
*** gmann is now known as gmann_afk08:53
openstackgerritZhenyu Zheng proposed openstack/nova master: Add instance action record for lock/unlock instances  https://review.openstack.org/52335308:54
*** cdent has joined #openstack-nova08:57
*** vladikr has quit IRC08:57
*** vladikr has joined #openstack-nova09:00
*** priteau has joined #openstack-nova09:01
openstackgerritHamdy Khader proposed openstack/nova master: Adding NVMEoF for libvirt driver  https://review.openstack.org/48264009:02
*** stvnoyes has quit IRC09:02
*** stvnoyes has joined #openstack-nova09:02
*** yamamoto has quit IRC09:04
*** yamamoto has joined #openstack-nova09:05
*** jpena|off is now known as jpena09:09
*** yamamoto has quit IRC09:11
*** lucas-afk is now known as lucasagomes09:19
*** zhurong has joined #openstack-nova09:20
*** sbezverk has quit IRC09:22
alex_xucdent: good morning, I have a confuse on this patch https://review.openstack.org/#/c/510626, looks like we just ignore the 'generation' parameter from the request, is it on purpose? or I missed something09:22
cdentyes, it is ignored on purpose. the idead is that when you do a GET the generation is included, so if you want to PUT that back you don’t have to worry about removing the generation09:23
cdentthere’s more in the linked spec09:23
*** moshele has quit IRC09:24
*** moshele has joined #openstack-nova09:24
*** moshele has quit IRC09:25
*** moshele_ has joined #openstack-nova09:26
*** moshele_ has quit IRC09:26
*** moshele has joined #openstack-nova09:26
alex_xucdent: ah, thanks09:27
openstackgerritJianghua Wang proposed openstack/nova master: XenAPI: update the picture in Xen hypervisor document  https://review.openstack.org/52336009:30
*** jichen has joined #openstack-nova09:30
openstackgerritJianghua Wang proposed openstack/nova master: XenAPI: update the picture in Xen hypervisor document  https://review.openstack.org/52336009:32
*** salv-orlando has quit IRC09:33
*** salv-orlando has joined #openstack-nova09:33
openstackgerritJianghua Wang proposed openstack/nova master: XenAPI: update the picture in Xen hypervisor document  https://review.openstack.org/52336009:37
*** salv-orlando has quit IRC09:38
*** ociuhandu has joined #openstack-nova09:43
*** lpetrut has quit IRC09:44
*** ociuhandu has quit IRC09:46
*** derekh has joined #openstack-nova09:46
*** openstackgerrit has quit IRC09:48
*** diga has quit IRC09:49
*** Alex_Staf has joined #openstack-nova09:52
*** erlon has joined #openstack-nova09:55
*** rcernin has joined #openstack-nova09:55
*** chyka has joined #openstack-nova09:57
*** chyka has quit IRC10:02
*** sdatko has quit IRC10:06
*** diga has joined #openstack-nova10:06
*** yamahata has quit IRC10:07
*** namnh has quit IRC10:07
*** openstackgerrit has joined #openstack-nova10:08
openstackgerritClaudiu Belu proposed openstack/nova master: POC: tests: autospecs all the mock.patch usages  https://review.openstack.org/47077510:08
*** sambetts|afk is now known as sambetts10:11
*** yamamoto has joined #openstack-nova10:14
*** yamamoto has quit IRC10:19
*** zhurong has quit IRC10:19
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Add pagination and changes-since for instance-actions  https://review.openstack.org/32632610:20
*** sdague has joined #openstack-nova10:22
*** alexchadin has quit IRC10:28
*** gcb has quit IRC10:28
*** rmart04 has joined #openstack-nova10:29
*** phuongnh has quit IRC10:30
*** kalyan has quit IRC10:33
*** lpetrut has joined #openstack-nova10:35
*** huanxie has quit IRC10:36
*** kalyan has joined #openstack-nova10:37
*** slaweq_ has joined #openstack-nova10:37
*** saop has joined #openstack-nova10:40
saopHello all10:40
nkorabliHey10:41
*** jaianshu_ has joined #openstack-nova10:41
saopI have openstack pike, and i tried to provision one instance with nova using libvirt driver10:41
*** slaweq_ has quit IRC10:42
saopI got error regarding "VirtualInterfaceCreateException: Virtual Interface creation failed"10:42
saopMy dhcp is right and everything seems fine10:42
saopany idea what's the problem?10:43
*** ArchiFleKs has quit IRC10:45
*** esberglu has joined #openstack-nova10:46
*** alexchadin has joined #openstack-nova10:51
*** esberglu has quit IRC10:51
*** udesale has quit IRC10:55
nkorabliI'm not an expert on that, sorry..10:56
*** abhishekk has quit IRC10:57
openstackgerritxulei proposed openstack/nova master: correct the resource provider log when return 409  https://review.openstack.org/52176410:58
*** salv-orlando has joined #openstack-nova11:01
*** cdent has quit IRC11:01
*** annp has quit IRC11:03
nsinghi am facing an issue ref: http://paste.openstack.org/show/627553/. any help?11:03
openstackgerritHuang Rui proposed openstack/nova master: z/VM Driver: Initial change set of z/VM driver  https://review.openstack.org/52338711:06
*** salv-orlando has quit IRC11:07
*** salv-orlando has joined #openstack-nova11:08
openstackgerritMerged openstack/nova master: [placement] Symmetric GET and PUT /allocations/{consumer_uuid}  https://review.openstack.org/51062611:09
*** salv-orlando has quit IRC11:13
*** salv-orlando has joined #openstack-nova11:14
openstackgerritZhenyu Zheng proposed openstack/nova master: Add instance action record for lock/unlock instances  https://review.openstack.org/52335311:24
*** nkorabli has quit IRC11:27
*** Mahesh has joined #openstack-nova11:27
*** nkorabli has joined #openstack-nova11:27
*** nkorabli has quit IRC11:32
*** diga has quit IRC11:35
*** mdnadeem has quit IRC11:38
openstackgerritBalazs Gibizer proposed openstack/nova master: Extract instance allocation removal code  https://review.openstack.org/51304111:38
*** chyka has joined #openstack-nova11:47
*** mhenkel has quit IRC11:50
*** chyka has quit IRC11:51
*** efried has quit IRC11:54
*** Guest79701 has quit IRC11:54
*** mhenkel has joined #openstack-nova11:54
*** mdnadeem has joined #openstack-nova11:55
openstackgerritYikun Jiang (Kero) proposed openstack/nova master: Add pagination and changes-since for instance-actions  https://review.openstack.org/32632611:56
openstackgerritWangpan proposed openstack/nova master: Handle ImageInUse exception during instance backup  https://review.openstack.org/52339511:56
*** linpopilan has quit IRC11:58
*** ratailor has quit IRC11:59
*** bkopilov has quit IRC12:01
*** psachin has quit IRC12:01
*** sree has joined #openstack-nova12:02
*** sapd_ has quit IRC12:03
*** sapd__ has joined #openstack-nova12:03
*** efried has joined #openstack-nova12:07
*** sree has quit IRC12:07
openstackgerritChris Dent proposed openstack/nova master: [placement] Enable limiting GET /allocation_candidates  https://review.openstack.org/51352612:09
ebbex/os-simple-tenant-usage/{tenant_id} , should that query return duplicates in "server_usages": [] ?12:12
efriednsingh Still around?12:15
nsinghyes12:15
efriednsingh What's the config group?12:16
nsinghu mean in cinder?12:17
efriedWherever the mystery session conf options are showing up12:18
efriedalex_xu yt?12:18
*** yamamoto has joined #openstack-nova12:18
*** takedakn has joined #openstack-nova12:18
nsinghit is showing the config group that i have provided as parameter.12:19
efriedalex_xu FYI, I'm in the middle of porting those two test cases over.  If they pass, I'll just slap 'em on top of the series.  If they don't...12:19
efriednsingh I don't understand.12:20
efriednsingh What's the name of the conf group?12:20
nsinghglance12:21
efriednsingh And in which process are these options showing up?12:21
*** yamamoto has quit IRC12:22
*** takedakn has quit IRC12:23
*** sree has joined #openstack-nova12:23
nsinghwhen i went inside https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/loading/session.py#L225 (kwargs.setdefault('insecure', c.insecure))12:23
*** udesale has joined #openstack-nova12:23
efriednsingh Which openstack service process are you in?  c-api?  n-cpu?  etc.12:23
nsinghc-api12:24
efriedokay, stand by...12:24
*** jaianshu__ has joined #openstack-nova12:25
*** jaianshu__ has quit IRC12:25
nsinghinsecure cafile certfile keyfile timeout -- are these options are added in the opt list of group at the time of service start? sorry another question.12:25
nsinghhttps://github.com/openstack/keystoneauth/blob/master/keystoneauth1/loading/session.py#L18012:26
*** sree has quit IRC12:27
*** jaianshu_ has quit IRC12:28
openstackgerritChris Dent proposed openstack/nova master: [placement] POST /allocations to set allocations for >1 consumers  https://review.openstack.org/50007312:31
openstackgerritChris Dent proposed openstack/nova master: [placement] Fix GET PUT /allocations nits  https://review.openstack.org/52340112:31
efriednsingh Yes, if they're registered via that call.  Can you tell me the command line for your c-api process?12:33
*** esberglu has joined #openstack-nova12:34
*** saop has quit IRC12:35
*** jaianshu has joined #openstack-nova12:36
efriednsingh systemctl status should show it.12:36
nsinghare you asking about logs ?12:37
nsinghok12:37
nsinghhttp://paste.openstack.org/show/627566/12:38
*** esberglu has quit IRC12:39
efriednsingh Can you paste me that cinder-api-uwsgi.ini?12:42
*** lpetrut has quit IRC12:42
nsinghhttp://paste.openstack.org/show/627569/12:43
*** nkorabli has joined #openstack-nova12:44
openstackgerritWangpan proposed openstack/nova master: Handle ImageInUse exception during instance backup  https://review.openstack.org/52339512:45
*** tetsuro has quit IRC12:47
openstackgerritChris Dent proposed openstack/nova master: WIP: [placement] use global conf with auth token middleware  https://review.openstack.org/52340312:48
*** Mahesh has quit IRC12:50
*** nkorabli has quit IRC12:51
*** yangyapeng has quit IRC12:56
jaianshuHello everyone12:59
jaianshui'm getting error in spawning vm on stable/pike " Failed to allocate the network(s), not rescheduling."13:00
nsinghefried: still there?13:00
jaianshu n-cpu.log - http://paste.openstack.org/show/627576/13:00
jaianshuany ideas?13:01
efriednsingh Yes, sorry, looking at cinder-wsgi...13:01
nsinghefried: ooh thanks13:02
*** smatzek has joined #openstack-nova13:02
*** dtantsur|afk is now known as dtantsur13:02
*** jpena is now known as jpena|lunch13:02
*** cdent has joined #openstack-nova13:03
cdentefried: what’s the emoji for :kid with fingers in ears saying la la la la la la over and over: ?13:03
*** sree has joined #openstack-nova13:04
efriedcdent I can think of a couple of finger emojis13:04
cdentheh13:04
*** dave-mccowan has joined #openstack-nova13:05
*** mdnadeem has quit IRC13:06
*** liverpooler has joined #openstack-nova13:06
kalyanjaianshu: virtual interface creation failed...could you please check if vif plugin entries present in the nova.conf13:07
efriednsingh To make sure I understand, we're saying is that your c-api process is registering ksa auth opts in the [glance] conf section, right?13:08
nsinghefried: yes13:08
*** sree has quit IRC13:08
cdenthurrah it is microversion merge conflict day!13:09
jaianshukalyan: i have these 2 entries for vif-plugin in nova.conf - vif_plugging_timeout=1013:09
jaianshu and vif_plugging_is_fatal=False13:09
*** slaweq_ has joined #openstack-nova13:10
openstackgerritjichenjc proposed openstack/nova master: check query param for server groups function  https://review.openstack.org/50034713:10
*** ijw has joined #openstack-nova13:11
efriednsingh Okay; I can't see how that's happening.  Normally it would be via keystoneauth1.loading.register_auth_conf_options, but I don't see anywhere in cinder that's being done for a [glance] section, directly or indirectly.  Perhaps someone in #openstack-cinder could shed some light on that.13:11
nsinghefried: ok is it done for any section?13:12
efriednsingh Not that I can see.13:12
nsinghefried: ok thank you for help. :)13:13
efriednsingh Good luck.13:13
nsinghefried: And your suggestion about cinder to nova interaction that i asked earlier works. So thank you for that also.13:14
efriednsingh Oh, great to hear.13:14
*** slaweq_ has quit IRC13:14
efriednsingh Which one was it?13:14
*** lucasagomes is now known as lucas-hungry13:14
*** jichen has quit IRC13:14
nsinghefried: you replied me on mail.13:15
efriednsingh Right, and I suggested three or four things - which one was the right one?13:15
*** ijw has quit IRC13:15
nsinghefried: n-cpu was pointing to nova-cpu.conf and i add sevice user configuration in nova.conf13:16
efriednsingh Okay, cool.13:16
efriednsingh I got burned by that a few months ago.13:16
nsinghefried: oohh..13:16
*** links has quit IRC13:16
*** nkorabli has joined #openstack-nova13:18
*** pchavva has joined #openstack-nova13:21
*** nkorabli has quit IRC13:21
*** mdnadeem has joined #openstack-nova13:22
*** edmondsw has joined #openstack-nova13:22
*** sree has joined #openstack-nova13:24
*** pchavva has quit IRC13:27
*** READ10 has joined #openstack-nova13:27
*** abalutoiu has joined #openstack-nova13:27
*** bkopilov has joined #openstack-nova13:28
*** sree has quit IRC13:29
*** esberglu has joined #openstack-nova13:29
*** esberglu has quit IRC13:29
*** esberglu has joined #openstack-nova13:29
*** esberglu has quit IRC13:29
*** esberglu has joined #openstack-nova13:30
*** sree has joined #openstack-nova13:30
*** jaypipes has joined #openstack-nova13:31
*** yangyapeng has joined #openstack-nova13:32
*** mriedem has joined #openstack-nova13:32
openstackgerritChris Dent proposed openstack/nova master: [placement] Object changes to support last-modified headers  https://review.openstack.org/52163913:34
openstackgerritChris Dent proposed openstack/nova master: [placement] Add cache headers to placement api requests  https://review.openstack.org/52164013:34
*** sree has quit IRC13:35
*** esberglu has quit IRC13:35
*** yangyapeng has quit IRC13:37
mriedembauzas: can you take a look at https://review.openstack.org/#/c/521391/ and the patch below it? those have to get backported through to newton and i was holding up the backports until i got some core review13:42
*** pchavva has joined #openstack-nova13:42
*** sree has joined #openstack-nova13:43
*** lyan has joined #openstack-nova13:50
mriedemalex_xu: do you know if @wsgi.action('migrate') ensures that a cold migration request will have a 'migrate' key in the request body even if the value for that key is null? we don't actually care about the value13:51
*** peter-hamilton has joined #openstack-nova13:52
mriedemmy guess is we wouldn't route properly if the request body didn't have the 'migrate' key in it13:53
*** tbachman has joined #openstack-nova13:54
jianghuaw_jaypipes, bauzas: are you around?13:56
openstackgerritEric Fried proposed openstack/nova master: Use ksa adapter for keystone conf & requests  https://review.openstack.org/50769313:57
*** salv-orlando has quit IRC13:57
*** jaianshu has quit IRC13:58
ildikovmriedem: hi :)14:00
ildikovmriedem: I hope you had a great Turkey weekend :)14:00
*** esberglu has joined #openstack-nova14:00
*** yamahata has joined #openstack-nova14:00
jaypipesjianghuaw_: I am indeed.14:00
moshelejaypipes: hi can you +W  review https://review.openstack.org/#/c/519066/ Rabi Mishra for heat team tested and it pass their test14:00
ildikovmriedem: so I think it's time now to do my regular "pretty please speech" for review: https://review.openstack.org/#/c/330285/14:00
jianghuaw_jaypipes, hi Jay. I posted a patch to create inventory data for VGPU_DISPLAY_HEAD. But later I realized there would be a problem.14:00
jianghuaw_https://review.openstack.org/#/c/523342/2/nova/virt/xenapi/driver.py@47714:01
ildikovjohnthetubaguy: same pretty please goes to you too ^^14:01
jaypipesmoshele: done14:01
jianghuaw_jaypipes, The vgpu display heads is not independent resources. When it consuming VGPUs, it also consumes display heads.14:01
moshelejaypipes: cool thanks :)14:01
jaypipesjianghuaw_: is there a specific relationship between the quantities? for example, does 1 VGPU means 1 display head will be consumed?14:02
jaypipesjianghuaw_: or is it dependent on the vGPU type?14:02
efriedsdague Would you please have a look at https://review.openstack.org/#/c/409404/ when you get a chance?14:05
jaypipesefried: I'm rebasing the series from review 520246. just making sure you've no local changes?14:05
efriedjaypipes No yet.  Go for it.14:06
jaypipesrock on.14:06
*** thorst has joined #openstack-nova14:06
efriedAnd thanks as always for checking14:06
jianghuaw_jaypipes, sorry. I just got a network disconnection.14:06
openstackgerritChris Dent proposed openstack/nova master: WIP: [placement] use global conf with auth token middleware  https://review.openstack.org/52340314:06
jaypipesjianghuaw_: I'll repeat...14:06
jianghuaw_jaypipes, yes. it depends on the vGPU type.14:06
jaypipesjianghuaw_: is there a specific relationship between the quantities? for example, does 1 VGPU means 1 display head will be consumed?14:07
jaypipesjianghuaw_: or is it dependent on the vGPU type?14:07
*** lucas-hungry is now known as lucasagomes14:07
jianghuaw_For example: There each vGPU supports 2 display heads and total vGPU is 5; then initially the available vGPUs amount is 5; and  available amount of display heads is 1014:07
jaypipesjianghuaw_: ok. so what is the problem with ensuring the flavor requests both VGPU and display head resources?14:07
jianghuaw_After we boot an instance with one VGPU. The available display heads will also be reduce to 8. But placement doesn’t know of the change on display heads if we don’t specify VGPU_DISPLAY_HEAD in the request spec.14:07
jianghuaw_if we specify both VGPU and display_heads, it should work.14:08
jaypipesjianghuaw_: is there a reason we can't specify display heads in the flavor?14:08
jianghuaw_But I think we should allow flavor to only request VGPU.14:08
*** jpena|lunch is now known as jpena|off14:08
jianghuaw_as the display heads is optional.14:08
efriedjianghuaw_ That's what I was going to suggest.14:08
efriedjianghuaw_ Is it always a certain number of display heads for a given type of vGPU?14:09
jianghuaw_yes. it is.14:09
*** gbarros has joined #openstack-nova14:09
efriedjianghuaw_ And is it possible to do requests in such a way that you run out of display heads before you run out of VGPUs?14:09
jianghuaw_the amount of display heads is determined by the vgpu type.14:09
jianghuaw_shouldn't.14:10
efriedjianghuaw_ Then yeah, I say leave display heads out of the picture entirely.  Don't register them as resources, and don't include them in the flavor.14:10
*** jmlowe has quit IRC14:10
sdagueefried: +A14:11
efriedsdague Thanks!14:11
sdagueand +2 on the config matrix update14:11
efriedsdague Cool.14:12
jianghuaw_efried, but I guess some customers may want to request vGPU with needed heads.14:12
*** abhishekk has joined #openstack-nova14:13
*** pcaruana has quit IRC14:13
jianghuaw_jaypipes, efried: I'm feeling the display heads somehow looks like a trait.14:14
jaypipesjianghuaw_: it's not :) it's a consumable resource14:15
efriedUnless it's like DUAL_DISPLAY_HEAD_CAPABLE :)14:15
jianghuaw_jaypipes, but it does have problem if we allow having display head as optional.14:16
edleafejianghuaw_: can you request a vGPU *without* consuming a display head?14:16
jaypipesjianghuaw_: why is that? wouldn't you just have a flavor that doesn't have display heads?14:16
*** pcaruana has joined #openstack-nova14:17
jianghuaw_efried, some vGPU types don't support display heads.14:17
jianghuaw_As some vGPUs don't support display heads. so the display heads' inv may be empty. So we should allow the flavor without specifying display heads.14:19
efriedjianghuaw_ In those cases, it makes sense.  Where I think we're having issues is this idea that, by requesting a certain type of vGPU, we might "automatically" consume some number of display heads.  We can't do that if we're inventorying the display heads.14:20
jianghuaw_But it's still possible to allocate a vGPU which support display heads it only request some kind of vGPU.14:20
efriedjianghuaw_ Let me ask it this way: In these cases where certain vGPU types support consuming display heads, is it possible to request a vGPU *without* consuming display heads?14:21
*** yamamoto has joined #openstack-nova14:21
jianghuaw_efried, yes. that's exactly the problem I met.14:21
edleafeefried: jinx-ish14:22
efriedjianghuaw_ If they need to be inventoried as separate resources, then they need to be requested as separate resources.14:22
jaypipesefried: +114:23
efriedjianghuaw_ And it sounds like we may have cases where a particular flavor setup is simply invalid: If there's a vGPU type that *must* consume display heads, your flavor *must* request the appropriate number of vGPUs *and* display heads.  Otherwise it's bogus.14:24
bauzasjianghuaw_: sorry was afk14:25
jianghuaw_bauzas, hi. no worries.14:25
bauzasoh, you're discussing about display heads ?14:25
jianghuaw_bauzas, yes.14:25
bauzasok14:25
mriedemesberglu: efried: why are evacuate and rebuild marked as missing in here? https://review.openstack.org/#/c/523140/14:25
mriedemnova-compute has a default rebuild impl if the virt driver doesn't implement it's own14:26
bauzasso, the point is that given some VGPU types don't provide display heads, then the inventory for them would be none14:26
bauzasso, when asking for display heads, the placement API wouldn't provide the computes having them14:27
jianghuaw_yes. I think we have cases that the vGPUs don't support display heads co-exist with vGPU not supporting it.14:27
bauzasthen, the scheduler would allocate a claim only for the computes supporting them14:27
efriedmriedem We have logic to make sure devices are re-attached in the proper order on rebuild.  That logic isn't in the in-tree driver yet.  So a rebuild *might* work with the default impl, but it might not.14:27
jianghuaw_that's why I'm thinking we should allow flavors which don't request display heads.14:28
bauzasjianghuaw_: see the problem ?14:28
bauzasright14:28
mriedemefried: that's why it was marked 'unknown'14:28
mriedemefried: i don't think libvirt ensures devices are re-attached in the same order on rebuild either14:29
mriedemthat's why mdbooth had the bdm metadata stuff for awhile14:29
mriedem*i think*14:29
*** janki has quit IRC14:29
mdboothefried: They are definitely *not* reattached in the same order in all circumstances14:30
jianghuaw_bauzas, It's possible to allocate vGPUs which actually supports display heads for those flavors not requesting display heads.14:30
*** smatzek has quit IRC14:30
efriedmdbooth Yeah, so in PowerVM, we guarantee that.14:30
jianghuaw_as the resource provider have inventory for VGPU which can meet the request.14:30
*** smatzek has joined #openstack-nova14:31
mdboothefried: It would be nice.14:31
mdboothefried: Is your scheme reproducible?14:31
efriedmriedem Yeah, I confirmed by looking at our OOT driver - there's a bunch of special stuff we do in spawn for the rebuild case that we haven't ported in yet.  So we want to declare that we *don't* support rebuild in the in-tree driver yet.14:31
*** slaweq has quit IRC14:31
bauzasjianghuaw_: the problem I see is that if you provide a flavor asking for both VGPUs *and* heads, then the scheduler will ask placement for *both*14:31
mdboothefried: i.e. Could the libvirt driver use it?14:32
*** slaweq has joined #openstack-nova14:32
*** alexchadin has quit IRC14:32
efriedmdbooth Bunch of caveats, but I think the concept might be portable.14:32
bauzasjianghuaw_: AFAIR, we had a spec for modifying the placement call to ask for some resource classes not mandatory14:32
bauzasefried: jaypipes: is it, right?14:32
efriedbauzas Not for Q14:33
mdboothThe issue the libvirt driver has is the interaction between dynamic and 'static' disks14:33
bauzasefried: yup,  I know14:33
bauzasefried: I was more commenting about the fact we discussed that14:33
efriedbauzas The one I remember was for "preferred traits", not for optional resource classes.14:33
bauzasyeah that14:33
mdboothSo if you have an instance with a root disk and a config disk, then you attach  a volume, you'll have root disk, config disk, volume14:33
mdboothBut in rebuild we always put the config disk last14:33
*** yamamoto has quit IRC14:33
mdboothSo on rebuild you'll have root disk, volume, config disk14:33
jianghuaw_bauzas, I think this case makes sense. What I'm think is that a flavor is asking only VGPU, but it placement may return RPs which contains display heads also.14:33
mdboothAnd in fact we have no way of knowing what the previous order was14:34
jianghuaw_it will result into the display heads leaking.14:34
bauzasjianghuaw_: right14:34
bauzaswhat do you mean by leaking ?14:34
*** eharney has quit IRC14:34
efriedmdbooth For us, the dev order is determined by which virtual "slot" the disk is attached via.  So we maintain a cache of which devices are associated with which slots, and then we make sure to restore that on rebuild.14:34
bauzasjianghuaw_: that's depending on the virt driver, right ?14:34
mdboothefried: Right. Where do you store the cache, though?14:35
*** smatzek has quit IRC14:35
efriedmdbooth In our case, in order to support that, the user has to set up swift :$14:35
mdboothAh...14:35
efriedindeeed.14:35
jianghuaw_bauzas, I mean it automatically consumed display heads. but placement don't it.14:35
mdboothSee, I actually think there's a lot of merit in having persistent driver state14:35
mdboothI think it should be local to the hypervisor, though14:36
efriedmdbooth We don't go crazy with persistent state, for sure.  We save these slot mappings, and we save the partition's NVRAM.14:36
*** slaweq has quit IRC14:36
jianghuaw_bauzas, don't it => doesn't know of it.14:36
mdboothefried: Definitely in favour of the concept.14:37
efriedmdbooth I have to say, our implementation ain't pretty.14:37
jianghuaw_bauzas, virt driver can only stop a booting by checking the resoureces in the allocation.14:38
*** maciejjozefczyk has quit IRC14:38
efriedmdbooth It was one of these rush jobs where we realized the problem (devices attached out of order) late in a cycle, and threw together a solution at the last minute.14:38
mdboothefried: Out of curiosity, why did you consider it a sufficiently big problem for a big rush job?14:38
jianghuaw_bauzas, or is there a way to correct the allocation if the allocated vGPU also supports display heads?14:39
mdboothDevice ordering is also inconsistent in a Linux guest OS14:39
openstackgerritChris Dent proposed openstack/nova master: [placement] re-use existing conf with auth token middleware  https://review.openstack.org/52340314:39
*** sree_ has joined #openstack-nova14:39
efriedmdbooth I don't remember all the reasons, but e.g. maybe you don't boot.14:39
efriedmdbooth Or possibly worse, boot to the wrong disk.14:39
*** sree_ is now known as Guest9753014:39
*** sree has quit IRC14:40
*** armax has joined #openstack-nova14:40
efriedmdbooth Also could have something to do with applications in guests referring to devices by name - and if that name changes, you're kaput.14:41
mdboothefried: That last point isn't fixed by consistent device ordering14:41
efriedmdbooth Keep in mind we're running not just Linux, but also AIX and IBMi.14:41
mdboothBecause as I say, Linux itself is also non-deterministic14:41
mdboothThe first should be handled by the hypervisor specifying a boot order for its BIOS/UEFI14:42
mdboothOr whatever hopefully much better boot solution is in Power :)14:43
efriedmdbooth That's exactly the point: The boot list is specified based on hardware addresses, which are discovered based on slots.14:43
*** lpetrut has joined #openstack-nova14:44
efriedmdbooth The big conceptual divide here is that PowerVM has a real hypervisor and the guests are real partitions.14:45
*** jdillaman has joined #openstack-nova14:45
jianghuaw_bauzas, I think efried's opinion is that we shouldn't make inventory for VGPU_DISPLAY_HEAD as that's possible to be consumed automatically by requesting VGPU.14:46
*** gbarros has quit IRC14:46
efriedjianghuaw_ Only if display heads are *only* consumed automatically by requesting VGPU14:46
edleafejianghuaw_: if it can't be consumed independently, and is always consumed automatically, then it shouldn't be tracked as inventory.14:47
efriedjianghuaw_ If it's possible to request them separately, then you need to inventory them separately; and then have extra logic in scenarios where it would happen automatically such that, if the flavor doesn't request the appropriate number of each, you throw an error.14:47
bauzasjianghuaw_: I agree with him14:47
bauzasjianghuaw_: until we have a way to track optional resources classes, we shouldn't be providing inventories for display heads IMHO14:48
bauzasand just do the display head consumption solely in the virt driver, if you can14:48
bauzastbh, libvirt doesn't support that yet, so I don't give a bit of that :p14:48
openstackgerritMatt Riedemann proposed openstack/nova stable/ocata: Refined fix for validating image on rebuild  https://review.openstack.org/52342714:49
jianghuaw_bauzas, efried Ok. Agreed. I will drop that patch for inventoring display heads.14:50
jianghuaw_Per my understand, the display heads will always be consumed automatically as long as the VGPUs supporting display heads.14:51
*** salv-orlando has joined #openstack-nova14:51
*** brault has quit IRC14:51
jianghuaw_Actually different vGPU types may support different display heads. And users may need some vGPUs which support specified amount of display heads. That's why I said it seems somehow traits for the vGPUs.14:53
efriedjianghuaw_ Yes, that sounds like it might be suitable for traits.14:54
jianghuaw_efried, but jaypipes seems don't agree ^ :-)14:55
*** brault has joined #openstack-nova14:55
bauzasjianghuaw_: well, requesting a display head is not quantitative14:55
efriedjianghuaw_ It depends whether it can be consumed independently, or is always tied to the VGPU.14:55
efriedWhich I'm still not clear on.14:55
*** salv-orl_ has joined #openstack-nova14:56
jianghuaw_efried, yes, it's always tied to VGPU.14:56
*** mlavalle has joined #openstack-nova14:56
efriedOkay.  If it is *always* the case that requesting a specific VGPU results in a specific number (possibly zero) of display heads being consumed, then there's no reason to inventory separately.14:56
efriedjianghuaw_ And how does the user specify which type of VGPU they're getting?14:57
bauzasby the trait14:58
jianghuaw_yes, by traits.14:58
openstackgerritBalazs Gibizer proposed openstack/nova master: Nits from Ic3ab7d60e4ac12b767fe70bef97b327545a86e74  https://review.openstack.org/52343214:58
bauzasgiven we don't support traits yet, we only ask for the operator to provide *one* type14:58
efriedSo a given trait is in fact overloading more than one aspect of the VGPU's characteristics.14:58
bauzaswell14:59
efriedIn other words, by saying I need a VGPU of type X, I'm also implicitly stating that I'm going to get two display heads (or whatever)14:59
bauzasthat is a correct assumption to me14:59
*** salv-orlando has quit IRC14:59
efriedOkay.  Then if that correlation always holds true14:59
*** yamamoto has joined #openstack-nova15:00
efriedthat is, a given VGPU type always maps to a given number of display heads15:00
jianghuaw_the plan is to associate traits like display_solutions; supported features after we support traits.15:00
bauzasefried: see the spec15:00
bauzasthere are some examples15:00
efriedthen you shouldn't have inventory for the display heads.15:00
bauzasI agree15:00
bauzasif that's correlated15:00
*** awaugama has joined #openstack-nova15:00
efriedAnd there's even no need for extra traits - though those could be included and it wouldn't hurt anything.15:01
*** abhishekk has quit IRC15:01
bauzastbh, I haven't thought that much on that problem, since libvirt doesn't return the heads :p15:01
bauzas(yet)15:01
jianghuaw_efried, the display heads is one factor can be used to determine a vGPU type.15:02
efriedjianghuaw_ Ah, okay, if you want to be able to go in the other direction, then it makes sense.15:02
*** hongbin has joined #openstack-nova15:02
efriedjianghuaw_ I can imagine that you don't want to be getting particular about VGPU types; rather, you want to be enumerating capabilities of each type, so that the scheduler could conceivably pick one of any number of types as long as they fit the capabilities you request.15:03
mriedemgibi: replied in https://review.openstack.org/#/c/523353/ and explained the issue15:03
jianghuaw_But the possible value is a continuous number which makes it more like quantitative.15:03
*** smatzek has joined #openstack-nova15:03
*** udesale has quit IRC15:03
gibimriedem: looking15:03
openstackgerritMatt Riedemann proposed openstack/nova stable/newton: Refined fix for validating image on rebuild  https://review.openstack.org/52343415:04
mriedeminstance actions/events are mythical beasts15:04
mriedemeasily broken15:04
mriedemrarely tested15:05
*** damien_r has quit IRC15:05
jianghuaw_efried, yes. That's also the result of the discussion with jaypipes to use capabilities instead of specifying vGPU type.15:05
efriedjianghuaw_ But a small number of discrete possible values15:05
mriedemdansmith: i've got those backports all up now https://review.openstack.org/#/q/I1a46ef1503be2febcd20f4594f44344d0552544615:05
efriedjianghuaw_ Like 1, 2, 4, 815:05
jianghuaw_efried, indeed.15:05
gibimriedem: thanks, I15:05
gibimriedem: thanks, I'm +2 now15:05
*** damien_r has joined #openstack-nova15:06
jianghuaw_efried, it looks like you agree with me to make it as traits. right?15:06
efriedjianghuaw_ With the caveat that I don't fully understand the different ways you can request/configure these things, yes, I believe I agree.15:06
mriedemsdague: could use some review on https://review.openstack.org/#/c/521391/ which is a fix for a regression introduced by a recent cve fix, so it's going to have to be backported through to newton - there is a regression test patch underneath it15:07
*** liusheng has quit IRC15:07
openstackgerritjiangpf proposed openstack/nova master: Encode libvirt domain XML in UTF-8  https://review.openstack.org/52216115:07
efriedjianghuaw_ A given VGPU type will only ever have *one* of the traits (e.g. SINGLE_DISPLAY_HEAD_CAPABLE, DUAL_DISPLAY_HEAD_CAPABLE, QUAD_DISPLAY_HEAD_CAPABLE) right?15:07
mriedemsdague: actually that regression test might be busted now, checking15:08
jianghuaw_efried, at the moment I see the possible number is 1, 2, 4, 815:08
efriedjianghuaw_ Okay; the question remains: a given VGPU type will *always* and *only* consume *one* of those numbers of display heads?15:09
jianghuaw_correct.15:10
*** marst has joined #openstack-nova15:10
efriedThen yes, I think it's appropriate *not* to inventory display heads separately, and I think it's okay to have those be traits.15:10
*** yamamoto has quit IRC15:10
dansmithmriedem: ack15:11
efriedNow if I want a VGPU with four display heads, I request resources=VGPU:1&required=QUAD_DISPLAY_HEAD_CAPABLE15:11
jianghuaw_efried, yeah. That's what I was thinking:-)15:11
efriedjaypipes Does this seem sane to you ^^15:12
jaypipesgimme a minute, folks. trying to finish rebasing n-r-p15:12
jaypipesok, final tests running now... lemme read back, sorry15:13
efriedjaypipes Summary: A given VGPU type will *always* have a certain number of display heads.  So display heads as traits (SINGLE_DISPLAY_HEAD_CAPABLE, DUAL_DISPLAY_HEAD_CAPABLE, etc.) and a RP of VGPUs (presumably the pGPU) would only ever have one of those traits.15:13
jianghuaw_efried, thanks for the summary.15:13
jaypipesefried: if the display head is *consumed* by a request, it needs to be a resource class, not a trait.15:14
efriedjaypipes The issue is that the number of display heads are always correlated exactly with the VGPU type.15:15
jianghuaw_jaypipes, the display heads will always be consumed automatically when requesting VGPU.15:15
jaypipesefried: I don't see any issue with that. (plus, I guarantee you nvidia and intel will end up changing that in the future. it's what they do. ALL THE TIME.15:15
alex_xumriedem: yea, you are right, without 'migrate' key, it won't route to that action15:16
*** mdnadeem has quit IRC15:16
bauzasjaypipes: the problem here is that display heads are correlated by the number of VGPUs and their types15:16
bauzasoh man15:16
jaypipesbauzas: I don't see a problem?15:16
jaypipesbauzas: set the amount of VGPU and display head resources in the flavor correctly, no?15:16
*** moshele has quit IRC15:16
bauzasjaypipes: once we have traits, it's doable15:16
jaypipesbauzas: traits have nothing to do with this.15:17
bauzasjaypipes: for the moment, the user has no clue about which type he will get15:17
alex_xuefried: you mean you are working on the two testcases in this patch https://review.openstack.org/498737 ?15:17
bauzashence how many heads he could get15:17
efriedalex_xu Yes15:17
jaypipesbauzas: it's not the user. it's the deployer/admin that needs to set shit up.15:17
alex_xuefried: cool, thanks15:17
efriedalex_xu The first one is ported over, and passing.  Working on the second one...15:17
bauzasjaypipes: I don't disagree15:17
bauzasjaypipes: the operator provides which supported types the compute should provide15:18
bauzasso the VGPUs will depend on thaty15:18
bauzasand the heads15:18
alex_xuefried: I ported the first one on Monday, but interupt by other works... so nvm, thanks for porting those15:18
bauzasbut then, if the user wants a specific GRID-K5000, then the operator will set the flavor with a trait15:19
jaypipesbauzas: correct. if the virt driver (Xen, libvirt, whatevs) wants to do some fancy-pants discovery on startup of nova-compute and ensure that inventory counts are proper for the types of GPUs found on the host, cool with me. But it's the deployer's responsibility to create flavors that make sense for these related resources.15:19
bauzasanyway, I need to go15:19
bauzasdisappearing for 20 mins15:19
bauzas-ish15:20
*** clayton has quit IRC15:20
jianghuaw_jaypipes, as the display heads are optional (we have to allow that as the vGPU may not support display heads). If the flavor has resources=VGPU:1; then placement may return resource providers which have display heads. In that case, the display heads are consumed automatically.15:20
jianghuaw_That's the problem.15:20
bauzasjaypipes: one last thing, libvirt doesn't support display heads yet15:20
bauzas:p15:20
efriedjaypipes Here's the counterexample: One pGPU provides VGPU types that always allocate four display heads, so it exposes inventory of VGPU:2,DISPLAY_HEAD:8.  Some other pGPU always allocates two display heads, so it exposes inventory of VGPU:2,DISPLAY_HEAD:4.  In my flavor, I request VGPU:1,DISPLAY_HEAD:2.  Scheduler happily schedules me to that first one, and allocates usage of 2 display heads.  But we actually consume four.15:20
bauzas(so I'm not fully on track with that)15:20
jaypipesjianghuaw_: no, nothing should be "consumed automatically". that's the problem. :)15:20
dansmithmriedem: are you not going to +2 this? https://review.openstack.org/#/c/521662/15:21
jianghuaw_jaypipes, agreed. but the problem is how to avoid that case.15:21
*** artom has quit IRC15:21
*** clayton has joined #openstack-nova15:21
jaypipesefried: that is what min_unit, max_unit, and step_size are for.15:21
efriedHum, yeah, I guess that would work.15:22
efriedBut15:22
efriedWe still have the problem of when I request VGPU:1 and no display heads.15:22
jianghuaw_jaypipes, but how about if flavor only has resources=VGPU:1?15:22
efriedjinx15:22
jianghuaw_it doesn't request display heads.15:22
efriedScheduler will happily schedule me to either one of those guys above, and not create a usage for display heads, even though they got consumed.15:23
jianghuaw_so it consumes a vGPU. But we know any consuming vGPU result also result the available display heads be reduced also.15:23
efried(Because there's another RP somewhere whose vGPUs don't have display heads, and that's where I meant to go.)15:23
jianghuaw_efried, ack15:24
efried(Or actually I didn't care whether I went there or not; but if I got onto the display-heads-havin' RPs, I have to consume its display heads)15:24
*** artom has joined #openstack-nova15:25
jaypipesjianghuaw_, efried: this is the same problem that stephenfin and snikitin's "PCI affinity scheduling policies" thing is about...15:25
*** gbarros has joined #openstack-nova15:25
jianghuaw_jaypipes, is there solution for that problem already?15:26
stephenfinpretty much, yeah15:26
jaypipesjianghuaw_, efried: I think in that scenario, I would just say the flavor must always request a display head, regardless of if the user ends up using one.15:26
openstackgerritMerged openstack/nova master: Update document related to host aggregate  https://review.openstack.org/51449915:26
efriedjaypipes That would make it impossible to use vGPUs that don't have display heads.15:26
stephenfinjianghuaw_: https://review.openstack.org/#/c/390520/15:27
jaypipesjianghuaw_: the "solution" is very specific to PCI, involves (yet another) configuration option/metadata key/value pair, and generally is going to make long-term porting of the PCIPassthroughFilter impossible. but yeah...15:27
jianghuaw_jaypipes, so making display heads as mandatory as long as it request vGPU?15:27
jaypipesjianghuaw_: IFF the compute hosts' pGPUs do not have the ability to only serve up a vGPU without a display head.15:27
jianghuaw_stephenfin, jaypipes thanks. looking at the patch.15:27
*** gbarros has quit IRC15:28
artommriedem, oh, you've proposed the upstream rebuild CVE backports, thanks :)15:28
*** jmlowe has joined #openstack-nova15:28
*** janki has joined #openstack-nova15:28
*** gbarros has joined #openstack-nova15:29
jianghuaw_jaypipes, but we do have cases where vGPUs don't support a display head. which means no inventory for display heads.15:29
jaypipesjianghuaw_: bottom line for me on this is that I do not think this use case is particularly high priority, and given that there is a solution of "just have the flavor always request a display head (or >1 display head) if the underlying hardware always requires a display head, I don't want to add in any sort of trait hack here.15:29
*** jmlowe has quit IRC15:30
openstackgerritMerged openstack/nova master: Add instance action record for attach/detach/swap volumes  https://review.openstack.org/51720515:32
jaypipesjianghuaw_: in that scenario, what about just attaching a custom trait CUSTOM_NO_DISPLAY_HEAD to the flavor that doesn't want a display head and attach the same trait to the resource providers representing those pGPUs?15:32
jaypipesjianghuaw_: that way, we're not using any standard traits for things that are quantitative and you can still have the scheduler and placement service do what they're good at without any additional hacks.15:32
jaypipesjianghuaw_: in that way, all the requests for vGPU with no need for display head support will go to those hosts and all other requests for vGPUs *with* display head support will go to the other hosts that have inventory of both VGPU and VGPU_DISPLAY_HEAD15:34
jianghuaw_jaypipes, hmmm. It should work.15:34
*** sapd__ has quit IRC15:34
*** sapd_ has joined #openstack-nova15:34
jaypipesjianghuaw_: I'm fine using custom traits for something like that. it's just that I am strongly against using standard traits for things that are, in essence, quantities of some class of resource (like the proposed SINGLE_DISPLAY_HEAD_CAPABLE thing above)15:34
jianghuaw_jaypipes, another option is to making display head default as 1. If there is no display heads return from hypervisor.15:35
jaypipesjianghuaw_: you mean "fake out" the inventory counts for VGPU_DISPLAY_HEADS for these hosts?15:35
jianghuaw_jaypipes, yes.15:36
jaypipesjianghuaw_: nah, I'd prefer not to do that. otherwise, we'll go down the route of cdent and his "infinite inventories" :P15:36
* cdent shakes tiny fist15:37
jianghuaw_jaypipes, ok. Let's forget it:-)15:37
cdentall my best ideas, like sands in the hourglass15:37
jaypipeshehe15:38
*** gbarros has quit IRC15:38
jaypipesjianghuaw_: no, in all seriousness, I think the custom trait CUSTOM_NO_DISPLAY_HEAD is the right approach to solve that remaining use case.15:38
*** slaweq has joined #openstack-nova15:38
*** gbarros has joined #openstack-nova15:39
jianghuaw_jaypipes, I think the above approaching by using custom traits actually strongly depends on the administrators to do right thing to set the flavors. I means it make break thing if someone wrongly created a flavor only request VGPU and don't have CUSTOM_NO_DISPLAY_HEAD.15:40
*** suresh12 has joined #openstack-nova15:41
jaypipesjianghuaw_: that's a tradeoff I'm willing to make.15:41
jianghuaw_jaypipes, got it. So we should record that in the document.15:42
*** slaweq has quit IRC15:43
jianghuaw_let's go with that approach.15:43
jaypipesjianghuaw_: yeah. I think a "how to use vGPUs with OpenStack" article/tutorial/reference would be extremely useful.15:43
*** dklyle has joined #openstack-nova15:43
jianghuaw_jaypipes, thanks very much.j15:43
jaypipesjianghuaw_: any time :)15:43
*** yamahata__ has joined #openstack-nova15:44
jianghuaw_efried, bauzas: thank you also for the discussion and advices.15:44
efriedjianghuaw_ Cool, good luck.15:45
*** gouthamr has joined #openstack-nova15:45
*** suresh12 has quit IRC15:45
*** isq_ has quit IRC15:45
*** slaweq has joined #openstack-nova15:45
openstackgerritMerged openstack/nova master: Don't overwrite binding-profile  https://review.openstack.org/51906615:45
jianghuaw_efried, :-)15:46
efriedalex_xu FYI, both of those tests pass on top of the stack; and I don't think we actually have other tests that match them exactly; and even if we did, I'm not opposed to having some duplication there.15:46
*** yamamoto has joined #openstack-nova15:46
efriedalex_xu Not sure exactly how/where to propose the code, though.15:46
*** ijw has joined #openstack-nova15:46
*** david-lyle has quit IRC15:46
efriedalex_xu I guess we should propose the code under https://review.openstack.org/#/c/498737/ and abandon https://review.openstack.org/#/c/480379/15:48
efriedalex_xu But I'm not sure which patch to declare as having fixed bug #173107215:49
openstackbug 1731072 in OpenStack Compute (nova) "AllocationCandidates.get_by_filters returns garbage with multiple aggregates" [Medium,Confirmed] https://launchpad.net/bugs/173107215:49
efriedoh, I guess that bug isn't fully fixed anyway, so we can just leave that alone.15:49
efriedOkay, I've answered all my questions :)15:49
*** nicolasbock has joined #openstack-nova15:49
efriedjaypipes mriedem FYI ^^15:49
*** slaweq has quit IRC15:50
efriedDangit, wrong bug.  Should have been bug #1702420 -- which is indeed fixed now.15:50
openstackbug 1702420 in OpenStack Compute (nova) "The AllocationCandidates.get_by_filters returned wrong combination of AllocationRequests" [High,In progress] https://launchpad.net/bugs/1702420 - Assigned to Alex Xu (xuhj)15:50
*** ijw has quit IRC15:50
jaypipesefried: now as in now or now as in "will be shortly once some patch is merged"?15:51
jianghuaw_bauzas, Please check the above discussion after you come back. Hope you also agree with the approach: 1. always requesting display heads for VGPUs which have display heads; 2. use custom traits e.g. CUSTOM_NO_DISPLAY_HEAD for those cases where display head is not supported.15:51
efriedjaypipes The latter.  I'm rebasing https://review.openstack.org/#/c/498737/ on top of the series formerly known as The Big Refactor.15:52
*** yamamoto has quit IRC15:52
*** gbarros has quit IRC15:52
jianghuaw_bauzas, and don't forget to review my vGPU patches. Thanks:-)15:52
jaypipesefried: gotcha.15:52
jaypipesefried: I'm focused on n-r-p right now.15:52
efriedjaypipes Oh, actually, since the refactors are merged at this point, it may be fixed at master.  I can check that quick...15:53
*** gbarros has joined #openstack-nova15:53
*** masuberu has joined #openstack-nova16:01
*** lyan has quit IRC16:01
*** lyan has joined #openstack-nova16:02
*** rmart04 has quit IRC16:04
*** masber has quit IRC16:05
efriedjaypipes Well, my port relies on some of the test helpers, so for that reason alone it won't work until later in the series.  IMO not worth the trouble of retrofitting the tests to pre-helper and then having to rebase.16:05
*** maciejjozefczyk has joined #openstack-nova16:05
jaypipesefried: ack16:05
openstackgerritEric Fried proposed openstack/nova master: placement: func tests for multiple shared RPs  https://review.openstack.org/49873716:06
efriedjaypipes alex_xu ^16:06
*** lpetrut has quit IRC16:06
*** lpetrut has joined #openstack-nova16:06
*** sbezverk has joined #openstack-nova16:07
efriedalex_xu FYI I closed https://bugs.launchpad.net/nova/+bug/170242016:07
openstackLaunchpad bug 1702420 in OpenStack Compute (nova) "The AllocationCandidates.get_by_filters returned wrong combination of AllocationRequests" [High,Fix released] - Assigned to Alex Xu (xuhj)16:07
*** masuberu has quit IRC16:08
*** masuberu has joined #openstack-nova16:08
*** imacdonn has joined #openstack-nova16:11
*** eharney has joined #openstack-nova16:14
*** josecastroleon has quit IRC16:15
*** shaner has quit IRC16:16
openstackgerritBalazs Gibizer proposed openstack/nova master: Deduplicate instance.create notification samples  https://review.openstack.org/52345616:19
*** tidwellr has joined #openstack-nova16:23
*** vladikr has quit IRC16:24
*** lpetrut has quit IRC16:28
*** gbarros has quit IRC16:28
*** salv-orlando has joined #openstack-nova16:28
*** salv-orl_ has quit IRC16:31
*** shaner has joined #openstack-nova16:31
*** yamamoto has joined #openstack-nova16:31
*** tidwellr has quit IRC16:32
*** tidwellr has joined #openstack-nova16:35
*** Oku_OS is now known as Oku_OS-away16:35
*** yamamoto has quit IRC16:36
*** jmlowe has joined #openstack-nova16:38
Anticimexhello, operator here16:40
Anticimexwas there ever progress on https://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/detach-boot-volume.html since M?16:40
Anticimexwe just ran into that as a little nasty bug that made us sad16:40
cdentmriedem: is there a reasonable way to do a test for this or is tempest sufficient? tempest happily blows up when it is wrong (see previous patchsets in the series): https://review.openstack.org/#/c/523403/16:41
*** salv-orlando has quit IRC16:42
*** salv-orlando has joined #openstack-nova16:42
*** lpetrut has joined #openstack-nova16:43
*** slaweq has joined #openstack-nova16:43
jaypipesAnticimex: what precisely is the use case for attaching/detaching a boot volume? I've read that spec and each use case just describes a poorly-architected legacy application that relies on the infrastructure to do all of its disaster recovery, backup, and HA.16:45
*** slaweq_ has joined #openstack-nova16:45
*** salv-orlando has quit IRC16:46
*** kenperkins has joined #openstack-nova16:47
*** slaweq has quit IRC16:48
*** AlexeyAbashkin has quit IRC16:49
*** suresh12 has joined #openstack-nova16:52
mriedemcdent: i'm lost re https://review.openstack.org/#/c/523403/16:55
mriedemwhich other patch in the series?16:55
cdentsorry, not series, same change: ps1 and p2 have failures (but I may have knocked them out before they got a chance to report)16:56
*** chyka has joined #openstack-nova16:56
cdentmriedem: my words are a bit broken today, too many of them16:56
cdentmriedem: the short form of my question is: since that didn’t have test coverage (besides tempest) before, is it okay without additional tests?16:57
*** damien_r has quit IRC16:59
mriedemmight not be bad to have a simple test that mocks out filter_factory and uses autospec to make sure what we're passing to that method is actually in the library16:59
*** damien_r has joined #openstack-nova16:59
efriedjaypipes Series starting at https://review.openstack.org/#/c/517119/ needs a rebase.  Want me to hit it?  Or mebbe we wait until some more stuff merges?17:00
jaypipesefried: wait on that.17:00
efriedjaypipes K.  Need to address gibi's -1 too.17:00
jaypipesefried: yeah.17:01
jaypipesefried: still running tests on the n-r-p series... and I'll need to rebase and bump the microversion yet again once cdent's latest patch merges.17:01
efriedjaypipes Right.  Is there anywhere I can actually be useful at this point?17:01
jaypipesefried: can you bake cookies (chocolate chip) and send them my way? :)17:02
jaypipesefried: no, in all seriousness, reviewing edleafe's series on alternate hosts if you haven't yet will be good.17:02
efriedjaypipes Sorry, my wife is the baker.  She's out til late tonight.  I make a mean curry, though.17:03
efriedjaypipes Okay, I've been deliberately avoiding that one for lack of context, but I guess I'll have to dig in at some point.17:03
jaypipesefried: ooh, I love curry.17:03
jaypipesefried: doesn't ship well, though.17:03
Anticimexjaypipes: resize boot volume, ie make it larger17:03
jaypipesefried: also ask dansmith to point you at patches he'd like reeviewed.17:04
*** ragiman has quit IRC17:04
efrieddansmith ^17:04
dansmithwe're waiting on me for all my patches currently I think17:04
jaypipesAnticimex: just stop the instance, resize the volume, and boot.17:04
*** liusheng has joined #openstack-nova17:04
efriedk, just let me know.17:04
edleafejaypipes: will have patch addressing your concerns on https://review.openstack.org/#/c/510159/ soon17:04
Anticimexjaypipes: can't while it's attached17:05
Anticimex.oO though that may have been fixed in ocata or something for ceph iirc17:05
jaypipesAnticimex: stop the instance, resize the volume, and start the instance.17:05
jaypipesedleafe: coo, thanks man17:05
jaypipesAnticimex: terminate the instance, not stop it.17:06
jaypipesAnticimex: I mean, if it's boot from volume, you're not losing anything.17:06
mriedemyou can resize an attached volume starting in pike17:06
mriedemfor libvirt + iscsi/fc17:06
Anticimexjaypipes: no only cumbersome to retype all things, but that's indeed the workaround17:06
jaypipesAnticimex: unless of course, it's a legacy application that relies on a) IP addresses not changing, b) infrastructure for doing disaster recovery, c) infrastructure for doing HA, etc17:07
Anticimexbut resize while attached (& stopped) is ok here17:07
mriedemhttps://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/nova-support-attached-volume-extend.html17:07
jaypipesmriedem: bfv though?17:07
mriedemjaypipes: not sure about bfv17:07
Anticimexmriedem: ack17:07
jaypipesright... it's always the problem with bfv :)17:07
mriedemthe tempest test is not bfv17:07
cdentefried: I’d totally dig on some curry please17:08
*** moshele has joined #openstack-nova17:08
* efried starts a list17:08
*** sahid has quit IRC17:09
*** ijw has joined #openstack-nova17:09
Anticimexjaypipes: it is however legacy workload indeed17:10
*** penick has joined #openstack-nova17:10
Anticimexbut that wasn't the problem, the problem was the workflow for the resize (grow).  but if this works in pike or queens if i got mriedem right, i guess that's always something17:11
jaypipesAnticimex: by legacy, I'm referring to an application that doesn't have the ability to separate its application state from the persistent user data. In other words, an application that can be inserted in an image/ephemeral boot disk and have its user data written to a persistent volume.17:11
*** moshele has quit IRC17:12
Anticimexyeah, it's not capable of that17:12
jaypipesAnticimex: I'd try it out if you can. Hopefully that would be a workaround solution until you can convince the application authors to provide a way to configure data to be written to a filesystem/DB separate from the boot partition.17:13
jaypipesAnticimex: i.e. not on C:\ in a Windows image. ;)17:13
Anticimexit would be nice yeah but not really applicable17:13
Anticimexsince it is a ton of C:'s coming in from a customers deprecated local dc17:14
Anticimex:)17:14
jaypipesya17:14
jaypipesI hear ya.17:14
Anticimex"we'll make it work"17:14
jaypipes:) said the sales guy.17:14
Anticimexjust have those +2 coming ;-)17:14
Anticimexhehe yeah17:14
jaypipes:)17:14
Anticimexthx jay, afk17:14
jaypipesciao17:15
*** jmlowe has quit IRC17:15
*** yamamoto has joined #openstack-nova17:16
*** shaner has quit IRC17:19
*** suresh12 has quit IRC17:20
*** cdent has quit IRC17:20
*** shaner has joined #openstack-nova17:21
*** cdent has joined #openstack-nova17:21
*** yamamoto has quit IRC17:21
*** suresh12 has joined #openstack-nova17:21
*** gbarros has joined #openstack-nova17:25
*** suresh12 has quit IRC17:26
*** tidwellr has quit IRC17:29
*** damien_r has quit IRC17:34
*** Alex_Staf has quit IRC17:37
*** Apoorva has joined #openstack-nova17:40
*** Apoorva has quit IRC17:40
*** Apoorva has joined #openstack-nova17:41
*** gbarros has quit IRC17:41
*** fragatina has quit IRC17:43
*** tidwellr has joined #openstack-nova17:43
*** gbarros has joined #openstack-nova17:44
*** lpetrut has quit IRC17:45
*** yamahata has quit IRC17:47
*** pprokop has joined #openstack-nova17:49
openstackgerritMatt Riedemann proposed openstack/nova master: Add regression test for rebuilding a volume-backed server  https://review.openstack.org/52120017:50
openstackgerritMatt Riedemann proposed openstack/nova master: Get original image_id from volume for volume-backed instance rebuild  https://review.openstack.org/52139117:50
openstackgerritMatt Riedemann proposed openstack/nova master: Fail fast if changing image on a volume-backed server rebuild  https://review.openstack.org/52066017:50
mriedemdansmith: i had to update the regression test at the bottom of this series because of the new RUN_ON_REBUILD=False for the ComputeFilter ^ using the super fun IsolatedHostsFilter now17:50
*** dtantsur is now known as dtantsur|afk17:50
*** sambetts is now known as sambetts|afk17:50
mriedemthe bottom 2 changes in that series are linked to https://review.openstack.org/#/c/521186/17:50
mriedemlinked in that the cve fix introduced that regression17:51
*** burt has joined #openstack-nova17:51
mriedemKevin_Zheng: did i answer your -1 on https://review.openstack.org/#/c/520660/ ?17:51
*** burt is now known as Guest9458017:51
mriedemmelwitt: i think this simple ironic bp patch is ready to go https://review.openstack.org/#/c/503088/17:51
*** Guest94580 has quit IRC17:52
mriedemsdague: this is an easy one for the ksa adapter stuff https://review.openstack.org/#/c/507693/17:52
openstackgerritEd Leafe proposed openstack/nova master: Add Selection objects  https://review.openstack.org/49923917:52
openstackgerritEd Leafe proposed openstack/nova master: Refactor the code to check for sufficient hosts  https://review.openstack.org/52024217:52
openstackgerritEd Leafe proposed openstack/nova master: Return Selection objects from the scheduler driver  https://review.openstack.org/49585417:52
openstackgerritEd Leafe proposed openstack/nova master: Modify select_destinations() to return objects and alts  https://review.openstack.org/51015917:52
openstackgerritEd Leafe proposed openstack/nova master: Change RPC for select_destinations()  https://review.openstack.org/51670717:52
openstackgerritEd Leafe proposed openstack/nova master: Move the claim_resources method to scheduler utils  https://review.openstack.org/51135717:52
openstackgerritEd Leafe proposed openstack/nova master: Make conductor pass and use host_lists  https://review.openstack.org/51135817:52
melwittmriedem: ack, will look17:52
openstackgerritEd Leafe proposed openstack/nova master: Move the to_dict() method to the Selection object  https://review.openstack.org/52349217:52
mriedemmelwitt: it'd also be good if you could help review ed's alternate hosts series above17:52
mriedemsince that's related to cells v2 stuff17:52
melwittsure thing17:53
mriedemthanks17:53
*** pcaruana has quit IRC17:53
*** moshele has joined #openstack-nova17:55
*** thorst has quit IRC17:57
*** thorst has joined #openstack-nova17:58
*** jamesdenton has joined #openstack-nova18:00
*** moshele has quit IRC18:01
*** yamamoto has joined #openstack-nova18:01
*** josecastroleon has joined #openstack-nova18:02
*** thorst has quit IRC18:02
*** derekh has quit IRC18:04
*** jmlowe has joined #openstack-nova18:05
*** yamamoto has quit IRC18:06
openstackgerritEd Leafe proposed openstack/nova master: Move the to_dict() method to the Selection object  https://review.openstack.org/52349218:06
openstackgerritEd Leafe proposed openstack/nova master: Modify select_destinations() to return objects and alts  https://review.openstack.org/51015918:06
openstackgerritEd Leafe proposed openstack/nova master: Change RPC for select_destinations()  https://review.openstack.org/51670718:06
openstackgerritEd Leafe proposed openstack/nova master: Move the claim_resources method to scheduler utils  https://review.openstack.org/51135718:06
openstackgerritEd Leafe proposed openstack/nova master: Make conductor pass and use host_lists  https://review.openstack.org/51135818:06
*** Swami has joined #openstack-nova18:09
*** thorst has joined #openstack-nova18:10
*** suresh12 has joined #openstack-nova18:11
*** ralonsoh has quit IRC18:11
*** gbarros has quit IRC18:11
openstackgerritMatt Riedemann proposed openstack/nova master: Fix NoneType error when [service_user] is misconfigured  https://review.openstack.org/52194718:13
openstackgerritEric Fried proposed openstack/nova master: Fix NoneType error when [service_user] is misconfigured  https://review.openstack.org/52194718:14
efriedah, seriously?18:14
*** thorst has quit IRC18:14
efriedmriedem ^18:14
mriedemwe are sympatico18:16
efriedmriedem Want me to unwind mine?18:16
mriedemsure18:16
jaypipesefried: FYI, still running tests on the n-r-p series after rebasing. (had to run tests for all 12 patches separately of course...)18:16
efriedjaypipes Of course.18:16
*** yamamoto has joined #openstack-nova18:18
*** yamamoto has quit IRC18:18
*** fragatina has joined #openstack-nova18:19
efriedmriedem Is there an easy way to revert to a prior patch set?18:20
jaypipesefried: rm -rf /18:20
jaypipes:P18:21
*** gbarros has joined #openstack-nova18:21
mriedemefried: not sure of an easy way18:21
clarkbefried: git review -d 123456,2 && git commit --amend # make some change to the commit message because gerrit (though new gerrit may not have this restriction any longer) && git review18:22
efriedclarkb Cool, thanks.18:22
openstackgerritEric Fried proposed openstack/nova master: Fix NoneType error when [service_user] is misconfigured  https://review.openstack.org/52194718:22
clarkbgerrit in the past has refused to accept old identical patchsets, I think ti may not refuse those anymore so you don't need to make changes but I haven't tested it18:22
melwittcool, I learned a thing. I wondered if there was a way to pull a specific rev using git review -d18:22
efriedclarkb No, it did refuse.18:22
*** yamahata has joined #openstack-nova18:23
efriedTrivial change to the commit message worked.  Thanks for that.18:23
*** lucasagomes is now known as lucas-afk18:23
efriedmriedem done, sorry about that.18:23
*** jmlowe has quit IRC18:25
*** penick has quit IRC18:25
*** liverpooler has quit IRC18:25
mriedemnp18:27
*** stvnoyes has quit IRC18:27
*** liverpooler has joined #openstack-nova18:28
*** jmlowe has joined #openstack-nova18:28
melwittmriedem: if we have a change that introduces a new config option but it's not useful until patch 3 in the series, is it okay to delay the reno until patch 3? example: https://review.openstack.org/#/c/345397/26/nova/conf/vnc.py18:30
melwittI'm thinking that makes sense (to reno the conf option when the feature represented in the series fully lands)18:34
*** penick has joined #openstack-nova18:34
*** thorst has joined #openstack-nova18:34
*** moshele has joined #openstack-nova18:35
*** stvnoyes has joined #openstack-nova18:35
*** AlexeyAbashkin has joined #openstack-nova18:35
*** josecastroleon has quit IRC18:36
*** thorst has quit IRC18:37
*** thorst has joined #openstack-nova18:38
*** AlexeyAbashkin has quit IRC18:40
*** adisky_ has quit IRC18:43
melwittwould anyone be willing to review this libvirt driver bug fix to save the guest XML after a volume update? has one +2 https://review.openstack.org/#/c/49898318:46
zigomelwitt: Hi ! I believe I know how to write the fix for my O_DIRECT issue! :)18:47
zigomelwitt: There's even a facility in nova to actually test for O_DIRECT support, but it's simply not used ... :P18:48
melwittzigo: I've seen the test for O_DIRECT support in the driver but wasn't sure how to apply it in the fail case you hit. if you could propose a patch, that would be sweet18:49
zigoPlease let me write it, that'd be my first patch in Nova, and that will make me very proud !!! :)18:49
melwittzigo: yup, have at it. ping me whenever you post it and I'll review it18:49
zigoCheers.18:49
* zigo is cloning the tree, and it's taking forever with my slow far away mountains ADSL...18:50
*** penick has quit IRC18:52
*** suresh12 has quit IRC18:53
*** suresh12 has joined #openstack-nova18:54
*** AlexeyAbashkin has joined #openstack-nova18:56
openstackgerritMerged openstack/nova master: Implement query param schema for sec group APIs  https://review.openstack.org/52135318:56
openstackgerritMerged openstack/nova master: Add instance action record for lock/unlock instances  https://review.openstack.org/52335318:57
openstackgerritMerged openstack/nova master: Add regression test for rebuild with new image doubling allocations  https://review.openstack.org/52115318:57
mriedemmelwitt: if the config option isn't used until later in the series, why isn't it just introduced later in the series, when it's used?18:57
*** cdent has quit IRC18:57
melwittmriedem: I think it's because in the series, patch 1 adds a base class (that uses the config option to iterate through choices), patch 2 adds one auth implementation, patch 3 adds another (and the final) auth implementation, each of which is one of the config option choices18:59
zigomelwitt: How can I import nova.virt.libvirt.driver.LibvirtDriver.disk_cachemode() ? It's not ok to just import it as it's a driver, right?19:00
mriedemsdague: you might have input here https://bugs.launchpad.net/nova/+bug/173469819:00
openstackLaunchpad bug 1734698 in OpenStack Compute (nova) "Squash database patches" [Undecided,Invalid]19:00
*** penick has joined #openstack-nova19:01
*** moshele has quit IRC19:01
melwittmriedem: er, sorry, patch 2 adds an impl, patch 3 does something else. let me look deeper into this first19:01
openstackgerritMerged openstack/nova master: [placement] POST /allocations to set allocations for >1 consumers  https://review.openstack.org/50007319:01
openstackgerritMerged openstack/nova master: [placement] Fix GET PUT /allocations nits  https://review.openstack.org/52340119:01
melwittzigo: where do you want to import it? just thinking ahead on whether it might need to be moved to utils to do what you want to do19:03
*** AlexeyAbashkin has quit IRC19:04
melwittbecause we don't want to import any driver stuff into imagebackend or images19:05
efriedjaypipes Here's a scenario: One or more sharing RPs (MISC_SHARES_VIA_AGGREGATE) in an aggregate.  But that aggregate does *not* contain any non-sharing RPs.  Would it be correct to say that we should *never* get allocation candidates including any RP in that aggregate?19:05
*** janki has quit IRC19:05
zigomelwitt: In nova/virt/images.py there's def _convert_image(source, dest, in_format, out_format, run_as_root):. There, there is cmd = ('qemu-img', 'convert', '-t', 'none', '-O', out_format).19:08
zigo'none' needs to be replaced by a call to that function.19:08
openstackgerritMerged openstack/nova master: [placement] Clean up TODOs in allocations.yaml gabbit  https://review.openstack.org/51305719:09
openstackgerritMerged openstack/nova master: Update the documentation links  https://review.openstack.org/52328819:09
jaypipesefried: wouldn't it depend on the request? I mean, if the request is only for resources that are being shared by those providers, then why wouldn't those providers be returned in allocation candidates? (note: the scheduler would throw those providers away since they wouldn't match a compute node UUID, but that's not the point, right?)19:10
efriedjaypipes That's indeed not the point.  Hum, I guess it's legit...19:11
melwittzigo: ah, gotcha. hmm ... yeah, so virt/images.py is not *supposed* to be libvirt-specific but it obviously is. and as you can tell from the layout, we've got separation between the driver and image related code. so we wouldn't want to import from the libvirt driver there. so I'm thinking what's the least ugly way we could do this ...19:12
efriedjaypipes Is _get_all_with_shared supposed to return only non-sharing RPs?19:12
jaypipesefried: it was supposed to, yeah. but alex_xu (and you, right?) pointed out that wasn't actually the case.19:13
*** rtjure has joined #openstack-nova19:13
jaypipesefried: and upon further thought, decided to leave it as it was, returning both sharing and non-sharing.19:13
*** sridharg has quit IRC19:13
jaypipesefried: and leave it up to callers to choose to ignore sharing-only allocation requests.19:13
efriedjaypipes Hell, I don't know anymore.19:15
mriedemdansmith: this is a fun bug https://bugs.launchpad.net/nova/+bug/173450419:15
openstackLaunchpad bug 1734504 in OpenStack Compute (nova) "User can't know which flavor used for resize by the result of "nova migration-list"" [Low,Triaged]19:15
dansmithhmm, doesn't look fun19:16
mriedemapparently we leak internal flavor primary keys out of the os-migrations REST API19:16
mriedemwhich, whatever, we leak them out, big whoop, but they have no meaning at all to an end user since they aren't the flavorid19:16
mriedemgood times19:16
mriedemand the columns on the migrations table that stores those ids is an integer column so we can't store string flavorid in there anyway :)19:17
efriedjaypipes Is there any meaning to MISC_SHARES_VIA_AGGREGATE if that's the case?19:17
*** salv-orlando has joined #openstack-nova19:17
efriedjaypipes What semantic does it provide beyond just being associated with a given aggregate?19:17
jaypipesefried: it says "I share my inventory with any provider in any aggregate I'm associated with"19:18
*** yamamoto has joined #openstack-nova19:18
*** rtjure has quit IRC19:18
mriedemas far as i can tell, there is no reason that we even store the flavor.id on the migration record *except* to return it out of the API19:18
mriedemnothing else in the code depends on it19:19
dansmith"no reason to store it other than to return the wrong thing out of the API" <-- FTFY19:19
mriedemyes correct19:19
dansmith\o/19:19
melwittzigo: okay, after looking through the code, what I'll guess is a decent way to try first is, move the static _supports_direct_io function into nova/utils.py and make it public, then call that in both the libvirt driver and virt/images.py to find out how to set cachemode19:20
*** claudiub|2 has quit IRC19:20
efriedjaypipes Are we allowed to have more than one non-MISC_SHARES_VIA_AGGREGATE in a given aggregate?  I mean, nothing stops us from doing that; but what does it mean?19:20
melwittbecause AFAICT, the test for direct io support is just a linux thing, not specific to libvirt19:20
jaypipesefried: aggregates don't have traits. only providers have traits.19:22
jaypipesefried: aggregates are simply groups of providers, nothing more.19:22
efriedjaypipes I understand that.  Rephrase: Are we allowed to have more than one RP without the MISC_SHARES_VIA_AGGREGATE trait in a given aggregate?  I mean, nothing stops us from doing that; but what does it mean?19:23
jaypipesefried: are you asking whether it's allowed to have >1 provider sharing the same resource class to other providers in its aggregates?19:23
efriedno19:23
efriedjaypipes In today's terms: Am I allowed to have more than one "compute node" in the same aggregate?19:23
jaypipesefried: *most* providers in an aggregate will *not* have the MISC_SHARES_VIA_AGGREGATE trait.19:23
jaypipesefried: for instance, compute node providers won't (typically) have that trait.19:24
mriedemhow bad would an alter table be on the migrations table to change old/new_instance_type from an integer to a varchar(64)?19:24
jaypipesefried: yes, it's totally expected to have >1 compute node in an aggregate19:24
mriedemwith say 100k entries19:24
jaypipesmriedem: less than a couple seconds.19:24
mriedemand,19:24
dansmithwe should just add the column, not change it19:24
dansmithper normal and then backfill the data19:24
mriedemyeah that was the other option i was thinking of19:25
mriedemi don't know that we could even reliably backfill it19:25
dansmiththere's no reason to change it unless we're going to rewrite the contents and that would be ungoodly19:25
dansmithlikely not, and it'd require details from the api database19:25
mriedemyup, and, flavor 1 might no longer exist19:25
dansmithis it majorly problematic that the user can't see what the resize actually was?19:26
dansmithI mean, it's the migrations api, mostly about moves anyway right?19:26
mriedemit's all about moves19:26
mriedemadmin-only by default19:26
mriedemif we added a new column, the api could just check that first, and if not set (old record), we fallback to the existing broken field19:27
*** yamamoto has quit IRC19:28
dansmithand that's just empty for non-resize moves?19:28
mriedemno,19:28
mriedemit's just equal for everything else19:28
mriedem:)19:28
openstackgerritIan Wienand proposed openstack/nova stable/newton: [DNM] Testing d-g automatic -eol tag detection  https://review.openstack.org/52350919:29
mriedemhttps://github.com/openstack/nova/blob/5b5b5c8df316e4c26b853c80ae8f8ea91f9c05c0/nova/conductor/tasks/migrate.py#L180-L18119:29
dansmithI just don't see the point I guess19:29
mriedemsure, but,19:29
mriedemit's also dumb19:29
dansmithflavorid doesn't really get you the info you need either19:30
mriedemnot if the flavor is deleted19:30
mriedemi agree19:30
dansmithso if you want to do this, we should go all overkill and store the actual flavors19:30
dansmithreally fatten out our database19:30
mriedemso we could microversion the fields out of the response19:30
mriedemdatabase, singular?19:30
dansmithyuup19:30
dansmithand/or always return zero there19:30
dansmithheh19:30
*** priteau has quit IRC19:30
*** ijw has quit IRC19:33
efriedjaypipes Am I missing something or are these identical? https://github.com/openstack/nova/blob/master/nova/objects/resource_provider.py#L1074-L109119:34
efried(other than the name of the alias)19:34
zigomelwitt: Ok, thanks.19:35
melwittzigo: let me know if you have any questions or if something wasn't clear19:35
zigoI'll do that later on (when my kids sleep...:)19:35
melwittheh, k19:35
jaypipesefried: nope, you're not missing anything. for explanation of why that's needed, see the comments above about "butterfly join"19:37
*** sdague has quit IRC19:37
efriedjaypipes Yeah, totally confused by all of that at the moment.19:37
jaypipesefried: https://github.com/openstack/nova/blob/master/nova/objects/resource_provider.py#L890-L94919:37
*** links has joined #openstack-nova19:38
efriedjaypipes Is there some reason we need two copies of that dict?19:38
jaypipesefried: I'd be happy to walk you through it in a hangout if you need.19:39
jaypipesefried: it's two separate sets of aliased tables. not the same dict.19:39
efriedjaypipes Hum, yeah.19:39
efriedjaypipes A walkthrough would be great, though I don't think my brain can handle it now.  I'll take you up on it at some point when I'm feeling smarter.19:39
jaypipesefried: np, happy to do that.19:39
efriedthanks19:40
*** stvnoyes has quit IRC19:40
jaypipesefried: sharing providers are the bane of my existence.19:40
efriedSurely not the *only* bane.19:41
jaypipesefried: heh19:41
*** links has quit IRC19:42
jaypipesefried: just completed the last of the test runs on n-r-p series. just in time to need to rebase and bump to 1.14 instead of 1.13...19:43
efriedjaypipes Fun day.19:43
edleafeefried: if you ever need a sanity check on differences, try https://www.diffchecker.com19:43
edleafeReally helpful when comparing expected vs. actual in tests19:44
efriededleafe Nice, thanks!19:44
openstackgerritMerged openstack/nova master: Regenerate and pass configdrive when rebuild Ironic nodes  https://review.openstack.org/50308819:44
jaypipesefried: actually... if you are looking for something to do...19:49
efriedjaypipes Tell me.  I think I could just about handle a deep rebase right now.19:49
jaypipesefried: if you wouldn't mind fixing those little issues you found on https://review.openstack.org/#/c/523192/, that would be super useful since I'm currently rebasing again the n-r-p series.19:50
efriedight19:50
jaypipesefried: since that's an important bug.19:50
efriedlemme propose this ksa release and I'll hit that...19:50
jaypipesefried: and will make mriedem happy.19:50
jaypipes++19:50
jaypipesthanks much19:50
*** gouthamr_ has joined #openstack-nova19:53
openstackgerritMatt Riedemann proposed openstack/nova master: Remove deprecated TrustedFilter  https://review.openstack.org/50686419:54
*** kenperkins has quit IRC19:56
*** gouthamr has quit IRC19:56
openstackgerritEric Fried proposed openstack/nova master: Use oslo_db Session in resource_provider.py  https://review.openstack.org/52319219:58
efriedjaypipes ^ -- though I doubt mriedem was witholding his +2 for those issues.19:58
mriedemi'm withholding my +2 for other reasons19:59
efriedat least this way we get more test runs.19:59
efriedmriedem Care to comment?19:59
mriedemi will leave you in suspense20:00
*** amodi has joined #openstack-nova20:01
openstackgerritMerged openstack/nova master: Remove 'nova-manage quota refresh' command  https://review.openstack.org/52182920:02
*** stvnoyes has joined #openstack-nova20:02
efriedjaypipes https://bugs.launchpad.net/nova/+bug/1731668 got reassigned to me, and I can't seem to punt it back to you.  Why is that?20:05
openstackLaunchpad bug 1731668 in OpenStack Compute (nova) "placement: claim allocations fails with IndexError in _ensure_lookup_table_entry" [High,In progress] - Assigned to Eric Fried (efried)20:05
mriedemefried: are you on the nova bug team?20:05
efriedmriedem How would I know?20:05
mriedemhttps://launchpad.net/~nova-bugs20:05
efriedSorry, I didn't mean that to sound rude20:06
efriedI literally meant, how would I know if that's the case?20:06
* mriedem puts down the knife20:06
mriedemshould show your membership in there somewhere20:06
mriedemor under your launchpad profile20:06
mriedemhttps://launchpad.net/~efried/+participation20:06
mriedemso no20:06
mriedemso join the nova bug team20:06
efriedight20:06
* efried reads the rules right quick20:07
mriedemthere are no rules20:07
*** suresh12 has quit IRC20:08
efriedThere's a busted link at https://wiki.openstack.org/wiki/Nova/BugTriage20:08
mriedemwikis are free to update20:08
mriedembut you mean http://138.197.2.61/ yes?20:09
efriedyeah20:09
efriedI wouldn't know what to update it to.20:09
mriedemlet me see if i can find it20:09
mriedemhttp://45.55.105.55:3000/dashboard/db/openstack-bugs20:10
mriedem45.55.105.55:8082/bugs-dashboard.html20:10
mriedemhttp://45.55.105.55:8082/bugs-dashboard.html20:10
mriedemmight be dead at this point since markus_z was maintaining that20:11
*** suresh12 has joined #openstack-nova20:11
efriedFix Committed and Fix Released -- this is no longer accurate: https://wiki.openstack.org/wiki/Bugs ?20:13
efriedCause we mark Fix Released as soon as it's in master; and we don't use Fix Committed at all - right?20:13
mriedemonce something is merged on master it's marked fix released20:14
mriedemi think things get marked fix committed on stable branches20:14
*** lpetrut has joined #openstack-nova20:14
mriedemthere is no auto-release of those for stable releases i don't think, although dhelmann used to run a script for that20:14
mriedemidk anymore20:14
mriedemnor is there a proposed/* branch anymore20:14
efriedSince it's OpenStack-wide, I'll refrain from editing that page; long as I have some understanding of what the real deal is.20:15
efriedMebbe I'll mention it to dhellmann20:16
mriedembauzas and stephenfin gave a talk at the summit about bug triage20:16
mriedemyou can blast them with your questions20:16
*** eharney has quit IRC20:19
*** pcaruana has joined #openstack-nova20:21
*** tidwellr has quit IRC20:21
*** tidwellr has joined #openstack-nova20:21
*** sahid has joined #openstack-nova20:22
*** sahid has quit IRC20:23
openstackgerritMatt Riedemann proposed openstack/nova master: Fix some incorrect option references for scheduler filters  https://review.openstack.org/52164520:23
openstackgerritMatt Riedemann proposed openstack/nova master: Deprecate the IronicHostManager  https://review.openstack.org/52164820:23
openstackgerritMerged openstack/nova master: libvirt: remove extraneous retry assignment in cleanup method  https://review.openstack.org/40919920:26
*** suresh12 has quit IRC20:26
*** esberglu has quit IRC20:27
*** awaugama has quit IRC20:33
*** READ10 has quit IRC20:37
*** suresh12 has joined #openstack-nova20:39
*** kenperkins has joined #openstack-nova20:39
*** esberglu has joined #openstack-nova20:40
mriedemefried: jaypipes: maybe you guys can confirm the issue i raised in this osc-placement allocations patch https://review.openstack.org/#/c/457534/1020:47
mriedembut looking at how PUT /allocations/{consumer_id} works before 1.12, we can get some weird behavior20:47
openstackgerritJay Pipes proposed openstack/nova master: placement: add nested resource providers  https://review.openstack.org/37713820:48
openstackgerritJay Pipes proposed openstack/nova master: placement: allow filter providers in tree  https://review.openstack.org/37721520:48
openstackgerritJay Pipes proposed openstack/nova master: placement: adds REST API for nested providers  https://review.openstack.org/38480720:48
openstackgerritJay Pipes proposed openstack/nova master: placement: update client to set parent provider  https://review.openstack.org/38569320:48
openstackgerritJay Pipes proposed openstack/nova master: ProviderTree.uuid_set()  https://review.openstack.org/52024320:48
openstackgerritJay Pipes proposed openstack/nova master: Scheduler set_inventory_for_provider does nested  https://review.openstack.org/52064320:48
openstackgerritJay Pipes proposed openstack/nova master: SchedulerReportClient._get_providers_in_tree  https://review.openstack.org/52066320:48
openstackgerritJay Pipes proposed openstack/nova master: SchedulerReportClient._get_providers_in_aggregates  https://review.openstack.org/52109720:48
openstackgerritJay Pipes proposed openstack/nova master: ProviderTree.populate_from_iterable  https://review.openstack.org/52075620:48
openstackgerritJay Pipes proposed openstack/nova master: Scheduler[Report]Client.get_provider_tree  https://review.openstack.org/52109820:48
openstackgerritJay Pipes proposed openstack/nova master: WIP: ComputeDriver.update_provider_tree()  https://review.openstack.org/52118720:48
openstackgerritJay Pipes proposed openstack/nova master: WIP: Use update_provider_tree from resource tracker  https://review.openstack.org/52024620:48
jaypipesmriedem: gonna take a break for a bit, but will look at that later.20:48
mriedemsmoke'em if you got'em20:49
melwittmriedem: about the console TLS series, you might have you skim it to see what I mean. it's an effort to break the work into chunks. an already merged patch added a base class for a SecurityProxy. the first unmerged patch in the series lays some groundwork by adding a base class and a None auth scheme. the second patch adds a vencrypt auth scheme, and the final patch adds a RFBSecurityProxy which actually does the encryption20:49
efriedmriedem ack; but sounds like it oughtta be solved in the CLI - not a bug in the placement API?20:49
mriedemefried: that's what i said, i think it's a limitation in the api until 1.12 and we have to handle it in the cli20:50
*** priteau has joined #openstack-nova20:50
melwittmriedem: so I'm not seeing a better way to do the reno except at the end https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/websocket-proxy-to-host-security20:50
mriedemmelwitt: well, we could just hold off on approving the first unmerged patch with the new option until people are happy with the entire series20:50
efriedmriedem rgr.  Though "limitation" might be a bit strong.20:50
melwittmriedem: okay, that works20:50
*** edmondsw_ has joined #openstack-nova20:52
*** edmondsw has quit IRC20:56
*** kenperkins has quit IRC20:58
*** kenperkins has joined #openstack-nova21:00
openstackgerritMerged openstack/nova master: Enable cold migration with target host(1/2)  https://review.openstack.org/40895521:00
*** penick has quit IRC21:03
*** thorst has quit IRC21:03
*** moshele has joined #openstack-nova21:04
*** Alex_Staf has joined #openstack-nova21:08
*** flanders_ has joined #openstack-nova21:08
*** gbarros has quit IRC21:12
*** awaugama has joined #openstack-nova21:15
*** stvnoyes has quit IRC21:15
*** armax has quit IRC21:17
*** penick has joined #openstack-nova21:20
*** gbarros has joined #openstack-nova21:21
*** gszasz has quit IRC21:21
*** gouthamr_ is now known as gouthamr21:21
*** pcaruana has quit IRC21:21
*** smatzek has quit IRC21:22
*** kenperkins has quit IRC21:24
melwittweird, yet another time when it says merge conflict and I rebase locally but there was no conflict ...21:25
*** edmondsw_ is now known as edmondsw21:27
melwittmriedem: should I just try the rebase button on https://review.openstack.org/#/c/498983 ? it says merge conflict but there's no conflict to resolve when I pull it down and rebase locally21:27
mriedemsure21:28
melwittk, trying that now21:29
openstackgerritmelanie witt proposed openstack/nova master: Save updated libvirt domain XML after swapping volume  https://review.openstack.org/49898321:29
*** thorst has joined #openstack-nova21:30
*** rcernin has quit IRC21:33
*** liverpooler has quit IRC21:37
*** liverpooler has joined #openstack-nova21:38
*** pchavva has quit IRC21:42
*** toure is now known as toure_biab21:42
*** openstackstatus has quit IRC21:42
*** openstack has joined #openstack-nova21:44
*** ChanServ sets mode: +o openstack21:44
*** erlon has quit IRC21:44
penickHey folks, we're gearing up to replace our quota by flavor (and az) patches with something we could actually upstream. At the moment (based on hazy recollection of conversations at the summit) the direction i'm heading in is to do quota by custom resource class, wherein a resource class could be a combination of AZ and Flavor. Does that sound sane?21:44
mriedemmlavalle: is this the neutron port binding extension that i'd want for the live migration thingy? http://paste.openstack.org/show/627643/21:45
penickWanted to see if anyone had some input before we started working on the spec.21:45
melwittpenick: I think what we discussed was leveraging the quota class facility we already have and adding the ability to tag flavors with a quota class21:45
*** kenperkins has joined #openstack-nova21:47
penickmelwitt: ah, I also have to do quota by flavor and AZ as well. Can I make that work using quota classes too?21:47
mriedemmlavalle: i'm guessing it's not, since it looks like that extension is just an indication of the binding:profile stuff on the port, i.e. https://developer.openstack.org/api-ref/network/v2/index.html#port-binding-extended-attributes21:47
mlavallemriedem: it's not21:48
mlavallethat is the existing extension21:48
*** moshele has quit IRC21:48
*** amodi has quit IRC21:48
melwittpenick: this gives a high level view of what quota classes are https://docs.openstack.org/nova/pike/user/quotas.html so it's already possible to set quota on a per class basis i.e. "openstack quota set --class myclass --instances 5"21:49
melwittit's just that currently there is no way to specify a quota class with any one request. rackspace used to do it via their own custom paste middleware, IIRC21:49
*** hamzy has quit IRC21:50
penickoh ok, I didn't realize that it could be custom resource classes too, not just the typical resources like instances, ram, etc21:51
mriedemnot the same thing21:52
mriedemresource classes are a placement concept21:52
melwittas for AZ, I guess to do it that way there would need to be a way to tag an AZ with a quota class21:52
mriedemquota classes are a nova concept21:52
gryfquota class is different thing21:52
mriedemplacement doesn't have any concept of quota21:52
penickAh, that makes sense.21:53
mriedemwe've talked about replacing nova's quota calculation code using the consumer allocation / resource class stuff in placement at some point, but there are issues21:53
mriedembecause the quota usage in nova is also tracked via allocatoins in placemetn for things like vcpu/memory_mb/disk_gb21:53
melwittyeah. a quota class is a logical grouping of quotas. like you could create a 'dev class' that has certain quota limits and you could create a different 'prod class' that has different quota limits21:54
mriedempenick: you could start with a backlog spec to document the problem and use case21:54
mriedemw/o getting into design or implementation details21:54
mriedemnote that today you can create any number of custom quota classes in nova, but the only one that the code actually gives 2 shits about is the 'default' quota class21:55
*** slaweq_ has quit IRC21:55
mriedemala https://review.openstack.org/#/c/411035/21:55
melwittthey've proposed a spec about it in the past, it got gridlocked on the implementation details21:55
mriedemthey = yahoo, past = juno?21:55
*** slaweq has joined #openstack-nova21:56
mriedemand was it the same guy that was doing the zookeeper spec that gridlocked for 3 years?21:56
melwittI was thinking a reasonable way to actually get it done would be to use quota classes and provide a way to tag flavor with a quota class21:56
mriedemor tooz or kazoo or whatever it was21:56
melwittmriedem: yes21:56
*** slaweq_ has joined #openstack-nova21:56
*** thorst has quit IRC21:56
penickheh21:57
*** slaweq_ has quit IRC21:57
mriedemwelp, i'd dig up the old spec i guess because i'm not familiar with the use case / problem description21:57
mriedemand i'm sure that predated anything with placement21:57
mriedem*plus* no chance for queens, so you'd have to tee this up for discussion in dublin21:57
*** slaweq_ has joined #openstack-nova21:57
melwittmriedem: this is the old spec https://review.openstack.org/#/c/206160/21:58
melwittit was agreed to be a reasonable use case, just that all of the implementation ideas were pretty hairy21:59
mriedemanything involving AZs is going to be hairy as hell21:59
mriedemor quotas21:59
mriedemis there some way we can work boot from volume into this?21:59
penickYou bet your ass we can21:59
melwittbeing able to tag a flavor with a quota class would get us quota by flavor at least, and the same use case has come up in the preemptable instances discussions21:59
*** slaweq has quit IRC22:00
*** ijw has joined #openstack-nova22:01
melwittthat is, for preemptable instances, you could have a quota class 'preemtable' which is unlimited quota and tag preemptable instance flavors with that class. so that users booting preemptable instances don't use up their quota when they boot them22:01
*** armax has joined #openstack-nova22:02
mriedemmlavalle: ok so i'm looking for the "binding-extended" extension per https://review.openstack.org/#/c/484389/8/neutron_lib/api/definitions/portbindings_extended.py22:02
*** kenperkins has quit IRC22:02
mriedemmlavalle: i'm looking at starting to build up the nova patches for this thing, and part of that is just asking neutron if the api extension is even available to do the deed22:03
*** slaweq_ has quit IRC22:03
*** slaweq has joined #openstack-nova22:04
*** slaweq has quit IRC22:04
mlavallemriedem: that is the extension definition. as far as the implementation, I am working on it22:05
openstackgerritKen'ichi Ohmichi proposed openstack/nova master: Remove unnecessary spaces on JSON samples  https://review.openstack.org/52354322:06
*** hemna_ has joined #openstack-nova22:06
penickSo If I want to limit tenant $foo to 10 instances of flavor $bar, and I want to limit tenant $baz to 20 instances of flavor bar, i'd create 2 quota classes, one for tenant $foo, one for tenant $baz, then tag flavor $bar with both quota classes?22:06
*** peter-hamilton has quit IRC22:07
*** ijw has quit IRC22:07
penickis that how the flow would go? Assuming I could tag a flavor with the quota class22:09
melwittpenick: hm, no. what I was saying would only work to have 1 set of quotas for a flavor if every tenant gets the same quotas for that flavor22:09
penickoh, crud22:09
*** ijw has joined #openstack-nova22:09
melwittbasically, you'd need a quota class per unique set of quota limits22:10
melwittI would think to a large extent many tenants would be able to use the same class?22:11
penicki'm checking the DB on one of our prod clusters right now..22:12
mriedemif we ever get limits information from keystone, doesn't that kind of throw a wrench into all of this?22:12
melwittwhat I mean is, you would only need one class per tenant/flavor if they were all literally different22:12
mriedembecause that's the eventual replacement for quota classes in nova22:12
melwittit would throw a wrench if we won't have quota classes in keystone22:13
*** tidwellr has quit IRC22:14
*** slaweq has joined #openstack-nova22:14
*** tidwellr has joined #openstack-nova22:15
*** ijw has quit IRC22:15
penickOk, so i'll need to assume one class per tenant and flavor22:16
melwitthang on, let me look at this again real quick.22:16
penickmriedem are limits definitely moving to keystone? Because i've heard talk about that for a year or two..and nothing's happened.22:16
dansmithwell, people keep getting laid off22:16
dansmithkinda gets in the way of progress22:17
mriedemsomeone from huawei was supposedly working on picking up that spec in keystone, but last i heard in sydney it was dropped in lbragstad's lap, and he's trying to move the rbac stuff forward22:17
lbragstadwe do have a new owner for that work22:18
lbragstadhttps://review.openstack.org/#/c/455709/22:18
*** tidwellr has quit IRC22:19
lbragstadwhich is still under sdague's name but wxy is picking it up22:19
*** gbarros has quit IRC22:19
lbragstadso if there is anything nova needs out of that interface from keystone, let us know22:20
openstackgerritMatt Riedemann proposed openstack/nova master: Add check if neutron "binding-extended" extension is available  https://review.openstack.org/52354822:21
openstackgerritMatt Riedemann proposed openstack/nova master: Add check if neutron "binding-extended" extension is available  https://review.openstack.org/52354822:22
penickif Keystone is going to be able to land the limits api in queens, will Nova move to use it for Rocky?22:22
lbragstadyeah - that's the idea22:22
*** rcernin has joined #openstack-nova22:23
*** priteau has quit IRC22:23
lbragstadbut there are other things that playing into it too, which sean was really driving in Boston (like what enforcement models to use)22:23
lbragstadwe're not quite sure how that's going to get applied as the service yet22:23
*** thorst has joined #openstack-nova22:27
*** moshele has joined #openstack-nova22:28
melwittpenick: I looked through the code again and indeed quota classes are not per tenant. so it won't be as simple as what I thought earlier22:30
penickmelwitt: dang22:30
*** thorst has quit IRC22:31
*** jaypipes has quit IRC22:35
*** Alex_Staf has quit IRC22:36
*** awaugama has quit IRC22:36
*** edmondsw has quit IRC22:36
*** thorst has joined #openstack-nova22:38
*** edmondsw has joined #openstack-nova22:39
*** penick has quit IRC22:40
openstackgerritMatt Riedemann proposed openstack/nova master: Add check if neutron "binding-extended" extension is available  https://review.openstack.org/52354822:40
*** thorst has quit IRC22:42
*** abalutoiu has quit IRC22:42
openstackgerritThomas Goirand proposed openstack/nova master: qemu-img do not use cache=none if no O_DIRECT support  https://review.openstack.org/52355422:43
*** edmondsw has quit IRC22:43
zigomelwitt: ^22:45
melwittcool, looking22:46
openstackgerritMathieu Gagné proposed openstack/nova master: Fix rebuild of baremetal instance when vm_state is ERROR  https://review.openstack.org/52355922:51
mriedemefried: can i make simple rest calls like post() from a ksa adapter object?22:53
mriedemmgagne: broken already :)22:53
mgagnemriedem: what's broken?22:54
mriedemmgagne: oh nvm, was thinking the rebuild + config drive thing22:54
mgagnemriedem: hehe, we have a theme this month: rebuilding stuff =)22:54
dansmithand re-rebuilding22:55
mgagnethat one had an interesting side effect: rebuild is actually happening on Ironic side but Nova stays in ERROR while rebuild continues22:55
*** marst has quit IRC22:56
mriedemefried: nvm, answer is yes, that's exactly how it's used for the placement client in SchedulerReportClient22:57
melwittzigo: reviewed, couple of minor things and need unit tests. looks clean tho22:59
efriedmriedem Yuh23:00
*** suresh12 has quit IRC23:01
*** Alex_Staf has joined #openstack-nova23:01
*** ijw has joined #openstack-nova23:03
openstackgerritOpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements  https://review.openstack.org/52356223:07
*** ijw has quit IRC23:08
zigomtreinish: Thanks, though I'm not sure what kind of unit tests you think I should write.23:10
openstackgerritThomas Goirand proposed openstack/nova master: qemu-img do not use cache=none if no O_DIRECT support  https://review.openstack.org/52355423:11
zigomtreinish: sorry wrong person.23:12
zigomelwitt: I'm not sure how the unit tests you're recommending should look like.23:13
melwittzigo: I attempted to explain in my comment. basically you'd mock supports_direct_io and utils.execute via decorators, and in one test make supports_direct_io return True and then verify that utils.execute was called with '-t none' and vice versa for it returning False23:16
*** lbragstad has quit IRC23:17
*** lyan has quit IRC23:18
*** edmondsw has joined #openstack-nova23:18
melwittzigo: if you don't have time to give it a try or otherwise don't want to, I can write the tests and add them to your patch as a co-author if that's okay with you23:19
zigomelwitt: It'd be great if you did so, yes.23:19
zigoThanks.23:19
melwittk, np23:20
*** edmondsw has quit IRC23:23
*** lbragstad has joined #openstack-nova23:24
*** suresh12 has joined #openstack-nova23:25
*** lpetrut has quit IRC23:25
*** penick has joined #openstack-nova23:27
*** flanders_ has quit IRC23:27
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: Add code to bind a port against a dest host during live migration  https://review.openstack.org/52360423:29
mriedemmlavalle: ^23:29
mriedemit's a start23:29
mlavallemriedem: thanks :-)23:30
openstackgerritTakashi NATSUME proposed openstack/nova master: [placement] Fix getting placement reuest ID  https://review.openstack.org/52360623:33
openstackgerritTakashi NATSUME proposed openstack/nova master: [placement] Fix getting placement reuest ID  https://review.openstack.org/52360623:33
*** salv-orl_ has joined #openstack-nova23:37
*** salv-orlando has quit IRC23:40
*** slaweq has quit IRC23:40
*** slaweq has joined #openstack-nova23:41
*** slaweq has quit IRC23:45
*** thorst has joined #openstack-nova23:46
*** thorst has quit IRC23:50
*** takashin has joined #openstack-nova23:53
*** lbragstad has quit IRC23:56
openstackgerritMathieu Gagné proposed openstack/nova master: Fix rebuild of baremetal instance when vm_state is ERROR  https://review.openstack.org/52355923:59

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