Thursday, 2018-04-05

*** _ix has quit IRC00:02
*** _ix_ has quit IRC00:09
*** Zames has joined #openstack-nova00:09
*** felipemonteiro has quit IRC00:20
*** Zames has quit IRC00:21
*** ssurana has quit IRC00:23
*** jmlowe has joined #openstack-nova00:31
*** suresh12 has quit IRC00:32
*** suresh12 has joined #openstack-nova00:33
*** yamamoto has joined #openstack-nova00:34
*** gouthamr has joined #openstack-nova00:37
*** yamamoto has quit IRC00:39
*** odyssey4me has quit IRC00:41
*** odyssey4me has joined #openstack-nova00:41
*** hoangcx has joined #openstack-nova00:43
*** kevinbenton_ has joined #openstack-nova00:46
*** obre_ has joined #openstack-nova00:46
*** lifeless has joined #openstack-nova00:46
*** slaweq_ has joined #openstack-nova00:46
*** cburgess_ has joined #openstack-nova00:49
*** zzzeek_ has joined #openstack-nova00:50
*** lifeless_ has quit IRC00:51
*** rubasov has quit IRC00:51
*** zzzeek has quit IRC00:51
*** obre has quit IRC00:51
*** kevinbenton has quit IRC00:51
*** slaweq has quit IRC00:51
*** cburgess has quit IRC00:51
*** lennyb has quit IRC00:51
*** ltomasbo has quit IRC00:51
*** chyka has joined #openstack-nova00:54
*** phuongnh has joined #openstack-nova00:56
*** lennyb has joined #openstack-nova00:58
*** rubasov has joined #openstack-nova00:58
*** chyka has quit IRC00:59
*** hongbin_ has joined #openstack-nova00:59
*** voelzmo has joined #openstack-nova01:11
*** tiendc has joined #openstack-nova01:13
*** tssurya has joined #openstack-nova01:13
*** Swami has quit IRC01:15
*** tssurya has quit IRC01:18
*** yangyapeng has joined #openstack-nova01:19
*** gyan__ has joined #openstack-nova01:20
*** salv-orl_ has joined #openstack-nova01:20
*** ssurana has joined #openstack-nova01:22
*** ssurana has quit IRC01:22
*** salv-orlando has quit IRC01:23
*** suresh12 has quit IRC01:32
*** _ix has joined #openstack-nova01:34
*** mriedem_away has quit IRC01:34
*** yamamoto has joined #openstack-nova01:35
*** _ix_ has joined #openstack-nova01:40
*** yamamoto has quit IRC01:41
*** gjayavelu has quit IRC01:42
*** harlowja has quit IRC01:42
*** _ix has quit IRC01:42
*** Guest44505 has quit IRC01:45
*** voelzmo has quit IRC01:45
*** nicolasbock has quit IRC01:50
*** tssurya has joined #openstack-nova01:55
*** tssurya has quit IRC01:59
*** r-daneel has joined #openstack-nova02:02
*** suresh12 has joined #openstack-nova02:03
*** blkart_ has joined #openstack-nova02:06
*** suresh12 has quit IRC02:08
*** _ix_ has quit IRC02:10
*** edmondsw has joined #openstack-nova02:25
*** _ix has joined #openstack-nova02:25
*** tbachman has quit IRC02:26
openstackgerritMerged openstack/nova master: Default to py3 for the pep8 tox env because it's stricter  https://review.openstack.org/55864802:29
*** gouthamr has quit IRC02:33
*** jmlowe has quit IRC02:34
*** Spaz-Work has joined #openstack-nova02:34
*** Spazmotic has quit IRC02:35
*** tbachman has joined #openstack-nova02:35
*** yamamoto has joined #openstack-nova02:37
*** liusheng has quit IRC02:37
*** liusheng has joined #openstack-nova02:38
*** jmlowe has joined #openstack-nova02:39
*** hoonetorg has quit IRC02:39
*** fragatina has quit IRC02:43
*** yamamoto has quit IRC02:43
*** edmondsw has quit IRC02:51
*** hoonetorg has joined #openstack-nova02:52
*** tssurya has joined #openstack-nova02:56
*** tssurya has quit IRC03:00
*** janki has joined #openstack-nova03:01
*** jchhatbar has joined #openstack-nova03:10
*** janki has quit IRC03:12
*** namnh has joined #openstack-nova03:16
*** psachin has joined #openstack-nova03:18
*** Zames has joined #openstack-nova03:20
*** jmlowe has quit IRC03:21
*** Zames has quit IRC03:23
*** suresh12 has joined #openstack-nova03:25
*** harlowja has joined #openstack-nova03:37
*** yamamoto has joined #openstack-nova03:39
*** germs has quit IRC03:39
*** germs has joined #openstack-nova03:40
*** germs has quit IRC03:40
*** germs has joined #openstack-nova03:40
*** voelzmo has joined #openstack-nova03:42
*** lbragstad has joined #openstack-nova03:42
*** suresh12 has quit IRC03:43
*** suresh12 has joined #openstack-nova03:43
*** tianhui_ has quit IRC03:44
openstackgerritMerged openstack/nova master: Fix nits in update_provider_tree series  https://review.openstack.org/53126003:44
*** tianhui has joined #openstack-nova03:44
*** yamamoto has quit IRC03:45
*** hongbin_ has quit IRC03:50
*** yamamoto has joined #openstack-nova03:52
*** udesale has joined #openstack-nova03:54
*** psachin` has joined #openstack-nova03:57
*** psachin has quit IRC03:57
*** fragatina has joined #openstack-nova03:58
*** fragatin_ has joined #openstack-nova03:58
*** fragatina has quit IRC04:02
*** voelzmo has quit IRC04:07
*** germs has quit IRC04:10
*** blkart_ has quit IRC04:14
*** sridharg has joined #openstack-nova04:21
*** links has joined #openstack-nova04:23
*** fragatin_ has quit IRC04:34
*** sree has joined #openstack-nova04:34
openstackgerritTetsuro Nakamura proposed openstack/nova master: Consider nested RPs in get_all_with_shared  https://review.openstack.org/55645004:35
openstackgerritTetsuro Nakamura proposed openstack/nova master: Support shared and nested allocation candidates  https://review.openstack.org/55651404:35
*** abhishekk has joined #openstack-nova04:36
*** tssurya has joined #openstack-nova04:40
*** tssurya has quit IRC04:44
*** yamahata has joined #openstack-nova04:49
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/virt/xenapi/test_vm_utils.py (2)  https://review.openstack.org/55899304:53
*** lpetrut has joined #openstack-nova04:58
*** lbragstad has quit IRC04:58
*** mdnadeem has joined #openstack-nova04:59
*** lbragstad has joined #openstack-nova05:01
*** chyka has joined #openstack-nova05:05
*** sridharg has quit IRC05:08
*** lbragstad has quit IRC05:10
*** chyka has quit IRC05:10
*** harlowja has quit IRC05:22
*** yangyapeng has quit IRC05:27
*** fragatina has joined #openstack-nova05:27
*** ccamacho has quit IRC05:33
*** moshele has joined #openstack-nova05:36
openstackgerritNakanishi Tomotaka proposed openstack/nova master: Test availability zone in multiple cells  https://review.openstack.org/55899805:37
*** ratailor has joined #openstack-nova05:38
openstackgerritTetsuro Nakamura proposed openstack/nova master: Return all resources in provider_summaries  https://review.openstack.org/55804505:38
*** yangyapeng has joined #openstack-nova05:47
*** lpetrut has quit IRC05:49
*** yangyapeng has quit IRC05:53
*** sahid has joined #openstack-nova05:55
*** sridharg has joined #openstack-nova05:56
*** lpetrut has joined #openstack-nova05:58
*** yangyapeng has joined #openstack-nova05:59
*** damien_r1 has quit IRC06:01
*** suresh12 has quit IRC06:05
*** Swami has joined #openstack-nova06:07
*** cfriesen_ has quit IRC06:09
*** lajoskatona has joined #openstack-nova06:12
*** stakeda has joined #openstack-nova06:14
*** sree has quit IRC06:17
*** sree has joined #openstack-nova06:18
*** evin has joined #openstack-nova06:18
*** cfriesen_ has joined #openstack-nova06:19
*** fragatina has quit IRC06:19
*** lpetrut has quit IRC06:19
*** lpetrut has joined #openstack-nova06:20
*** gjayavelu has joined #openstack-nova06:22
*** tuanla____ has joined #openstack-nova06:22
*** sree_ has joined #openstack-nova06:23
*** sree_ is now known as Guest338006:23
*** sree has quit IRC06:23
*** pcaruana has joined #openstack-nova06:28
*** lpetrut has quit IRC06:32
*** suresh12 has joined #openstack-nova06:36
*** mdnadeem has quit IRC06:37
*** AlexeyAbashkin has joined #openstack-nova06:38
*** Swami has quit IRC06:44
*** hoangcx has quit IRC06:47
*** suresh12 has quit IRC06:47
*** hoangcx has joined #openstack-nova06:50
*** belmoreira has joined #openstack-nova06:52
*** armaan has joined #openstack-nova06:54
*** andreas_s has joined #openstack-nova06:54
*** danpawlik has joined #openstack-nova06:55
openstackgerritOpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata  https://review.openstack.org/54877207:04
*** imacdonn has quit IRC07:04
*** Guest3380 has quit IRC07:04
*** imacdonn has joined #openstack-nova07:05
*** damien_r has joined #openstack-nova07:06
*** ccamacho has joined #openstack-nova07:07
*** jchhatbar is now known as janki07:07
*** yamahata has quit IRC07:08
*** ccamacho has quit IRC07:10
*** sree has joined #openstack-nova07:13
*** tesseract has joined #openstack-nova07:15
*** gjayavelu has quit IRC07:28
*** rcernin has quit IRC07:30
*** Dinesh_Bhor has joined #openstack-nova07:33
*** avolkov has joined #openstack-nova07:35
*** claudiub|2 has joined #openstack-nova07:37
*** belmoreira has quit IRC07:42
*** alexchadin has joined #openstack-nova07:42
*** amoralej|off is now known as amoralej07:42
*** jpena|off is now known as jpena07:42
*** lajoskatona has left #openstack-nova07:47
*** alexchad_ has joined #openstack-nova07:51
*** suresh12 has joined #openstack-nova07:51
*** evin has quit IRC07:51
*** tssurya has joined #openstack-nova07:53
*** alexchadin has quit IRC07:54
*** ralonsoh has joined #openstack-nova07:55
*** ralonsoh has quit IRC07:55
*** suresh12 has quit IRC07:56
openstackgerritTetsuro Nakamura proposed openstack/nova master: Check pinning support in NUMATopologyFilter  https://review.openstack.org/53104907:57
openstackgerritTetsuro Nakamura proposed openstack/nova master: Add NumaTopology support for libvirt/qemu driver  https://review.openstack.org/53045107:57
openstackgerritTetsuro Nakamura proposed openstack/nova master: Enable cpu pinning with libvirt/QEMU driver  https://review.openstack.org/55407607:57
*** mgoddard has joined #openstack-nova08:05
*** FL1SK has quit IRC08:06
*** evin has joined #openstack-nova08:06
*** namnh_ has joined #openstack-nova08:08
*** lpetrut has joined #openstack-nova08:08
*** lucas-afk is now known as lucasagomes08:09
*** alexchadin has joined #openstack-nova08:09
*** sdake has quit IRC08:10
*** namnh has quit IRC08:10
*** logan- has quit IRC08:11
*** odyssey4me has quit IRC08:11
*** alexchad_ has quit IRC08:11
*** elod has quit IRC08:11
*** idlemind has quit IRC08:11
*** sahid has quit IRC08:12
*** hoonetorg has quit IRC08:12
*** owalsh has quit IRC08:12
*** josecastroleon has quit IRC08:12
*** oanson has quit IRC08:12
*** idlemind has joined #openstack-nova08:13
*** elod has joined #openstack-nova08:13
*** sdake has joined #openstack-nova08:13
*** sdake has quit IRC08:13
*** sdake has joined #openstack-nova08:13
*** oanson has joined #openstack-nova08:13
*** logan- has joined #openstack-nova08:13
*** sahid has joined #openstack-nova08:13
*** hoonetorg has joined #openstack-nova08:14
*** josecastroleon has joined #openstack-nova08:14
*** odyssey4me has joined #openstack-nova08:16
*** belmoreira has joined #openstack-nova08:16
*** mdnadeem has joined #openstack-nova08:18
*** ralonsoh has joined #openstack-nova08:20
*** owalsh has joined #openstack-nova08:20
*** belmoreira has quit IRC08:23
*** melwitt has quit IRC08:26
*** cdent has joined #openstack-nova08:26
*** mdbooth has joined #openstack-nova08:26
*** sdake has quit IRC08:26
*** idlemind has quit IRC08:26
*** owalsh has quit IRC08:27
*** idlemind has joined #openstack-nova08:28
*** suresh12 has joined #openstack-nova08:28
*** sdake has joined #openstack-nova08:31
*** sdake has quit IRC08:31
*** sdake has joined #openstack-nova08:31
*** armaan has quit IRC08:31
*** melwitt has joined #openstack-nova08:33
*** owalsh has joined #openstack-nova08:33
*** suresh12 has quit IRC08:33
*** strigazi has quit IRC08:35
*** armaan has joined #openstack-nova08:37
*** evin has quit IRC08:37
*** links has quit IRC08:40
*** namnh has joined #openstack-nova08:40
*** Zames has joined #openstack-nova08:41
*** suresh12 has joined #openstack-nova08:42
*** sar has joined #openstack-nova08:42
*** namnh_ has quit IRC08:42
kashyapalex_xu_: Hi there, will you be able to merge this: https://review.openstack.org/#/c/534384/08:43
kashyapIt also got thorough review from johnthetubaguy ^08:44
kashyapWe should be able to merge ready patches (with thorough reviews) during CET / UTC hours.08:45
* cdent gives kashyap a supportive thumbs up08:45
*** suresh12 has quit IRC08:46
*** Zames has quit IRC08:48
*** tssurya_ has joined #openstack-nova08:48
kashyapcdent: This is one of the fundamental blocking points that DanPB raised many moons ago08:49
*** links has joined #openstack-nova08:50
*** moshele has quit IRC08:50
*** armaan_ has joined #openstack-nova08:51
*** armaan_ has quit IRC08:51
*** armaan_ has joined #openstack-nova08:52
*** armaan_ has quit IRC08:52
*** moshele has joined #openstack-nova08:52
*** armaan_ has joined #openstack-nova08:53
*** armaan has quit IRC08:53
*** tssurya_ has quit IRC08:53
*** josecastroleon has quit IRC08:55
lyarwoodmdbooth: https://review.openstack.org/#/c/543569/ was rebased and lost your +1 if you have time today, I'll push for more reviews later once NA are online.08:56
*** moshele has quit IRC08:57
*** ccamacho has joined #openstack-nova08:57
*** suresh12 has joined #openstack-nova09:00
*** tssurya has quit IRC09:01
kashyaplyarwood: Saw it last night; I have a small remark09:02
kashyapOh, not this one, it's the other09:02
*** armaan_ has quit IRC09:02
kashyapIt's this: https://review.openstack.org/#/c/544238/  I'll write in the review09:03
*** suresh12 has quit IRC09:05
*** sree has quit IRC09:07
*** sree has joined #openstack-nova09:07
*** sree_ has joined #openstack-nova09:08
*** sree_ has quit IRC09:08
*** sree has quit IRC09:08
*** sree has joined #openstack-nova09:09
*** sree has quit IRC09:09
*** sree has joined #openstack-nova09:10
openstackgerritTetsuro Nakamura proposed openstack/nova-specs master: Enable NUMA Features for Libvirt/QEMU Driver  https://review.openstack.org/53307709:11
*** belmoreira has joined #openstack-nova09:12
*** strigazi has joined #openstack-nova09:12
*** tssurya has joined #openstack-nova09:12
*** mikal_ has quit IRC09:13
*** mikal has joined #openstack-nova09:13
openstackgerritLee Yarwood proposed openstack/nova stable/pike: libvirt: slow live-migration to ensure network is ready  https://review.openstack.org/55903209:15
openstackgerritLee Yarwood proposed openstack/nova stable/ocata: libvirt: log vm and task state when vif plugging times out  https://review.openstack.org/55903309:18
openstackgerritLee Yarwood proposed openstack/nova stable/ocata: libvirt: slow live-migration to ensure network is ready  https://review.openstack.org/55903409:18
*** derekh has joined #openstack-nova09:21
*** moshele has joined #openstack-nova09:28
*** tssurya_ has joined #openstack-nova09:29
*** Dinesh_Bhor has quit IRC09:30
*** takashin has left #openstack-nova09:33
*** moshele has quit IRC09:33
*** tssurya_ has quit IRC09:33
openstackgerritMerged openstack/nova master: Move configurable mkfs to privsep.  https://review.openstack.org/55192109:35
openstackgerritMerged openstack/nova master: Move xenapi xenstore_read's to privsep.  https://review.openstack.org/55224109:35
*** rmart04 has joined #openstack-nova09:35
*** suresh12 has joined #openstack-nova09:39
*** sambetts|afk is now known as sambetts09:42
*** suresh12 has quit IRC09:44
*** tetsuro has joined #openstack-nova09:52
*** sree has quit IRC10:02
*** rmart04 has quit IRC10:02
*** slaweq_ is now known as slaweq10:02
*** armaan has joined #openstack-nova10:04
*** sree has joined #openstack-nova10:08
*** abhishekk has quit IRC10:10
*** sree has quit IRC10:13
*** sree has joined #openstack-nova10:14
openstackgerritLee Yarwood proposed openstack/nova stable/ocata: libvirt: log vm and task state when vif plugging times out  https://review.openstack.org/55903310:15
openstackgerritLee Yarwood proposed openstack/nova stable/ocata: libvirt: slow live-migration to ensure network is ready  https://review.openstack.org/55903410:15
*** suresh12 has joined #openstack-nova10:16
*** FL1SK has joined #openstack-nova10:16
*** sree has quit IRC10:19
*** suresh12 has quit IRC10:20
*** sree has joined #openstack-nova10:20
*** tuanla____ has quit IRC10:21
*** dtantsur|afk is now known as dtantsur10:23
*** sree has quit IRC10:25
*** namnh has quit IRC10:25
*** mdbooth has quit IRC10:26
*** yangyapeng has quit IRC10:30
*** nicolasbock has joined #openstack-nova10:30
*** tssurya_ has joined #openstack-nova10:31
*** sdague has joined #openstack-nova10:35
*** tssurya_ has quit IRC10:35
*** tbachman has quit IRC10:36
*** mikal_ has joined #openstack-nova10:40
*** tbachman has joined #openstack-nova10:43
*** mikal has quit IRC10:43
*** suresh12 has joined #openstack-nova10:47
*** suresh12 has quit IRC10:51
*** tbachman has quit IRC10:59
*** jpena is now known as jpena|lunch11:00
*** phuongnh has quit IRC11:00
openstackgerritDoug Hellmann proposed openstack/nova master: add lower-constraints job  https://review.openstack.org/55596111:12
*** tetsuro has left #openstack-nova11:13
*** kaisers has joined #openstack-nova11:19
*** lucasagomes is now known as lucas-hungry11:23
*** xinliang has quit IRC11:25
*** mdbooth has joined #openstack-nova11:31
*** alexchadin has quit IRC11:32
*** xinliang has joined #openstack-nova11:38
*** stakeda has quit IRC11:39
*** alexchadin has joined #openstack-nova11:42
*** alexchadin has quit IRC11:47
*** suresh12 has joined #openstack-nova11:48
*** suresh12 has quit IRC11:52
*** lbragstad has joined #openstack-nova11:53
*** amoralej is now known as amoralej|lunch11:59
*** psachin` has quit IRC12:00
*** jpena|lunch is now known as jpena12:01
*** sree has joined #openstack-nova12:01
*** ralonsoh_ has joined #openstack-nova12:04
*** tbachman has joined #openstack-nova12:04
*** ralonsoh has quit IRC12:07
*** takashin has joined #openstack-nova12:08
*** tbachman has quit IRC12:08
*** tbachman has joined #openstack-nova12:09
*** psachin` has joined #openstack-nova12:09
*** adriano_ has quit IRC12:12
*** abhishekk has joined #openstack-nova12:14
*** alexchadin has joined #openstack-nova12:14
*** adriano has joined #openstack-nova12:16
*** yangyapeng has joined #openstack-nova12:17
*** ratailor has quit IRC12:18
*** alexchadin has quit IRC12:19
*** alexchadin has joined #openstack-nova12:20
*** yangyapeng has quit IRC12:22
*** lucas-hungry is now known as lucasagomes12:23
*** suresh12 has joined #openstack-nova12:27
*** suresh12 has quit IRC12:31
*** tiendc has quit IRC12:32
*** armaan has quit IRC12:37
*** edmondsw has joined #openstack-nova12:37
*** armaan has joined #openstack-nova12:38
*** alexchadin has quit IRC12:38
*** links has quit IRC12:38
*** links has joined #openstack-nova12:39
*** tetsuro has joined #openstack-nova12:39
*** yangyapeng has joined #openstack-nova12:41
*** odyssey4me has quit IRC12:44
*** _ix has quit IRC12:44
*** odyssey4me has joined #openstack-nova12:44
*** yangyapeng has quit IRC12:45
*** gyan__ has quit IRC12:47
*** yangyapeng has joined #openstack-nova12:48
*** armaan has quit IRC12:48
*** armaan has joined #openstack-nova12:49
*** gouthamr has joined #openstack-nova12:49
*** gouthamr has quit IRC12:49
*** gouthamr has joined #openstack-nova12:49
*** lyan has joined #openstack-nova12:53
*** lyan is now known as Guest3139012:54
*** armaan has quit IRC12:55
*** armaan has joined #openstack-nova12:56
*** mriedem has joined #openstack-nova12:57
*** yangyapeng has quit IRC13:03
*** yangyapeng has joined #openstack-nova13:03
openstackgerritEric Young proposed openstack/nova master: Support extending attached ScaleIO volumes  https://review.openstack.org/55467913:04
*** ralonsoh__ has joined #openstack-nova13:05
openstackgerritMerged openstack/nova master: Remove duplicative implementation of temporary directories.  https://review.openstack.org/55479113:06
*** yangyapeng has quit IRC13:08
*** ralonsoh has joined #openstack-nova13:09
*** avolkov has quit IRC13:09
*** ralonsoh_ has quit IRC13:09
*** avolkov has joined #openstack-nova13:09
openstackgerritTakashi NATSUME proposed openstack/nova master: WIP: Add notifications for removing a member from a server group  https://review.openstack.org/55907613:10
*** ralonsoh__ has quit IRC13:11
*** amoralej|lunch is now known as amoralej13:12
*** avolkov has quit IRC13:12
*** avolkov has joined #openstack-nova13:12
*** kuzko has quit IRC13:12
*** germs has joined #openstack-nova13:13
*** germs has quit IRC13:13
*** germs has joined #openstack-nova13:13
*** kuzko has joined #openstack-nova13:13
*** mvk has quit IRC13:15
*** sree has quit IRC13:17
*** sree has joined #openstack-nova13:17
*** markvoelker has quit IRC13:21
*** sree has quit IRC13:22
*** markvoelker has joined #openstack-nova13:23
*** links has quit IRC13:23
*** armaan has quit IRC13:25
*** sar has quit IRC13:25
*** armaan has joined #openstack-nova13:25
*** kuzko has quit IRC13:27
*** kuzko has joined #openstack-nova13:29
*** liverpooler has joined #openstack-nova13:29
*** ralonsoh_ has joined #openstack-nova13:29
*** david-lyle has quit IRC13:30
*** jistr is now known as jistr|mtg13:30
*** ralonsoh has quit IRC13:33
*** sar has joined #openstack-nova13:33
*** amodi has joined #openstack-nova13:33
*** pchavva has joined #openstack-nova13:34
*** yangyapeng has joined #openstack-nova13:34
*** psachin` has quit IRC13:35
*** sree has joined #openstack-nova13:36
*** pchavva1 has joined #openstack-nova13:36
*** yangyapeng has quit IRC13:39
*** sree has quit IRC13:40
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/virt/xenapi/test_vm_utils.py (1)  https://review.openstack.org/55870413:42
openstackgerritTakashi NATSUME proposed openstack/nova master: Remove mox in unit/virt/xenapi/test_vm_utils.py (2)  https://review.openstack.org/55899313:43
*** esberglu has joined #openstack-nova13:45
dansmithkashyap: found some doc issues in your patch.. fix them up and I'll fast approve13:46
* dansmith finally goes to get coffee13:47
kashyapdansmith: Hey there; thanks!  Let me look13:49
*** sar has quit IRC13:49
*** mvk has joined #openstack-nova13:52
*** tbachman has quit IRC13:52
kashyapdansmith: When you're back, can you point me to the rendered conf link?  I seem to be blind13:52
kashyapFound it: http://logs.openstack.org/84/534384/23/check/build-openstack-sphinx-docs/2f47d33/html/configuration/config.html13:53
*** hongbin has joined #openstack-nova13:54
melwittnova meeting in 5 minutes13:55
*** tbachman has joined #openstack-nova13:55
*** jackie-truong has joined #openstack-nova13:55
*** r-daneel has quit IRC13:55
kashyapdansmith: For the rendering; I am aware of it, actually even discussed on PS-2213:58
kashyapdansmith: Replied on the review.  It is a bug in oslo_config.sphinxext13:59
*** yangyapeng has joined #openstack-nova13:59
*** awaugama has joined #openstack-nova13:59
kashyapdansmith: Also the bullet rendering I use is same as the one used by 'disk_cachemodes'13:59
*** voelzmo has joined #openstack-nova13:59
dansmithkashyap: I know and it looks bad there too14:00
dansmithkashyap: as I said, the typo and the log message are the critical bits there14:00
kashyapdansmith: Right; but it'll be fixed by the oslo_config patch series I pointed out14:00
kashyapdansmith: Yep, that I already am fixing, as noted on the review :-)14:00
kashyapBut the config thing, we should leave it as-is14:00
*** sar has joined #openstack-nova14:00
kashyapstephenfin: Since we discussed this here before, can you double-confirm I don't have to re-format the config options here: https://review.openstack.org/#/c/534384/2314:01
*** kuzko has quit IRC14:01
*** moshele has joined #openstack-nova14:01
stephenfinkashyap: Yup, done14:02
*** kuzko has joined #openstack-nova14:02
kashyapstephenfin: Saw that; merci.14:03
*** yangyapeng has quit IRC14:03
stephenfinkashyap: As you noted, there are plenty other options displaying the exact same symptoms so I wouldn't block on that14:03
*** pchavva1 has quit IRC14:03
* kashyap nods14:04
*** sar has quit IRC14:05
*** mlavalle has joined #openstack-nova14:06
openstackgerritKashyap Chamarthy proposed openstack/nova master: libvirt: Allow to specify granular CPU feature flags  https://review.openstack.org/53438414:06
*** rmcall has joined #openstack-nova14:07
kashyapdansmith: When you can, fixed the two critical bits ^.  Appreciate the review!14:08
openstackgerritEric Fried proposed openstack/nova master: update_provider_tree devref and docstring updates  https://review.openstack.org/55347614:09
*** jaypipes has joined #openstack-nova14:12
*** yamahata has joined #openstack-nova14:14
*** yangyapeng has joined #openstack-nova14:18
*** yangyapeng has quit IRC14:22
*** germs has quit IRC14:23
*** germs has joined #openstack-nova14:23
*** germs has quit IRC14:23
*** germs has joined #openstack-nova14:23
*** takashin_ has joined #openstack-nova14:25
*** tbachman has quit IRC14:26
*** jistr|mtg is now known as jistr14:26
*** takashin has quit IRC14:27
*** r-daneel has joined #openstack-nova14:29
*** mchlumsky has joined #openstack-nova14:29
kashyapmelwitt: I added a quick last item on the open disucssion, if there's time, about: http://lists.openstack.org/pipermail/openstack-dev/2018-April/129048.html14:30
*** suresh12 has joined #openstack-nova14:31
*** Spaz-Work has quit IRC14:31
*** Spaz-Work has joined #openstack-nova14:36
openstackgerritsahid proposed openstack/nova master: libvirt: add support for virtio-net rx/tx queue sizes  https://review.openstack.org/48499714:37
*** felipemonteiro_ has joined #openstack-nova14:37
sahidmriedem, stephenfin, can you remove your -2 on ^ - the spec has been accepted and that could help to get more reviews14:37
*** _ix has joined #openstack-nova14:38
stephenfinsahid: Sure, done14:38
*** felipemonteiro__ has joined #openstack-nova14:39
*** yangyapeng has joined #openstack-nova14:39
mriedemsahid: done14:40
*** david-lyle has joined #openstack-nova14:40
sahidthakns14:40
*** pcaruana has quit IRC14:41
*** felipemonteiro_ has quit IRC14:42
*** yangyapeng has quit IRC14:43
openstackgerritsahid proposed openstack/nova master: libvirt: add support for virtio-net rx/tx queue sizes  https://review.openstack.org/48499714:47
*** jdillaman has quit IRC14:47
*** jackie-truong has quit IRC14:49
mriedemefried: setting CONF.neutron.auth_type is going to be required to talk to neutron using ksa right?14:50
efriedmriedem: I believe so, yes.14:50
efrieduh14:50
efriedunless you're going the admin path.14:50
mriedemthat's what i was worried about,14:50
efriedthen you're just using admin auth.14:50
mriedembut if you get here and auth_type is None, http://git.openstack.org/cgit/openstack/nova/tree/nova/network/neutronv2/api.py#n7514:50
efriedwhich is CONF.something-other-than-neutron.auth_type, I imagine.14:50
mriedemthen you've f'cked up right?14:50
efriedhum, that code shouldn't be in nova at all.  If you had no auth type, that ksa loading shoulda kicked an exception.14:51
efriedI'll have to go paw through the ksa code again, gimme a few...14:52
openstackgerritsahid proposed openstack/nova master: libvirt: add support for virtio-net rx/tx queue sizes  https://review.openstack.org/48499714:52
*** moshele has quit IRC14:52
imacdonnmriedem: on a very-slightly related note; take a peek at https://review.openstack.org/#/c/558089/ when you get a chance14:53
efriedYes, mriedem, ^ is truly excellent work :)14:53
imacdonn:)14:54
*** links has joined #openstack-nova14:54
*** suresh12 has quit IRC14:54
*** jdillaman has joined #openstack-nova14:55
*** suresh12 has joined #openstack-nova14:55
efriedmriedem: Okay, I was mistaken.  No exception; it returns None.  https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/loading/conf.py#L122-L12414:55
*** voelzmo has quit IRC14:56
mriedemefried: right, ok, point is i'm trying to know if/when i can log something useful in the logs for when you don't configure nova to talk to neutron https://bugs.launchpad.net/nova/+bug/176148714:56
openstackLaunchpad bug 1761487 in OpenStack Compute (nova) "Nova, Unexpected API Error while creating VM" [Undecided,Invalid]14:56
mriedemwe get that same bug at least weekly14:56
*** belmoreira has quit IRC14:57
efriedmriedem: This would be very similar in spirit to what imacdonn noted above.  We used to try to determine whether you'd configured placement based on whether [placement]os_region_name was present.  Which isn't the best way to do it, because that guy can default - auth_type would have been a better one to check.14:58
efriedmriedem: Which leads me to this one: you could have a similar check for neutron config.  Though I don't know whether neutron is required to make the world work, so having the check up front may be too aggressive.14:58
efriedmriedem: But yeah, you could at least make that error message that you pointed out more clear.14:59
efriedmriedem: "You need to configure the [neutron] section of your conf with ksa Adapter options."14:59
efriedkind of thing.14:59
*** yangyapeng has joined #openstack-nova14:59
zigoo/15:00
mriedemneutron is required yeah, because we assume port binding is available in neutron and the port binding extension is an admin-only extension by default15:00
kashyapzigo: Hi there ... so to follow-up, all the distributions in the DistroSupportMatrix have libvirt 3.8.0 and QEMU 2.9.015:00
*** abhishekk has quit IRC15:00
mriedemefried: so i'll start small with that kind of log message if we hit this,15:00
zigoI haven't tried backporting libvirt & qemu to Stretch, could you give me some time so I can tell if it's painful or not?15:00
kashyapzigo: This is the wiki: https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix15:00
efriedmriedem: ++15:00
*** ratailor has joined #openstack-nova15:00
mriedemefried: and i also noticed during triage of that bug that our install guide, at least for ubuntu, doesn't tell you that you need to configure nova with neutron creds15:00
*** suresh12 has quit IRC15:00
kashyapzigo: Sure.  Please respond here: http://lists.openstack.org/pipermail/openstack-dev/2018-April/129048.html15:00
zigoWill do.15:00
zigoI should be able to give an answer tomorrow.15:01
kashyapzigo: I spent a couple of hours duking around various Debian packaging URLs & wrote that up15:01
kashyapThanks!15:01
zigo(today, got 2 hours driving back home from work in Geneva)15:01
mriedemdansmith: https://review.openstack.org/#/c/555416/ is ready to go if you want to re-apply your +215:01
tssuryathanks ^^15:01
* dansmith is in his second meeting of the morning15:02
*** Swami has joined #openstack-nova15:03
*** takashin_ has left #openstack-nova15:03
*** tetsuro has left #openstack-nova15:03
* melwitt realizes she has the same meeting15:03
*** yangyapeng has quit IRC15:04
*** tbachman has joined #openstack-nova15:04
mriedemtssurya: unrelated, but would you mind pushing a simple patch to add a .. note:: to http://logs.openstack.org/59/556459/9/check/build-openstack-sphinx-docs/66f4bf4/html/admin/configuration/schedulers.html#cell-filters that those filters are only for cells v1 which is deprecated15:05
*** sar has joined #openstack-nova15:05
tssuryamriedem: sure, looking at it now..15:06
*** links has quit IRC15:06
*** tbachman_ has joined #openstack-nova15:06
*** voelzmo has joined #openstack-nova15:06
*** tbachman has quit IRC15:08
*** tbachman_ has quit IRC15:09
zigokashyap: You can just scrap Jessie from your table, it's unsupported already, and maybe add Sid.15:12
zigoThat's what counts for me.15:12
kashyapzigo: "Sid" == Testing / unstable, isn't it?15:12
kashyapzigo: Isn't it "Buster" that's the upcoming release?15:12
* kashyap learnt a bit too much (?) about Debian release structure last week :P15:13
zigokashyap: Generally, we have sid == buster, package migrate in 5 days from Sid to Buster if there's no RC bug.15:13
kashyapzigo: "Also ... it's a wiki, feel free to update it" :-)15:13
zigo:)15:13
kashyapzigo: When I checked earlier this week, there was no ETA for Buster (love saying it out loud)15:14
zigoSure, that's what Debian is about: it's ready when it's ready, no commercial agenda.15:14
bauzasdansmith: mriedem: melwitt: FYI, I had a family loss this week, so I won't be around tomorrow15:14
zigoWhat's surprising is that there's still no freeze date.15:14
kashyapzigo: Either way, if you see, we're trying to converge on a reasonable least common denonimnator version for libvirt / QEMU across releases15:14
*** moshele has joined #openstack-nova15:14
dansmithbauzas: ack :(15:14
zigoI guess the release team has a few more transition to get done before announcing the freeze date.15:14
bauzashence also me not around this afternoon :(15:15
melwittsorry to hear that bauzas :(15:15
zigobauzas: Oh, sorry to read that. Moral support and all...15:15
kashyapbauzas: Take care of that; IRC can wait15:15
* zigo sends a virtual free hug to bauzas15:15
bauzasnp, it was my grand father who was 9115:15
*** sree has joined #openstack-nova15:16
openstackgerritSurya Seetharaman proposed openstack/nova master: Update the Cell filters section of the scheduler docs  https://review.openstack.org/55910815:19
*** sree has quit IRC15:20
*** yangyapeng has joined #openstack-nova15:20
tssuryamriedem: ^15:21
*** andreas_s has quit IRC15:23
*** yangyapeng has quit IRC15:25
mriedembauzas: ack; making it that long is a feat15:25
bauzasyup, and with a way to leave us quickly without illness15:26
bauzasjust because the body stopds15:26
bauzasI just hope everyone can leave the world like him15:26
openstackgerritMatt Riedemann proposed openstack/nova master: Log a more useful error when neutron isn't configured  https://review.openstack.org/55911115:27
openstackgerritSurya Seetharaman proposed openstack/nova master: Update the cells FAQs and scheduler maintenance docs.  https://review.openstack.org/55645915:27
*** andreas_s_ has joined #openstack-nova15:28
*** jackie-truong has joined #openstack-nova15:30
mriedemtssurya: thanks, +215:30
*** chyka has joined #openstack-nova15:31
*** moshele has quit IRC15:32
*** andreas_s_ has quit IRC15:32
mriedemmelwitt: i meant to point this out in the meeting, but i noticed it after the bugs and gate CI part - i saw some very weird and random looking failures in the functional job in what looks to be an unrelated change http://logs.openstack.org/12/555812/5/gate/nova-tox-functional/94dc121/testr_results.html.gz15:32
*** ratailor has quit IRC15:33
melwitthm, that looks plenty weird15:33
*** openstackgerrit has quit IRC15:34
mriedemdansmith: was "limestone" the cloud provider that was timing out yesterday?15:36
dansmithmriedem: yar15:36
mriedembecause that's the one this functional job above seems to hit15:36
mriedemyeah ok so that's probably all it was15:36
*** sapd has quit IRC15:36
mriedemmelwitt: nvm then15:36
*** sapd has joined #openstack-nova15:36
melwitta-ha, cool15:37
*** andreas_s has joined #openstack-nova15:38
stephenfinsean-k-mooney: I recall a blueprint that would allow us to determine what networking backend was running on a host (I guess so you could mix hosts OVS-DPDK and OVS kernel). Got a link, if so?15:42
* stephenfin has hardware again and is trying to find a way to make NUMA-aware vSwitch less icky15:42
mriedemstephenfin: wouldn't that information be in the port's host binding details?15:43
*** andreas_s has quit IRC15:43
stephenfinmriedem: Possibly, but we don't do any of that stuff until we land on a host, far as I can tell15:46
*** jackie-truong has quit IRC15:46
stephenfinOnly thing we do do (heh) is prepare a PCIRequest object for any SR-IOV requests15:47
*** pcaruana has joined #openstack-nova15:47
stephenfinbauzas: Sorry to hear it :(15:48
bauzasstephenfin: no worries, it was expected15:48
sean-k-mooneymriedem: that info is not in the port until after binding15:48
sean-k-mooneystephenfin: i dont think it was in a seperat spec but it was part of the bandwith based scheduling spec15:49
stephenfinsean-k-mooney: Hmm, OK. Was hoping I could steal some ideas from said spec15:49
*** Spaz-Work has quit IRC15:49
sean-k-mooneythe intent was to use traits for neturon extention or backend to select the backend. the trati would be added to the neutron port resouce reuest15:50
stephenfinSo you'd be querying placement?15:50
sean-k-mooneystephenfin: well you can proably steal them from the bandwith spec.15:50
sean-k-mooneystephenfin: yes15:50
sean-k-mooneyor rather its addtional info that is included with nova queries placement15:51
stephenfinDarn, it all comes back to placement15:51
*** armaan has quit IRC15:51
*** armaan has joined #openstack-nova15:51
sean-k-mooneystephenfin: i did have a proposal to do this with a neutron api for network backend capablities in mitaka before placement but that never went anywhere outside intel15:52
stephenfinYeah, so NUMA stuff. I naturally want to be able to do this stuff in the scheduler but I don't have enough information at that point to make a decision15:52
*** openstackgerrit has joined #openstack-nova15:52
openstackgerritMatt Riedemann proposed openstack/nova master: doc: add a link in the install guides about configuring neutron  https://review.openstack.org/55911515:52
stephenfinI can figure out what network I have but then I need to map that network to a given NUMA node15:53
*** sahid has quit IRC15:53
stephenfinand that information lives on each individual host, either as a configuration option or something else15:53
sean-k-mooneystephenfin: well you can have enough info in the schduler if you populated it in the host state object. placement does not know about it however unlees the compute agent puts it in placement too15:53
stephenfinso it looks like I'm going to have to pass it back to the scheduler via the host state object, which I'm not sure I want to do15:54
*** Swami has quit IRC15:54
stephenfinsean-k-mooney: yup, exactly15:54
*** damien_r has quit IRC15:54
sean-k-mooneystephenfin: i had assumed you were going to addd the network stuff to the numa topology blob15:54
*** dklyle has joined #openstack-nova15:55
openstackgerritMatt Riedemann proposed openstack/nova master: doc: add a link in the install guides about configuring neutron  https://review.openstack.org/55911515:55
sean-k-mooneyso the compute agent would read the config opptions and populated the numa info for the backend into the numatopology blob then the numa topology filter which gets that blob in the host_State object can make desions about the host15:55
*** efried has quit IRC15:56
openstackgerritMatt Riedemann proposed openstack/nova master: Update the cells FAQs and scheduler maintenance docs.  https://review.openstack.org/55645915:57
*** david-lyle has quit IRC15:57
stephenfinsean-k-mooney: Hmm, I hadn't considered that. I'd been adding additional fields and then got stuck because I had a network from the user and physnet name from the host15:57
sean-k-mooneystephenfin: your only other option bar modleing it in placement which is the long term answer is to not scheduler based on the numa constriats and retry if you cannont fit the insance on the compute node that was selected15:57
stephenfin*I had considered that but...15:57
sean-k-mooneystephenfin: well you have more then the network15:58
sean-k-mooneyyour stuff assumed that the vm was booted with a nuton port15:58
stephenfinso network and port IDs15:59
stephenfin?15:59
*** tesseract has quit IRC15:59
*** tbachman has joined #openstack-nova15:59
sean-k-mooneyin that case we already pull back the full neutron port object to check if its an sriov port15:59
sean-k-mooneyso you can ask neutron for the physnet and put that in the instance request object15:59
sean-k-mooneyyou can also determin if its a tunneled/routed port16:00
stephenfinsean-k-mooney: Yup, I've been charting that this afternoon :D http://paste.openstack.org/show/718499/16:00
sean-k-mooneystephenfin: thats how the nic feature based schduling works :)16:01
stephenfinralonsoh_'s patches?16:01
sean-k-mooneyyep16:01
stephenfin(I've been meaning to re-review those but they were failing CI last I checked)16:01
sean-k-mooneywe extend the pci requst spec object to carry the feature flags16:02
*** FL1SK has quit IRC16:02
*** voelzmo has quit IRC16:02
sean-k-mooneystephenfin: i belive the bandwidth spec was suggestion adding an arry of networkRequstsSepcs to the instance request object16:02
stephenfinI need to reread that one too so. That's exactly what I'd done16:03
*** tbachman has quit IRC16:03
sean-k-mooneystephenfin: oh and i started rebasing  rodoflos patches yesterday16:04
stephenfinOnly, like I said, it seemed useless to me because I didn't want to be querying neutron for more information from the scheduler16:04
sean-k-mooneyi hope to have them back up tomrowo or monday16:04
stephenfinsean-k-mooney: Sounds good. I can review once they're done16:04
stephenfin*ready16:04
*** tbachman has joined #openstack-nova16:04
stephenfinsean-k-mooney: I'll push up what I have probably some time tomorrow16:05
stephenfinTry not to laugh too hard. It's strewn with TODOs :D16:05
sean-k-mooneywell i broke them more in the refactor. once they are back passing unuit test i will need to do some more testing with real hardware so they wont be "ready" untill later next week but they can still be reviewed16:05
stephenfinYeah, that's fine. I can do some basic validation too16:05
stephenfin...given that I actually have hardware again16:06
sean-k-mooneywell im currently doing the rebase work in a vm so need to deploy on real hard ware to test after that is done.16:06
*** efried has joined #openstack-nova16:07
*** tbachman has quit IRC16:10
*** AlexeyAbashkin has quit IRC16:10
*** tssurya has quit IRC16:11
*** tbachman has joined #openstack-nova16:12
mriedemefried: imacdonn: i've updated https://review.openstack.org/#/c/554577/ to depend on your nova change16:12
efriedmriedem: cool16:13
*** lpetrut has quit IRC16:15
*** pcaruana has quit IRC16:16
*** FL1SK has joined #openstack-nova16:17
*** mdbooth has quit IRC16:18
*** mvk has quit IRC16:22
*** yangyapeng has joined #openstack-nova16:22
*** esberglu_ has joined #openstack-nova16:22
*** esberglu has quit IRC16:25
*** felipemonteiro__ has quit IRC16:26
*** felipemonteiro__ has joined #openstack-nova16:26
*** yangyapeng has quit IRC16:27
mriedemkashyap: holy wow everything volume-related failed in your patch http://logs.openstack.org/84/534384/24/check/tempest-full/c7c0cbe/16:30
mriedemcongratulations on breaking cinder16:30
* kashyap blinks and looks16:30
* kashyap was cleaning up downstreams; give me a sec to context-switch16:30
kashyapmriedem: I suppose you're referring to: https://review.openstack.org/#/c/558783/16:31
mriedemit's not related to your patch, just looks like c-vol is having a very bad time http://logs.openstack.org/84/534384/24/check/tempest-full/c7c0cbe/controller/logs/screen-c-vol.txt.gz?level=TRACE16:31
kashyap?16:31
mriedemno16:31
mriedemhttps://review.openstack.org/#/c/534384/16:31
kashyapAh, that one16:31
kashyapmriedem: I go do a plain 'recheck', or does it require a more deeper incantation?16:32
mriedemjust recheck it16:32
* kashyap wants to be mindful of not wasting CI resources16:32
kashyapDone16:32
kashyapmriedem: Too eager to jump the gun, eh :P16:33
melwitttriaging this bug about disk_available_least going negative for an image-based instance with 0 GB disk flavor. proposal is to reject such requests with 400 (which would require a microversion, I think). additional thoughts welcome https://bugs.launchpad.net/nova/+bug/175827816:34
openstackLaunchpad bug 1758278 in OpenStack Compute (nova) "disk_available_least become a negative value unexpectedly" [Undecided,New]16:34
kashyapdansmith: Thanks for the fast-approve, and the eagle eyes, as usual.16:36
*** udesale has quit IRC16:36
jaypipesefried, pls see my response on https://review.openstack.org/#/c/55687316:38
efriedjaypipes: ack16:38
mriedemdansmith: if you're done with your meeting, this will close out the cell-disable bp https://review.openstack.org/#/c/556459/16:39
mriedemjust the final docs patch16:39
*** lucasagomes is now known as lucas-afk16:42
*** bigdogstl has joined #openstack-nova16:46
*** sree has joined #openstack-nova16:48
*** armaan has quit IRC16:48
*** bigdogstl has quit IRC16:49
melwittcan someone remind me, in this last comment from belmiro, did he mean cells v2 instead of cells v1 or? https://bugs.launchpad.net/nova/+bug/176119716:51
openstackLaunchpad bug 1761197 in OpenStack Compute (nova) "Not defined keypairs in instance_extra cellsV1 DBs" [Undecided,New] - Assigned to Surya Seetharaman (tssurya)16:51
*** fragatina has joined #openstack-nova16:54
*** fragatina has quit IRC16:55
*** fragatina has joined #openstack-nova16:56
*** derekh has quit IRC16:58
openstackgerritArvind Nadendla proposed openstack/nova master: Update ImageMetaProp object to expose traits  https://review.openstack.org/55779517:01
*** jmlowe has joined #openstack-nova17:01
arvindn051dansmith: jaypipes: updated code per comment(changed name of the field)17:02
*** sree has quit IRC17:02
*** fragatina has quit IRC17:03
*** ralonsoh_ has quit IRC17:04
*** ccamacho has quit IRC17:04
*** hongbin has quit IRC17:07
*** mgoddard has quit IRC17:10
*** mchlumsky has quit IRC17:10
*** armaan has joined #openstack-nova17:11
*** sree has joined #openstack-nova17:11
*** dklyle has quit IRC17:13
jaypipesdansmith: you good with it, I'm good with it.17:14
dansmithI'm under a pile of other stuff right now,17:14
dansmithhence me ignoring pings17:14
dansmithsorry17:14
*** abhishekk has joined #openstack-nova17:15
dansmithwill look later17:15
jaypipesdansmith: no worries. I left a +2 on it.17:15
*** jpena is now known as jpena|off17:16
*** sree has quit IRC17:16
*** mchlumsky has joined #openstack-nova17:18
*** hongbin has joined #openstack-nova17:18
*** david-lyle has joined #openstack-nova17:18
*** tssurya has joined #openstack-nova17:18
*** janki has quit IRC17:19
*** harlowja has joined #openstack-nova17:21
*** jmlowe has quit IRC17:21
*** fragatina has joined #openstack-nova17:22
*** suresh12_ has joined #openstack-nova17:25
*** harlowja has quit IRC17:25
sean-k-mooneyjaypipes: just thinking back over your cpu spec and some of the other granualr requests discussions. have we finalised on the fact that numbered request groups will be guraenteed to be form different RPs17:26
*** felipemonteiro_ has joined #openstack-nova17:27
*** suresh12_ has quit IRC17:29
efriedsean-k-mooney: Nobody has proposed a spec change17:29
*** suresh12 has joined #openstack-nova17:30
*** tbachman has quit IRC17:30
sean-k-mooneyefried: hum ok in the current form if they are in the same request group are all resouces in that group required form the same subtree?17:31
*** felipemonteiro__ has quit IRC17:31
sean-k-mooneyefried: ill read the sepc to confim just tought i would ask if you knew off the top of your head17:31
efriedif in the same numbered request group, they'll land in the same provider17:32
*** suresh12 has quit IRC17:32
*** suresh12 has joined #openstack-nova17:32
efriedin the unnumbered group, can be spread around the tree17:32
sean-k-mooneyefried: same provider or "same proviers or one of its childern"17:32
melwitttssurya: in this bug in belmiro's last comment, did he mean keypair isn't in instance_extra with cells v2? the comment says "cells v1" https://bugs.launchpad.net/nova/+bug/176119717:33
openstackLaunchpad bug 1761197 in OpenStack Compute (nova) "Not defined keypairs in instance_extra cellsV1 DBs" [Undecided,New] - Assigned to Surya Seetharaman (tssurya)17:33
*** mdnadeem has quit IRC17:34
efriedsean-k-mooney: same provider.  The only thing we have today (impl or design) that uses children is the concept of grouping as a tree.  Nothing in placement deals with hierarthies or branches or subtrees etc17:34
*** AlexeyAbashkin has joined #openstack-nova17:34
efriedhierarchies, that is17:34
melwittfwiw, I checked a recent devstack of mine and see keypairs in instance_extra in the nova_cell1 database, so if there's a bug in ocata, it looks like it got fixed somehow later17:35
*** armaan has quit IRC17:35
melwitt(assuming cells v2 was what he meant)17:35
sean-k-mooneyefried: so you can never have a numbered resouce group containig CPUs and virtual fucntions and find a host as they will be from diffrent RPs in a subtree of a compute host17:36
tssuryamelwitt: no its in cellsv1 that we have this issue17:36
melwitttssurya: ah, okay. thanks for confirming17:36
jaypipessean-k-mooney: that is correct.17:37
jaypipessean-k-mooney: and we are aware that is a problem.17:37
sean-k-mooneyjaypipes: ok17:37
efriedsean-k-mooney: That's correct, given your premise.17:37
*** lpetrut has joined #openstack-nova17:37
openstackgerritMerged openstack/nova master: Add nova-status check for ironic flavor migration  https://review.openstack.org/52754117:38
tssuryano problem :), yea its a weird thing happening between the two migrations in newton, one moving keypairs from the cellsDB keypairs table to instance_extra.keypairs and two moving the instance_extra.keypairs up to the apidb17:38
tssuryaand for the new instance currently created we don't have any instance_extra.keypairs and instance_extra.vcpu_models17:38
tssuryainstances**17:38
sean-k-mooneyi was talking to xlinx at the ptg after teh cyborg session ended. they reached out to me during the week to follow up and i suggested a solution that should still work for them provided we require they come form the same provider17:38
*** AlexeyAbashkin has quit IRC17:38
sean-k-mooneyefried: jaypipes  it would still work with subtrees potetailly but it may also not17:39
*** gjayavelu has joined #openstack-nova17:40
melwitttssurya: yeah ... the way cells v1 works is it will write the instance data to the API level DB first, then sync the instances table down to child cell, and I assume instance_extra must not be part of that17:41
melwittso you'll never see instance_extra in child cells AFAIK17:42
tssuryayes , this is what we are also thinking17:42
tssuryaI mean we have instance_extra, but some fields are not being synced17:42
melwittoh, so some fields and not others17:43
tssuryayea17:43
mriedemjaypipes: dingers on that image meta props traits change17:43
melwittthat would make sense if some writes are initiated while already in the child cell17:43
tssuryalike for now we know for sure instance_extra.keypairs and instance_extra.vcpu_models are not syncing17:43
melwittI see17:43
sean-k-mooneytssurya: were you discussing this with dansmith yesterday? someone else was having issues with cellsv1 and instance_extra17:44
tssuryasean-k-mooney: yes belmiro was talking about this17:45
sean-k-mooneytssurya: ah yes17:45
tssuryawe are from the same team at CERN (he is my supervisor :D)17:45
sean-k-mooneytssurya: he will be happy to know your contunuing to follow up so17:45
tssuryasean-k-mooney: :)17:46
openstackgerritEric Fried proposed openstack/nova master: [placement] Fix incorrect exception import  https://review.openstack.org/55891617:46
efriedmriedem, melwitt: ^17:50
mriedemo17:51
mriedemalready looking at it17:51
*** bigdogstl has joined #openstack-nova17:51
mriedemagree with all of your comments about mock usage in PS2 btw17:51
jaypipesmriedem: honestly, if some operator sets an image property called traits_required=foo, I really don't care.17:52
jaypipesmriedem: traits were all about trying to standardize this mess of completely random string key/values.17:52
jaypipesmriedem: we can add all the unit tests you want for these edge cases, but I don't feel they add much value. Just MHO.17:53
arvindn051btw, since we call _set_attr_from_trait_names method after the _set_attr_from_current_names, i can just overwrite over the other property just to be safe17:54
*** bigdogstl has quit IRC17:56
melwittowalsh: do you know if/how things got resolved here? https://bugs.launchpad.net/nova/+bug/171791517:56
openstackLaunchpad bug 1717915 in oslo.messaging "nova services and transport_url, cannot connect to vhost if specified" [Undecided,New]17:56
arvindn051i currently just have a check if "'traits_required' not in self" i can also check for if traits_required is also not a list, then i overwrite it...would that make sense?17:56
jaypipesafter a certain point, I just don't feel like doing any reviews -- or at least don't feel like leaving any *positive* reviews. seems like we go out of our way sometimes to -1 for things that just aren't particularly important.17:57
jaypipesefried: speaking of negative reviews... what is the current status on the whole "use case" around granular request groups *not* meaning that the resource providers will be different for each group?17:58
*** amoralej is now known as amoralej|off17:59
arvindn051jaypipes: just taking it as constructive criticism...you guys have been at this a lot more than i have :)17:59
efriedjaypipes: I recently wrote up a decent synopsis in a spec review.  Finding...18:00
arvindn051i am sure there are more edge cases...but if we want to guard against known one by adding few lines of code...should be fine18:00
jaypipesefried: since I "solved" that "use case" with the whole "sum the inventories for like resource classes for a tree" and that was -1'd by you (https://review.openstack.org/#/c/534339/) because it would not make sense ("No, I think that, under the current design, if you want two VFs, you should specify them in separate granular request groups, even if they're identical, so that you'll still get a viable candidate in the18:01
jaypipesscenario described for this test case.")18:01
efriedjaypipes: https://review.openstack.org/#/c/555081/4/specs/rocky/approved/cpu-resources.rst@412 while I go read that...18:02
jaypipesarvindn051: I'm referring to my own frustration... not even considering whether you may or may not be frustrated by the constant back and forth (I would be if I were you)18:02
*** Spaz-Work has joined #openstack-nova18:02
jaypipesefried: yeah, I've read that over and over. And it directly contradicts your own statement on the sum resources patch.18:03
efriedjaypipes: Sorry, which statement/patch?18:04
mriedemarvindn051: if you want to handle the edge case check in a follow up that's fine with me18:05
arvindn051jaypipes: thanks. i am just starting out with contributing to the project...so learning pains is how i am taking it. So close to getting it checked in :)18:05
jaypipesefried: "No, I think that, under the current design, if you want two VFs, you should specify them in separate granular request groups, even if they're identical, so that you'll still get a viable candidate in the scenario described for this test case."18:05
mriedemarvindn051: add the check on top and i'll approve this18:05
*** dtantsur is now known as dtantsur|afk18:06
efriedjaypipes: We talked about that some more in IRC afterwards IIRC, and I gave up on the idea that we would separate out the *results* for that kind of request.  But there's nothing contradictory there.  Specifying two identical VFs in separate numbered request groups allows you to get viable results whether you have (available inventory in) one PF or multiple.18:07
efriedjaypipes: I also realized later that we can't separate out the results without changing the response format, because dict.18:08
*** pcaruana has joined #openstack-nova18:08
efriedjaypipes: So I accepted that, in such cases where placement had to combine those results, the caller would have to pick them apart again (based on their request, I guess).18:08
efriedjaypipes: In any case, like I said in that comment, we're going to need both semantics at some point.  It's just a matter of which one is the default.18:09
*** amodi has quit IRC18:09
efriedSomeone who feels strongly that it should be opposite to what's in the spec should propose an amendment to that spec.18:10
efriedand/or an addition to the syntax that will enable the other.18:10
openstackgerritMatt Riedemann proposed openstack/nova master: [placement] Fix incorrect exception import  https://review.openstack.org/55891618:10
efriedmriedem: Do I get to +2 this again now?  ^  :P18:11
efried(jk, need to wait for melwitt to relook anyway)18:11
mriedemefried: i'm sure melwitt would be fast to hit it18:11
*** david-lyle has quit IRC18:11
efriedI can't believe I made a typo on the word whose typo I was fixing.18:12
melwittyeah geez yall18:12
efriedI blame the one-handed dvorak typing because fried chicken in the other hand.18:12
melwittfried chicken, good excuse18:13
jaypipesefried: from the spec: "* For both numbered and un-numbered ``resources``, a single18:13
jaypipes  *resource_class*:*count* will never be split across multiple RPs.18:13
jaypipes  While such a split could be seen to be sane for e.g. VFs, it is clearly not18:13
jaypipes  valid for e.g. DISK_GB.  If you want to be able to split, use separate18:13
jaypipes  numbered groups."18:13
*** voelzmo has joined #openstack-nova18:13
*** abhishekk has quit IRC18:14
jaypipesefried: that, I believe, is the source of much confusion.18:14
*** bigdogstl has joined #openstack-nova18:15
*** vladikr has quit IRC18:15
*** avolkov has quit IRC18:16
melwittguh the server_group func tests are such a thorn in our side. another random failure http://logs.openstack.org/84/534384/24/check/nova-tox-functional/94444cd/testr_results.html.gz18:16
*** vladikr has joined #openstack-nova18:16
efriedjaypipes: How is that unclear?18:16
*** hongbin has quit IRC18:16
efriedIf it said, "If you want to split," instead of "If you want to *be able to* split," perhaps.18:17
efriedAnd the third bullet in that same list is clear.18:18
*** bigdogstl has quit IRC18:20
jaypipesefried: I strongly disagree that this is clear. otherwise we wouldn't have such strong disagreement about what was meant.18:20
jaypipesmelwitt: s/server_group func tests/server_group/18:21
melwittfair :)18:22
efriedThere wasn't disagreement about what was meant.  People either didn't care at the time, or changed minds afterwards.18:22
openstackgerritEric Berglund proposed openstack/nova master: WIP: PowerVM: Cold Migrate & Resize  https://review.openstack.org/55358318:22
efriedI'll grant that part of the problem may have been "too many words in spec".  I've been working on that issue in subsequent specs.18:23
*** huanxie has joined #openstack-nova18:23
jaypipesefried: or thought it meant one thing when in actuality it meant another.18:24
*** hongbin has joined #openstack-nova18:24
efriedI'm sure I'm having trouble seeing it because I wrote it, but to me this is crystal: "Separate groups (numbered or un-numbered) may return results from the same RP. That is, you are not guaranteeing RP exclusivity by separating groups. (If you want to guarantee such exclusivity, you need to do it with traits.)"18:25
jaypipesefried: it's a subtle but extremely important distinction that "use_same_provider=True" meant (for you) that the resources from the single request group would be met by the same provider, which dansmith and I thought it meant that the resources in granular request groups would be met by different providers.18:25
openstackgerritMerged openstack/nova master: Use a pythonic delete.  https://review.openstack.org/55479218:26
odyssey4meHi everyone. I wonder if someone could help just verify whether this is normal or not. I'm trying to use the openstack client to disable a service, but it errors out. This is on a test environment which was deployed with Pike, then upgraded to Queens. I've tried this with the scheduler, consoleauth and conductor services, all with the same result.: https://gist.github.com/odyssey4me/5cec9c69dcf0f118f7a62464df64b480#file-output-log-L7418:26
jaypipesodyssey4me: hi Jesse, yes, that's normal. you need to reconcile your cell to host mappings.18:26
efriedwe're talking about the code now?  (Cause use_same_provider isn't part of the spec.)  There's no way use_same_provider=True could be construed (or even used) to signify anything *between* request groups.18:26
jaypipesefried: use_same_provider=False is set on numbered request groups.18:27
jaypipesefried: which makes it seem that resource providers will not be the same for each numbered request group.18:27
odyssey4mejaypipes apologies for my ignorance - what exactly does that mean? got a doc link or something for me?18:27
efriedvice versa jaypipes18:27
jaypipesefried: I'm not saying you meant to cause this confusion, just that it obviously is confusing to some people.18:28
efried        :param use_same_provider:18:28
efried            If True, (the default) this RequestGroup represents requests for18:28
efried            resources and traits which must be satisfied by a single resource18:28
efried            provider.  If False, represents a request for resources and traits18:28
efried            in any resource provider in the same tree, or a sharing provider.18:28
jaypipesodyssey4me: yeah, sec, grabbing one18:28
efriedTo put it in context, though, a RequestGroup is *one* request group.  This says nothing of how this RequestGroup interacts with other RequestGroups.18:28
*** harlowja has joined #openstack-nova18:29
jaypipesodyssey4me: https://docs.openstack.org/nova/latest/cli/nova-manage.html#nova-cells-v218:29
odyssey4metyvm, appreciate your time jaypipes18:29
jaypipesodyssey4me: also try this:18:29
jaypipeshttps://docs.openstack.org/nova/latest/cli/nova-status.html#upgrade18:29
jaypipesnova-manage status check18:29
odyssey4meooh, a new command :)18:30
jaypipesodyssey4me: sorry, that should have been nova-status upgrade check18:30
odyssey4mewith return codes and everything, fancy :)18:31
odyssey4meyeah, got that - it says all is well18:31
jaypipesodyssey4me: you can thank mriedem for it.18:31
mriedemi think that's microversion 2.53 you're hitting18:32
odyssey4memany thanks to mriedem then - we shall make use of this in ways similar to keystone doctor18:32
*** armaan has joined #openstack-nova18:32
mriedemodyssey4me: the services API only allows enabling/disabling 'compute' services once you're on cells v218:32
mriedemb/c those compute service are mapped to a cell in the api db, but other non-compute services aren't18:32
mriedemplus,18:32
mriedemit doesn't make sense to disable non-compute services, as that doesn't mean/do anything18:32
odyssey4meok, then something's probably wrong in our config or something - because this started life as pike, so cellsv2 should have just been there from the start18:33
mriedemodyssey4me: https://docs.openstack.org/releasenotes/nova/pike.html#id2318:33
mriedemThe PUT /os-services/disable, PUT /os-services/enable and PUT /os-services/force-down APIs to enable, disable, or force-down a service will now only work with nova-compute services. If you are using those APIs to try and disable a non-compute service, like nova-scheduler or nova-conductor, those APIs will result in a 404 response.18:33
odyssey4meoh doesn't it? I'm trying to do a nice process of disable, then shut down, then wipe the containers18:33
mriedemcheck that release note18:34
odyssey4meaha, I see18:34
jaypipesefried: could you please explain to me your comment on https://review.openstack.org/#/c/534339/ then? If I have a single compute node with 2 PFs with 2 SRIOV_NET_VFs, and I request 4 SRIOV_NET_VF, how exactly are you proposing that we determine that that compute node is a good match for the request?18:34
odyssey4meso I shouldn't be so nice and just wipe them :)18:34
efriedjaypipes: stand by18:34
odyssey4meok, many thanks - it makes much more sense now.. effectively it's no longer a thing, so don't do it18:35
mriedemodyssey4me: likely a relic of your upgrade tooling18:35
mriedemworked going from pre-cellsv2 to cellsv2, but not cellsv2+18:35
mriedemand yeah, was never a use in disabling / enabling non-compute services18:36
efriedjaypipes: I'm not sure which comment you're referring to, but to answer this: "If I have a single compute node with 2 PFs with 2 SRIOV_NET_VFs, and I request 4 SRIOV_NET_VF, how exactly are you proposing that we determine that that compute node is a good match for the request?"18:36
efriedjaypipes: Without knowing beforehand whether the compute node has one PF or two or four, or how many VFs are available on any of them, the most flexible way to issue that request and have the highest chance of landing *somewhere* would be: resources1=VF:1&resources2=VF:1&resources3=VF:1&resources4=VF:118:38
efriedthat's of course assuming there are no traits in play (which in the case of PFs there likely would be, to represent nets or whatever)18:38
*** liverpooler has quit IRC18:39
efriedOne can envision a HAWeigher that would prefer results that were "spread".  Etc. etc.18:39
*** david-lyle has joined #openstack-nova18:40
jaypipesefried: wow...18:42
jaypipesefried: and what about DISK_GB? if we don't get a single provider that has 1024 GB of disk space from a single disk, do we break the request into two requests for 512 MB from two different resource providers?18:42
efriednot unless you want two disks.18:43
jaypipesefried: the resource is not a disk. The resource is DISK_GB. i.e. an amount of GB of disk space.18:43
*** suresh12 has quit IRC18:43
efriedRight.  Point is that the *caller* understands the semantics of that, though.  Not placement.18:43
*** suresh12 has joined #openstack-nova18:44
efriedSo if you want two 512GB disks, you say resources1=DISK_GB:512&resources2=DISK_GB:512.  They may come from the same provider (which will respond with DISK_GB:1024 and you'll have to go back to your request to figure out that you wanted to split it up) or they may come from separate providers.18:44
*** liverpooler has joined #openstack-nova18:44
efriedIt would be nice if the user didn't have to know that the systems in the cloud have one disk or ten, on PF or eight, etc.  He just wants his instance to land.18:45
efriedOr maybe that's wrong.  Maybe there needs to be tight coupling between the flavors and the exact topology of the cloud.18:46
efriedbut that doesn't seem very... cloudy to me.18:46
*** suresh12 has quit IRC18:46
*** suresh12 has joined #openstack-nova18:46
jaypipesefried: I just want to make sure we're tackling real-world problems.18:46
efriedokay: what's the real-world problem that demands separation?  NUMA?18:47
jaypipesefried: I don't believe that there is a viable use case for a request for 4 SRIOV VFs and the requester doesn't care whether the VFs are provided by a single PF or two PFs.18:47
*** pcaruana has quit IRC18:47
efriedFWIW, we implemented exactly that use case in powervm for SR-IOV.18:47
efriedFor HA.18:48
jaypipesefried: when does a requester of SRIOV VFs *not* want HA?18:48
openstackgerritMerged openstack/nova master: Avoid showing password in log  https://review.openstack.org/55869418:48
openstackgerritMerged openstack/nova master: Add __repr__ for NovaException  https://review.openstack.org/55581218:49
efriedWhen there's only one PF available.18:49
jaypipesefried: if there's only one PF available, and the image/flavor needs >1 SRIOV VF, then IMHO, that compute node with only a single PF shouldn't be a legit destination node.18:50
efriedjaypipes: If I don't care about HA, and I said resources1=SRIOV_NET_VF:1&required1=CUSTOM_PHYSNET_A&resources2=SRIOV_NET_VF:1&required2=CUSTOM_PHYSNET_B (because that's the only way I can get two VFs on separate physnets), and I was *forced* to use two separate PFs to make that happen, I would not be able to land an instance on a node with just one PF.18:50
jaypipesefried: the whole purpose of having multiple VFs is to allow active/failover for links...18:50
efriedWhen HA is the issue, yes.18:50
*** salv-orl_ has quit IRC18:53
*** efried1 has joined #openstack-nova18:53
*** salv-orlando has joined #openstack-nova18:53
*** awaugama has quit IRC18:54
*** efried has quit IRC18:54
*** efried1 is now known as efried18:54
jaypipeswelcome back18:54
*** tbachman has joined #openstack-nova18:55
efriedWas that my glitch or a server thing?18:56
efriedDid I miss stuff?18:56
efriedHere's what I was about to say:18:56
*** salv-orlando has quit IRC18:57
efriedLook, I'm (still) not arguing that there are cases where it will be useful to force split.  I'm (still) asserting that we're going to need to be able to handle both.  One behavior will be the default, and the other will require some extra syntax to make it happen.  I'm not convinced we truly need *either* immediately.  So I've been advocating for the default being the one that's in the spec, because that's the one that make18:58
efriedhead since Denver.  But as I said here https://review.openstack.org/#/c/555081/4/specs/rocky/approved/cpu-resources.rst@412 I get that I'm being outvoted.  So let's stop trying to convince each other that ours is the one true vision and just get on with making things happen.  I'm implementing the granular algorithm right now.  If you want to propose an amendment to the spec, let's git r done.18:58
efried(But on that note, I don't have a good way to tie separate request groups together unless allocation requests include the anchor provider.)18:59
*** rmcall has quit IRC19:00
jaypipesefried: ack19:01
*** gouthamr has quit IRC19:04
*** baoli has joined #openstack-nova19:05
*** voelzmo has quit IRC19:06
*** mriedem has quit IRC19:07
*** mriedem has joined #openstack-nova19:07
*** jaosorior has quit IRC19:11
*** jmlowe has joined #openstack-nova19:12
*** yangyapeng has joined #openstack-nova19:13
*** yangyapeng has quit IRC19:18
eanderssonWhat is the status of NUMA migration / evacuation etc?19:18
mriedemeandersson: there is a spec for supporting live migration of numa instances https://review.openstack.org/#/c/552722/19:19
mriedemartom owns that19:19
mriedemevac....19:19
eanderssonDo you know when resize etc was fixed?19:19
mriedemevac should work, not sure when cold migrate was fixed19:20
mriedemcfriesen_ might know19:20
*** armaan has quit IRC19:24
*** moshele has joined #openstack-nova19:24
*** armaan has joined #openstack-nova19:25
melwittwhat sort of testing do we generally do for the metadata API service? mostly only unit tests?19:29
*** suresh12 has quit IRC19:31
melwittnvm, I found some func tests too19:31
*** yangyapeng has joined #openstack-nova19:33
eanderssonmriedem, cfriesen_ thanks - yea was hoping to figure out when (resize, evacuate etc)  was actually fixed19:34
mriedemeandersson: i'm not sure what about evac would be broken for instances with numa19:34
mriedemevac goes through the scheduler to find a new host and has to do a claim on that new host, just like normal server create19:34
eanderssonYea - it's possible we were mislead by this bug report https://bugs.launchpad.net/nova/+bug/141766719:34
openstackLaunchpad bug 1417667 in OpenStack Compute (nova) "migration/evacuation/rebuild/resize/unshelve of instance with NUMA topology needs to recalculate NUMA topology" [Medium,In progress] - Assigned to sahid (sahid-ferdjaoui)19:34
mriedemthat does look misleading,19:35
mriedemcfriesen_ reported that for live migration, and then it looks like a blanket statement was made about other operations, including rebuild, which isn't a move operation19:36
*** liverpooler has quit IRC19:36
eanderssonWe did do a lot of testing on this, but honestly don't remember what was actually broken (besides live migration) for us19:37
mriedemeandersson: so https://review.openstack.org/#/q/topic:bug/1417667+(status:open+OR+status:merged)19:37
mriedemshould handle all of the cold migrate/evac/resize cases i think19:37
*** yangyapeng has quit IRC19:37
mriedemhttps://review.openstack.org/#/c/226411/ goes back to liberty19:38
*** mvk has joined #openstack-nova19:38
*** suresh12 has joined #openstack-nova19:38
mriedemhttps://review.openstack.org/#/c/218938/ looks like that is the fix for cold migrate / resize19:38
eanderssonbtw unrelated by is there a reason why filters and weights weren't made into plugins?19:40
mriedemso i think we can probably mark this as fixed for evac and cold migrate, and open a new bug for tracking the live migration issue, which is being resolved via https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/numa-aware-live-migration.html in rocky19:40
mriedemyou can plug those in19:41
eanderssonoh19:41
*** voelzmo has joined #openstack-nova19:41
eanderssonwe have been adding them to the nova/schedulers/filters etc :D19:41
mriedemcfriesen_: if you're around and https://bugs.launchpad.net/nova/+bug/1417667/comments/45 is accurate, we should work on closing out that bug to reflect reality since Liberty19:41
openstackLaunchpad bug 1417667 in OpenStack Compute (nova) "migration/evacuation/rebuild/resize/unshelve of instance with NUMA topology needs to recalculate NUMA topology" [Medium,In progress] - Assigned to sahid (sahid-ferdjaoui)19:41
mriedemeandersson: we == ?19:41
mriedemsuse?19:41
eandersson*I have :D for my deployment19:42
melwittyou mean adding custom out-of-tree ones right? if you have generally useful weighers/filters you can upstream them19:42
*** moshele has quit IRC19:42
eanderssonYea for sure :D19:42
melwittdo we allow custom out of tree ones? I thought maybe not19:42
mriedemeandersson: https://docs.openstack.org/nova/latest/user/filter-scheduler.html#writing-your-own-filter19:43
mriedemmelwitt: yes we do19:43
melwittI can't remember if we restricted it to in-tree only19:43
melwittokay, nevermind then19:43
mriedemthat's also why scheduler hints are wild west19:43
mriedemhell you can even load your own scheduler driver19:43
eanderssonI think we may just have backported some of the newer filter fixes19:44
mriedemeandersson: which release are you on?19:44
eanderssonmitaka atm19:44
openstackgerritTyler Blakeslee proposed openstack/nova stable/queens: Add __repr__ for NovaException  https://review.openstack.org/55915819:44
*** yamamoto has quit IRC19:45
mriedemok so i think i was wrong about the plugin,19:47
mriedemi think that might just be the scheduler driver entrypoint19:47
mriedemhttps://github.com/openstack/nova/blob/master/nova/scheduler/filters/__init__.py#L6419:48
mriedemloads up the filters from nova/scheduler/filters as you said19:48
mriedemhttps://docs.openstack.org/nova/latest/user/filter-scheduler.html#writing-your-own-filter doesn't mention that you have to drop them into the code tree19:48
eanderssonIt would be a nice feature, because someone might write a scheduler to automatically upgrade their computes19:49
eanderssonyou know sounds like a cool thing19:49
melwittit used to be free-form pluggable but it locked down more recently, IIRC. and the doc not updated19:49
eanderssonI see19:49
mriedemeandersson: typically nova is anti-plugin19:49
mriedemand have slowly evolved over time to cut out plugin points, as they aren't tested and we break them as such19:49
mriedemplus, interop is a concern with too many plug points19:50
mriedemfor a private cloud that just wants to customize everything, interop isn't a concern, but it's a concern for public cloud19:50
mriedemwell, could be a concern for private cloud if it ever wants to use the same APIs on a public cloud19:50
melwittyeah, I've seen it bite private cloud when people used other open source tools that talk to openstack19:51
melwittthat expected the APIs to be a certain way19:51
eanderssonYea - makes sense19:53
melwittthey thought "oh I can use this tool to talk to the openstack private cloud" and something custom in the cloud API tripped it up so they couldn't use the tool19:53
mriedemi can't see anything in loadables or filters that used to use extension points19:54
mriedemlooks like it's just always been classpath loading since 201219:54
eanderssonYea - the first place I always look is setup.cfg19:54
*** jackie-truong has joined #openstack-nova19:55
*** salv-orlando has joined #openstack-nova19:55
melwittoh, hm. okay19:56
melwittI dunno what I was thinking of. maybe I dreamed it19:57
mriedemnaw i thought they were loadable via ext point too19:57
mriedemi know the driver is19:57
*** jmlowe has quit IRC19:57
mriedemand compute rest api extensions used to be loadable via ext point19:57
mriedemi think that was also killed in liberty19:57
melwittright19:58
eanderssonbtw more crazy questions... why was a notifaction on instance rename never implemented?19:58
mriedemno one ever asked for/wrote it?19:58
mriedemthere are notifications on instance.update19:59
eanderssonI see - that simple huh? :D19:59
mriedemwhich is what a rename is19:59
*** awaugama has joined #openstack-nova19:59
mriedemhttps://docs.openstack.org/nova/latest/reference/notifications.html#versioned-notification-samples19:59
mriedemalthough it's not like create where you have a start/end notification19:59
mriedemoh, well looky here: "old_display_name": null,20:00
*** yassine has quit IRC20:00
mriedemhttp://git.openstack.org/cgit/openstack/nova/tree/nova/notifications/base.py#n12120:00
mriedemso yeah, instance.update is what you want20:01
eanderssoncool - maybe I can add that to designate20:01
eanderssonhttps://github.com/openstack/designate/blob/master/designate/notification_handler/nova.py#L7320:01
mriedemhmm, i don't think the display_name is what you're looking for20:01
mriedem"host_name": "some-server",20:02
mriedemhost_name is what's used for the DNS entry i think20:02
eanderssonYea - it is20:02
melwittyeah and host_name is derived from the display_name during create20:02
mriedemand you can't change that via the REST API20:02
*** sree has joined #openstack-nova20:02
mriedemhttps://developer.openstack.org/api-ref/compute/#update-server20:03
melwittyeah, display_name -> hostname thing only happens during create, I don't see it for update20:05
melwitthttps://github.com/openstack/nova/blob/master/nova/compute/api.py#L52420:05
*** yassine has joined #openstack-nova20:06
openstackgerritMathieu Gagné proposed openstack/nova-specs master: Multiple Fixed-IPs support in network information  https://review.openstack.org/31262620:06
*** sree has quit IRC20:07
mriedemif we updated the hostname that would also likely imply a rebuild needed to get it into the guest20:07
melwittwould this be a problem if anything in the exception message (like string substitutions like display_name) has unicode characters in it? https://review.openstack.org/#/c/555812/5/nova/exception.py@10820:07
mriedemor at least a reboot20:07
mriedemmelwitt: ah, yes, probably20:08
melwittyeah. it would take some doing. I think people have asked for it before but not sure what all would be involved20:08
melwittwas thinking about it since you brought up str() on a different review and someone just proposed a queens backport for the __repr__ one20:09
*** cdent has quit IRC20:09
mriedemefried: do you have the ability to sametime tyler blakes?20:09
mriedem*blakeslee20:09
mriedemi see you guys are bff's20:09
efriedmriedem: looking...20:09
eanderssonI tested evacuate in mitaka and it failed :'(20:09
melwittruh roh20:10
mriedemeandersson: with an instance that has numa?20:10
eanderssonYea - I created 5 instances on two computes with numa pinning20:10
mriedemdid it fail because of numa or because of something else?20:10
efriedmriedem: Got him on slack.  Whaddayaneed?20:10
mriedemefried: see the comment in https://review.openstack.org/#/c/555812/ about unicode20:11
eanderssonand evacuated two of them to the other compute, and the two evacuated now have conflicting numa pinning20:11
mriedemeandersson: did you evacuate them at the same time?20:11
eanderssonYes20:11
mriedemwell,20:11
mriedemthat's your problem :)20:11
efriedmriedem: Ack.  But... I thought they fixed that issue down at the oslo.log level.20:11
eanderssonSo the two vms are not conflicting with each other20:11
mriedemeandersson: the numa resource claim happens on the compute service, not in the scheduler, so you're racing with concurrent evac requests to claim the same thing20:12
eanderssonthey both kept their pinnings20:12
efriedmriedem: Hum, that totally wouldn't help here, huh?20:12
mriedemefried: no20:12
eanderssonthey are conflicting with vms that already were on the compute20:12
mriedemeandersson: hmm20:12
mriedemeandersson: the evac should fail then shouldn't it?20:12
*** arvindn051 has quit IRC20:13
mriedemif the resources are already taken by other VMs on that host20:13
eanderssonYea - I just don't think it knows that it is conflicting20:13
eanderssonbecause it's technically not "invalid" to pin two vms on the same cores20:13
mriedemwhat is valid or not with the numa stuff at this level is over my head, and would require the likes of cfriesen_, stephenfin, jaypipes, et al20:14
eanderssonYea - hoenstly I bet this is fixed in newer versions20:14
eanderssonWe just need to upgrade20:14
mriedemhopefully you're not too heavily forked20:14
eanderssonnah - it's more cells etc20:14
mriedemupgrading to cells v2 never hurt *anybody*20:15
eanderssonit's a big jump, or feels like one at least :D20:15
melwittyeah. no one has ever complained about it20:15
eanderssonHow does nova perform now with... a lot of computes?20:15
mriedemif you haven't read up yet, https://docs.openstack.org/nova/latest/user/cells.html - https://docs.openstack.org/nova/latest/user/cellsv2-layout.html -20:15
mriedemthere are some summit videos here if you don't like reading https://docs.openstack.org/nova/latest/user/cells.html#cells-v220:16
mriedemto prime that pump20:16
*** archit has joined #openstack-nova20:16
*** archit is now known as amodi20:16
mriedemwell, depends - placement is more meant to solve the lots of computes issue20:17
mriedemdoing filtering in sql queries rather than post-db query python filters in memory20:17
mriedemand doing resource claims in the scheduler rather than racing to claim in the computes, hitting conflicts and rescheduling20:17
*** jistr has quit IRC20:18
mriedemyou'll need to be at least at pike to do claims via placement in the scheduler20:18
mriedemand pike for mult-cell20:18
melwittthat reminds me, I was looking at this yesterday. need to check on something in the scheduler https://bugs.launchpad.net/nova/+bug/173746520:18
openstackLaunchpad bug 1737465 in OpenStack Compute (nova) "[cellv2] the performance issue of cellv2 when creating 500 instances concurrently" [Undecided,New] - Assigned to Surya Seetharaman (tssurya)20:18
melwittthat's not about a lot of computes, sorry. that's about a lot of instances20:18
*** jistr has joined #openstack-nova20:19
eanderssonnice20:22
eanderssonwe are looking at pike at the moment20:22
owalshmelwitt: nope, donno if https://bugs.launchpad.net/nova/+bug/1717915 got resolved. I'd assume it's an oslo.messaging bug20:27
openstackLaunchpad bug 1717915 in oslo.messaging "nova services and transport_url, cannot connect to vhost if specified" [Undecided,New]20:27
melwittowalsh: ack, thanks20:28
*** ccamacho has joined #openstack-nova20:28
owalshmelwitt: actually, I had problems with oslo.messaging the other day where the transport_url handling wasn't right up when some, but not all, of the legacy conf options were set20:29
owalshnot had time to look into it though20:29
efriedmriedem, melwitt: tblakes has acked internally and will get on that fup.20:30
melwittowalsh: by transport_url handling do you mean trying to use both the transport_url config option and the legacy options at the same time? or using only legacy options the resultant transport_url was wrong?20:30
owalshmelwitt: using both transport_url and the legacy options at the same time20:31
owalshmelwitt: I'll mention it on the LP at least20:31
melwittowalsh: yeah, I'm pretty sure that won't work because one (transport_url) is a superset of the others. like, if transport_url is set, that will be taken and nothing else considered. I'm not 100% sure though20:31
melwittif it tries to merge them or not20:32
mriedemefried: ok, i hope the requisite amount of gifs were posted on slack during that conversation20:32
*** jackie-truong has quit IRC20:32
efriedmriedem: No giphys were harmed in the making of this conversation.20:32
zigokashyap: Just sent my reply.20:32
* efried loathes giphy20:33
owalshmelwitt: that's what I expected, but no. transport_url was correct but nova couldn't connect to rabbitmq. IIRC the legacy conf option for the port was also set but the host options was not20:33
melwittowalsh: ugh, okay. link me to the LP and I can look later20:34
*** lpetrut has quit IRC20:35
*** yangyapeng has joined #openstack-nova20:35
*** yangyapeng has quit IRC20:40
*** pchavva has quit IRC20:40
*** yamamoto has joined #openstack-nova20:46
openstackgerritTyler Blakeslee proposed openstack/nova master: Use six.text_type instead of str in NovaException __repr__  https://review.openstack.org/55916920:48
*** yamamoto has quit IRC20:52
openstackgerritMatt Riedemann proposed openstack/nova master: Wait for network-vif-plugged before starting live migration  https://review.openstack.org/55800121:00
openstackgerritMatt Riedemann proposed openstack/nova master: Add check if neutron "binding-extended" extension is available  https://review.openstack.org/52354821:00
openstackgerritMatt Riedemann proposed openstack/nova master: Add "bind_ports_to_host" neutron API method  https://review.openstack.org/52360421:00
openstackgerritMatt Riedemann proposed openstack/nova master: Add "delete_port_binding" network API method  https://review.openstack.org/55217021:00
openstackgerritMatt Riedemann proposed openstack/nova master: Add "activate_port_binding" neutron API method  https://review.openstack.org/55594721:00
openstackgerritMatt Riedemann proposed openstack/nova master: Delete port bindings in setup_networks_on_host if teardown=True  https://review.openstack.org/55633321:00
openstackgerritMatt Riedemann proposed openstack/nova master: Implement migrate_instance_start method for neutron  https://review.openstack.org/55633421:00
openstackgerritMatt Riedemann proposed openstack/nova master: Add VIFMigrateData object for live migration  https://review.openstack.org/51542321:00
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: libvirt: use dest host vif migrate details for live migration  https://review.openstack.org/55137021:00
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: compute: use port binding extended API during live migration  https://review.openstack.org/55137121:00
openstackgerritMatt Riedemann proposed openstack/nova master: WIP: Port binding based on events during live migration  https://review.openstack.org/43487021:00
openstackgerritMatt Riedemann proposed openstack/nova master: conductor: use port binding extended API in during live migrate  https://review.openstack.org/52253721:00
melwittowalsh: thanks. I misunderstood you earlier, I thought there was a second LP bug you had opened about the other issue21:03
*** mikal_ is now known as mikal21:03
openstackgerritMerged openstack/nova master: Make generation optional in ProviderTree  https://review.openstack.org/53932421:03
openstackgerritTyler Blakeslee proposed openstack/nova master: Use six.text_type instead of str in NovaException __repr__  https://review.openstack.org/55916921:04
owalshmelwitt: ah, yea, not had time to investigate it yet...21:04
melwittyeah, no worries. just explaining why I said, "link me the LP" because I thought there was a second LP :)21:04
openstackgerritMatt Riedemann proposed openstack/nova master: DNM: test live_migration_wait_for_vif_plug=True  https://review.openstack.org/55800621:05
melwittyou were probably like, "what ... link the same bug you told me about?"21:05
* owalsh did wonder :)21:05
melwitthaha21:06
*** Guest31390 has quit IRC21:08
*** homeski has joined #openstack-nova21:13
*** arvindn05 has joined #openstack-nova21:16
arvindn05i am having issues running tox -epep8. Was working fine unti it wasnt...21:17
arvindn05gettting the error netifaces.c:1:20: fatal error: Python.h: No such file or directory21:17
arvindn05anyone saw this error before?21:18
melwittwe recently switched it to run with python3 by default21:20
melwittso maybe you need the python3-dev package, or the like21:20
openstackgerritArvind Nadendla proposed openstack/nova master: Update ImageMetaProp object to expose traits  https://review.openstack.org/55779521:21
arvindn05melwitt: thanks...i tried that based on similar recommendation21:24
arvindn05The following packages have unmet dependencies:21:24
arvindn05 python3-dev : Depends: libpython3-dev (= 3.5.1-3) but it is not going to be installed21:24
arvindn05               Depends: python3.5-dev (>= 3.5.1-2~) but it is not going to be installed21:24
arvindn05E: Unable to correct problems, you have held broken packages.21:24
arvindn05unable to install them because it says i have unmet dependencies...i looked for broken packages...but no luck21:24
*** edmondsw has quit IRC21:27
*** Swami has joined #openstack-nova21:28
arvindn05melwitt: nevermind got it to work. Thanks for the hint21:29
*** tssurya has quit IRC21:29
*** felipemonteiro_ has quit IRC21:29
arvindn05had to use a different package manager aptitude to resolve the dependencies21:29
melwittk, cool21:29
openstackgerritMerged openstack/nova master: [placement] Fix incorrect exception import  https://review.openstack.org/55891621:32
melwittlooks like limestone hosts still timing out21:47
*** yamamoto has joined #openstack-nova21:48
*** rcernin has joined #openstack-nova21:49
*** yamamoto has quit IRC21:53
*** esberglu_ has quit IRC21:57
*** esberglu has joined #openstack-nova21:58
*** esberglu has quit IRC22:03
*** sdague has quit IRC22:15
*** bnemec has quit IRC22:17
*** salv-orlando has quit IRC22:19
*** salv-orlando has joined #openstack-nova22:19
*** jistr has quit IRC22:22
*** salv-orlando has quit IRC22:24
*** jaypipes has quit IRC22:26
openstackgerritMichael Still proposed openstack/nova master: Move xenapi disk resizing to privsep.  https://review.openstack.org/55224222:27
openstackgerritMichael Still proposed openstack/nova master: Sync xenapi and libvirt on what flags to pass e2fsck.  https://review.openstack.org/55407822:27
openstackgerritMichael Still proposed openstack/nova master: Move xenapi partition copies to privsep.  https://review.openstack.org/55360522:27
openstackgerritMichael Still proposed openstack/nova master: Move image conversion to privsep.  https://review.openstack.org/55443722:27
openstackgerritMichael Still proposed openstack/nova master: We don't need utils.trycmd any more.  https://review.openstack.org/55443922:27
openstackgerritMichael Still proposed openstack/nova master: We no longer need rootwrap.  https://review.openstack.org/55443822:27
*** sridharg has quit IRC22:29
logan-melwitt: would you mind linking me to the job log? im not seeing the fail in logstash. we (limestone) are actively monitoring and fixing the timeouts noticed yesterday and the failure rate has been much lower today.22:31
*** tssurya has joined #openstack-nova22:33
openstackgerritMichael Still proposed openstack/nova master: Use a pythonic delete, with a retry.  https://review.openstack.org/55479322:33
*** felipemonteiro_ has joined #openstack-nova22:36
*** jistr has joined #openstack-nova22:36
*** tssurya has quit IRC22:37
*** baoli has quit IRC22:41
*** lbragstad has quit IRC22:41
*** baoli has joined #openstack-nova22:41
*** baoli has quit IRC22:42
*** yangyapeng has joined #openstack-nova22:44
*** yangyapeng has quit IRC22:49
*** yamamoto has joined #openstack-nova22:49
cfriesen_eandersson: I was off working other stuff today, didn't see your messages.  If you have questions abut numa stuff, feel free to ping me.  Just wondering, do you have the NUMATopologyFilter enabled in the "scheduler_default_filters" config option in nova.conf?22:51
*** yamamoto has quit IRC22:55
*** yassine has quit IRC22:58
*** yassine_ has joined #openstack-nova22:58
*** jmlowe has joined #openstack-nova23:00
openstackgerritEric Fried proposed openstack/nova master: WIP: placement: Granular GET /allocation_candidates  https://review.openstack.org/51775723:01
*** threestrands has joined #openstack-nova23:02
*** threestrands has joined #openstack-nova23:02
*** felipemonteiro_ has quit IRC23:02
*** yangyapeng has joined #openstack-nova23:03
mriedemcfriesen_: i think the net is https://bugs.launchpad.net/nova/+bug/1417667/comments/4523:04
openstackLaunchpad bug 1417667 in OpenStack Compute (nova) "migration/evacuation/resize/unshelve of instance with NUMA topology needs to recalculate NUMA topology" [Medium,In progress] - Assigned to sahid (sahid-ferdjaoui)23:04
*** chyka has quit IRC23:04
mriedemcfriesen_: ah you replied23:04
mriedemok, so i think we should probably close that bug23:04
*** weshay is now known as weshay_pto23:05
*** hongbin has quit IRC23:05
mriedemmikal: fyi, i'm cleaning up https://review.openstack.org/#/c/324720/23:08
*** yangyapeng has quit IRC23:08
eanderssoncfriesen_, yea it's enabled23:11
openstackgerritArvind Nadendla proposed openstack/nova master: Update ImageMetaProp object to expose traits  https://review.openstack.org/55779523:15
openstackgerritMerged openstack/nova master: Add --enable and --disable options to  nova-manage update_cell  https://review.openstack.org/55541623:16
openstackgerritMerged openstack/nova master: Update the cells FAQs and scheduler maintenance docs.  https://review.openstack.org/55645923:16
arvindn05mriedem: added the check to unit test for the image traits review23:16
*** salv-orlando has joined #openstack-nova23:20
Spaz-HomeMorning folks23:20
*** mdrabe has quit IRC23:24
*** salv-orlando has quit IRC23:24
*** yangyapeng has joined #openstack-nova23:25
openstackgerritMerged openstack/nova master: update_provider_tree devref and docstring updates  https://review.openstack.org/55347623:27
*** mdrabe has joined #openstack-nova23:29
*** yangyapeng has quit IRC23:29
cfriesen_mriedem: I guess we've got https://bugs.launchpad.net/nova/+bug/1289064 to track the live migration issues, so yeah I'm okay with closing that one.23:30
openstackLaunchpad bug 1289064 in OpenStack Compute (nova) "live migration of instance should claim resources on target compute node" [Medium,In progress] - Assigned to sahid (sahid-ferdjaoui)23:30
cfriesen_eandersson: in that case I'm a bit surprised.  Do you see resource claims being made on the destination?23:33
*** mdrabe has quit IRC23:34
*** yassine_ has quit IRC23:37
*** mlavalle has quit IRC23:37
*** mdrabe has joined #openstack-nova23:37
*** yangyapeng has joined #openstack-nova23:39
*** yangyapeng has quit IRC23:44
*** yassine_ has joined #openstack-nova23:48
*** mdrabe has quit IRC23:49
*** gouthamr has joined #openstack-nova23:51
*** yamamoto has joined #openstack-nova23:51
Spaz-HomeInteresting.. does it only do those claims if a host is specified?23:52
*** mdrabe has joined #openstack-nova23:53
eanderssoncfriesen_, > During the sync_power process the instance has moved from host X to host Y23:55
eanderssonIs all I see in the normal logs23:55
cfriesen_eandersson: mitaka, right?23:55
eanderssonyea23:55
eandersson> CPUPinningInvalid: Cannot pin/unpin cpus [1, 21] from the following pinned set [0, 1, 20, 5, 25, 21]23:56
eanderssonIt's complaning about that after it was moved23:57
*** yamamoto has quit IRC23:57
*** mdrabe has quit IRC23:58

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