| *** ociuhandu has joined #openstack-nova | 00:00 | |
| *** ociuhandu has quit IRC | 00:05 | |
| *** efried has quit IRC | 00:18 | |
| *** tosky has quit IRC | 00:22 | |
| *** luksky has quit IRC | 00:22 | |
| *** efried has joined #openstack-nova | 00:27 | |
| *** spatel has joined #openstack-nova | 00:43 | |
| *** spatel has quit IRC | 00:48 | |
| *** slaweq has joined #openstack-nova | 01:11 | |
| *** slaweq has quit IRC | 01:16 | |
| *** mdbooth has quit IRC | 01:16 | |
| *** mdbooth has joined #openstack-nova | 01:18 | |
| *** yedongcan has joined #openstack-nova | 01:41 | |
| *** yedongcan has quit IRC | 01:52 | |
| *** yedongcan has joined #openstack-nova | 01:53 | |
| *** gyee has quit IRC | 02:10 | |
| *** hongbin has joined #openstack-nova | 02:29 | |
| *** Liang__ has joined #openstack-nova | 02:46 | |
| *** slaweq has joined #openstack-nova | 03:11 | |
| *** slaweq has quit IRC | 03:15 | |
| *** mkrai has joined #openstack-nova | 03:33 | |
| *** mkrai has quit IRC | 03:36 | |
| *** mkrai_ has joined #openstack-nova | 03:36 | |
| *** mkrai_ has quit IRC | 03:37 | |
| openstackgerrit | Guo Jingyu proposed openstack/nova-specs master: Proposal for a safer noVNC console with password authentication https://review.opendev.org/623120 | 03:51 |
|---|---|---|
| *** vishalmanchanda has joined #openstack-nova | 03:52 | |
| *** mkrai has joined #openstack-nova | 04:00 | |
| *** udesale has joined #openstack-nova | 04:03 | |
| *** hongbin has quit IRC | 04:33 | |
| *** yedongcan has quit IRC | 04:37 | |
| *** yedongcan has joined #openstack-nova | 04:40 | |
| *** larsks has quit IRC | 05:05 | |
| *** cmurphy has quit IRC | 05:05 | |
| *** cmurphy has joined #openstack-nova | 05:07 | |
| *** slaweq has joined #openstack-nova | 05:11 | |
| *** mkrai has quit IRC | 05:11 | |
| *** larsks has joined #openstack-nova | 05:12 | |
| *** slaweq has quit IRC | 05:16 | |
| *** links has joined #openstack-nova | 05:18 | |
| *** Liang__ has quit IRC | 05:29 | |
| *** evrardjp has quit IRC | 05:33 | |
| *** evrardjp has joined #openstack-nova | 05:34 | |
| *** udesale_ has joined #openstack-nova | 05:45 | |
| *** udesale has quit IRC | 05:48 | |
| *** ratailor has joined #openstack-nova | 05:55 | |
| *** mkrai has joined #openstack-nova | 06:08 | |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: ksa auth conf and client for Cyborg access https://review.opendev.org/631242 | 06:24 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: Add Cyborg device profile groups to request spec. https://review.opendev.org/631243 | 06:24 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: Define Cyborg ARQ binding notification event. https://review.opendev.org/692707 | 06:24 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: Create and bind Cyborg ARQs. https://review.opendev.org/631244 | 06:24 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: Pass accelerator requests to each virt driver from compute manager. https://review.opendev.org/698581 | 06:24 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: Compose accelerator PCI devices into domain XML in libvirt driver. https://review.opendev.org/631245 | 06:24 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: Delete ARQs for an instance when the instance is deleted. https://review.opendev.org/673735 | 06:24 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: Enable hard/soft reboot with accelerators. https://review.opendev.org/697940 | 06:24 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: Enable start/stop of instances with accelerators. https://review.opendev.org/699553 | 06:24 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: Enable and use COMPUTE_ACCELERATORS trait. https://review.opendev.org/699554 | 06:24 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: Bump compute rpcapi version and reduce Cyborg calls. https://review.opendev.org/704227 | 06:24 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: Add cyborg tempest job. https://review.opendev.org/670999 | 06:24 |
| *** udesale_ has quit IRC | 06:45 | |
| *** udesale has joined #openstack-nova | 06:53 | |
| *** slaweq has joined #openstack-nova | 07:11 | |
| *** lpetrut has joined #openstack-nova | 07:15 | |
| *** slaweq has quit IRC | 07:16 | |
| *** dpawlik has joined #openstack-nova | 07:26 | |
| *** mkrai has quit IRC | 07:26 | |
| *** mugsie has quit IRC | 07:37 | |
| *** kiseok7 has joined #openstack-nova | 07:39 | |
| *** mugsie has joined #openstack-nova | 07:41 | |
| *** evrardjp has quit IRC | 07:46 | |
| *** evrardjp has joined #openstack-nova | 07:50 | |
| *** dtantsur|afk is now known as dtantsur | 07:56 | |
| *** vesper11 has quit IRC | 08:06 | |
| *** vesper11 has joined #openstack-nova | 08:07 | |
| *** slaweq has joined #openstack-nova | 08:12 | |
| *** maciejjozefczyk has joined #openstack-nova | 08:14 | |
| *** tkajinam has quit IRC | 08:17 | |
| *** luksky has joined #openstack-nova | 08:21 | |
| *** mkrai has joined #openstack-nova | 08:22 | |
| *** tesseract has joined #openstack-nova | 08:27 | |
| *** priteau has joined #openstack-nova | 08:31 | |
| *** rpittau|afk is now known as rpittau | 08:33 | |
| *** HagunKim has joined #openstack-nova | 08:34 | |
| *** tosky has joined #openstack-nova | 08:40 | |
| *** ociuhandu has joined #openstack-nova | 08:45 | |
| *** ralonsoh has joined #openstack-nova | 08:48 | |
| *** martinkennelly has joined #openstack-nova | 08:57 | |
| *** tetsuro has joined #openstack-nova | 09:04 | |
| *** hoonetorg has quit IRC | 09:06 | |
| *** shilpasd has joined #openstack-nova | 09:07 | |
| gibi | efried: reasoning for the group_policy none default https://review.opendev.org/#/c/657796/12//COMMIT_MSG unfortunatly the train ptg etherpad is dead :/ | 09:07 |
| gibi | efried: I remember that it wasn't a 100% coin toss to select none | 09:08 |
| gibi | bah https://etherpad.openstack.org/p/nova-ptg-train-5 is also dead | 09:10 |
| gibi | and there is no -6 | 09:11 |
| gibi | there was a dump of the etherpad on the ML http://www.codeha.us/openstack-discuss/msg05171.html but not much details there | 09:12 |
| gibi | "#agree: 'none' seems to be a sensible policy" | 09:12 |
| *** ociuhandu has quit IRC | 09:14 | |
| gibi | isolate is the stricter value so that feels a better default | 09:14 |
| gibi | but I'm not trying the re-create the reasoning alone | 09:14 |
| *** hoonetorg has joined #openstack-nova | 09:18 | |
| *** xek has joined #openstack-nova | 09:19 | |
| *** ociuhandu has joined #openstack-nova | 09:24 | |
| *** ociuhandu has quit IRC | 09:29 | |
| *** ociuhandu has joined #openstack-nova | 09:32 | |
| *** ociuhandu has quit IRC | 09:36 | |
| *** priteau has quit IRC | 09:44 | |
| *** derekh has joined #openstack-nova | 09:44 | |
| *** Liang__ has joined #openstack-nova | 09:59 | |
| *** davidsha has joined #openstack-nova | 10:05 | |
| *** jaosorior has quit IRC | 10:08 | |
| *** mkrai has quit IRC | 10:14 | |
| *** ociuhandu has joined #openstack-nova | 10:21 | |
| huaqiang | stephenfin: do you updated comment for nova spec https://review.opendev.org/#/c/668656/? | 10:27 |
| bauzas | gibi: FWIW, I'm writing a new rev for https://review.opendev.org/#/c/552924/ | 10:34 |
| gibi | bauzas: ack | 10:34 |
| bauzas | we could discuss about the group_policy with this one | 10:34 |
| gibi | do we still have an open question about group_policy? | 10:36 |
| *** mkrai has joined #openstack-nova | 10:44 | |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: virt: Provide block_device_info during rescue https://review.opendev.org/700811 | 10:45 |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Add support for stable device rescue https://review.opendev.org/700812 | 10:45 |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Report COMPUTE_RESCUE_BFV and check during rescue https://review.opendev.org/701429 | 10:45 |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: api: Introduce microverion 2.82 allowing boot from volume rescue https://review.opendev.org/701430 | 10:45 |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: compute: Extract _get_bdm_image_metadata into nova.utils https://review.opendev.org/705212 | 10:45 |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP libvirt: Support boot from volume instance rescue https://review.opendev.org/701431 | 10:45 |
| *** mkrai has quit IRC | 10:52 | |
| *** dtantsur is now known as dtantsur|afk | 10:54 | |
| *** udesale has quit IRC | 11:04 | |
| *** ociuhandu has quit IRC | 11:06 | |
| *** dpawlik has quit IRC | 11:06 | |
| *** ociuhandu has joined #openstack-nova | 11:07 | |
| *** dpawlik has joined #openstack-nova | 11:07 | |
| *** yedongcan has quit IRC | 11:10 | |
| *** ociuhandu has quit IRC | 11:11 | |
| *** ociuhandu has joined #openstack-nova | 11:12 | |
| *** yedongcan has joined #openstack-nova | 11:13 | |
| *** hoonetorg has quit IRC | 11:14 | |
| *** tosky has quit IRC | 11:14 | |
| *** HagunKim has quit IRC | 11:14 | |
| *** slaweq has quit IRC | 11:14 | |
| *** mugsie has quit IRC | 11:14 | |
| *** ratailor has quit IRC | 11:14 | |
| *** cmurphy has quit IRC | 11:14 | |
| *** vishalmanchanda has quit IRC | 11:14 | |
| *** mdbooth has quit IRC | 11:14 | |
| *** ircuser-1 has quit IRC | 11:14 | |
| *** mmethot_ has quit IRC | 11:14 | |
| *** knikolla has quit IRC | 11:14 | |
| *** ildikov has quit IRC | 11:14 | |
| *** adriant has quit IRC | 11:14 | |
| *** abhishekk has quit IRC | 11:14 | |
| *** dansmith has quit IRC | 11:14 | |
| *** jkulik has quit IRC | 11:14 | |
| *** stephenfin has quit IRC | 11:14 | |
| *** mgoddard has quit IRC | 11:14 | |
| *** adrianc has quit IRC | 11:14 | |
| *** lchabert has quit IRC | 11:14 | |
| *** gryf has quit IRC | 11:14 | |
| *** hemna has quit IRC | 11:14 | |
| *** tonyb[m] has quit IRC | 11:14 | |
| *** _erlon_ has quit IRC | 11:14 | |
| *** cz3 has quit IRC | 11:14 | |
| *** Anticimex has quit IRC | 11:14 | |
| *** dtantsur|afk has quit IRC | 11:14 | |
| *** davidsha has quit IRC | 11:14 | |
| *** maciejjozefczyk has quit IRC | 11:14 | |
| *** kiseok7 has quit IRC | 11:14 | |
| *** arne_wiebalck has quit IRC | 11:14 | |
| *** rajinir has quit IRC | 11:14 | |
| *** pas-ha has quit IRC | 11:14 | |
| *** Jeffrey4l has quit IRC | 11:14 | |
| *** StevenK has quit IRC | 11:14 | |
| *** sapd1 has quit IRC | 11:14 | |
| *** mvkr has quit IRC | 11:14 | |
| *** dustinc has quit IRC | 11:14 | |
| *** mnasiadka has quit IRC | 11:14 | |
| *** andreaf has quit IRC | 11:14 | |
| *** szaher has quit IRC | 11:14 | |
| *** seba has quit IRC | 11:14 | |
| *** ab-a has quit IRC | 11:14 | |
| *** Alon_KS has quit IRC | 11:14 | |
| *** donnyd has quit IRC | 11:14 | |
| *** lyarwood has quit IRC | 11:14 | |
| *** logan- has quit IRC | 11:14 | |
| *** fyx has quit IRC | 11:14 | |
| *** vdrok has quit IRC | 11:14 | |
| *** sorrison has quit IRC | 11:14 | |
| *** melwitt has quit IRC | 11:14 | |
| *** bauzas has quit IRC | 11:14 | |
| *** irclogbot_2 has quit IRC | 11:15 | |
| *** openstackstatus has quit IRC | 11:16 | |
| *** ttx has quit IRC | 11:17 | |
| *** irclogbot_1 has joined #openstack-nova | 11:17 | |
| *** tonyb[m] has joined #openstack-nova | 11:17 | |
| *** _erlon_ has joined #openstack-nova | 11:17 | |
| *** cz3 has joined #openstack-nova | 11:17 | |
| *** Anticimex has joined #openstack-nova | 11:17 | |
| *** dtantsur|afk has joined #openstack-nova | 11:17 | |
| *** Liang__ has quit IRC | 11:18 | |
| *** vesper11 has quit IRC | 11:18 | |
| *** rnoriega_ has quit IRC | 11:18 | |
| *** kaisers has quit IRC | 11:18 | |
| *** smcginnis|FOSDEM has quit IRC | 11:18 | |
| *** johnthetubaguy has quit IRC | 11:18 | |
| *** purplerbot has quit IRC | 11:18 | |
| *** ioni has quit IRC | 11:18 | |
| *** gary_perkins has quit IRC | 11:18 | |
| *** ericyoung has quit IRC | 11:18 | |
| *** tristanC has quit IRC | 11:18 | |
| *** arxcruz has quit IRC | 11:18 | |
| *** johanssone has quit IRC | 11:18 | |
| *** bauzas has joined #openstack-nova | 11:18 | |
| *** hoonetorg has joined #openstack-nova | 11:18 | |
| *** tosky has joined #openstack-nova | 11:18 | |
| *** HagunKim has joined #openstack-nova | 11:18 | |
| *** slaweq has joined #openstack-nova | 11:18 | |
| *** mugsie has joined #openstack-nova | 11:18 | |
| *** ratailor has joined #openstack-nova | 11:18 | |
| *** cmurphy has joined #openstack-nova | 11:18 | |
| *** vishalmanchanda has joined #openstack-nova | 11:18 | |
| *** mdbooth has joined #openstack-nova | 11:18 | |
| *** ircuser-1 has joined #openstack-nova | 11:18 | |
| *** mmethot_ has joined #openstack-nova | 11:18 | |
| *** knikolla has joined #openstack-nova | 11:18 | |
| *** ildikov has joined #openstack-nova | 11:18 | |
| *** adriant has joined #openstack-nova | 11:18 | |
| *** abhishekk has joined #openstack-nova | 11:18 | |
| *** stephenfin has joined #openstack-nova | 11:18 | |
| *** dansmith has joined #openstack-nova | 11:18 | |
| *** jkulik has joined #openstack-nova | 11:18 | |
| *** mgoddard has joined #openstack-nova | 11:18 | |
| *** adrianc has joined #openstack-nova | 11:18 | |
| *** lchabert has joined #openstack-nova | 11:18 | |
| *** gryf has joined #openstack-nova | 11:18 | |
| *** hemna has joined #openstack-nova | 11:18 | |
| *** davidsha has joined #openstack-nova | 11:19 | |
| *** maciejjozefczyk has joined #openstack-nova | 11:19 | |
| *** kiseok7 has joined #openstack-nova | 11:19 | |
| *** arne_wiebalck has joined #openstack-nova | 11:19 | |
| *** rajinir has joined #openstack-nova | 11:19 | |
| *** pas-ha has joined #openstack-nova | 11:19 | |
| *** Jeffrey4l has joined #openstack-nova | 11:19 | |
| *** StevenK has joined #openstack-nova | 11:19 | |
| *** sapd1 has joined #openstack-nova | 11:19 | |
| *** mvkr has joined #openstack-nova | 11:19 | |
| *** dustinc has joined #openstack-nova | 11:19 | |
| *** mnasiadka has joined #openstack-nova | 11:19 | |
| *** andreaf has joined #openstack-nova | 11:19 | |
| *** szaher has joined #openstack-nova | 11:19 | |
| *** seba has joined #openstack-nova | 11:19 | |
| *** fyx has joined #openstack-nova | 11:19 | |
| *** ab-a has joined #openstack-nova | 11:19 | |
| *** Alon_KS has joined #openstack-nova | 11:19 | |
| *** donnyd has joined #openstack-nova | 11:19 | |
| *** lyarwood has joined #openstack-nova | 11:19 | |
| *** logan- has joined #openstack-nova | 11:19 | |
| *** vdrok has joined #openstack-nova | 11:19 | |
| *** sorrison has joined #openstack-nova | 11:19 | |
| *** melwitt has joined #openstack-nova | 11:19 | |
| *** johnthetubaguy has joined #openstack-nova | 11:19 | |
| *** _erlon_ has quit IRC | 11:20 | |
| *** arxcruz has joined #openstack-nova | 11:20 | |
| *** purplerbot has joined #openstack-nova | 11:20 | |
| *** johanssone has joined #openstack-nova | 11:20 | |
| *** cz3 has quit IRC | 11:20 | |
| *** rm_work has quit IRC | 11:21 | |
| *** tonyb[m] has quit IRC | 11:21 | |
| *** knikolla has quit IRC | 11:21 | |
| *** donnyd has quit IRC | 11:21 | |
| *** tonyb[m] has joined #openstack-nova | 11:21 | |
| *** mnaser has quit IRC | 11:21 | |
| *** _erlon_ has joined #openstack-nova | 11:22 | |
| *** rm_work has joined #openstack-nova | 11:22 | |
| *** mnaser has joined #openstack-nova | 11:22 | |
| *** vesper11 has joined #openstack-nova | 11:22 | |
| *** tesseract has quit IRC | 11:22 | |
| *** ildikov has quit IRC | 11:22 | |
| *** rnoriega_ has joined #openstack-nova | 11:23 | |
| *** ericyoung has joined #openstack-nova | 11:23 | |
| *** smcginnis|FOSDEM has joined #openstack-nova | 11:23 | |
| *** tristanC has joined #openstack-nova | 11:23 | |
| *** cz3 has joined #openstack-nova | 11:23 | |
| *** knikolla has joined #openstack-nova | 11:23 | |
| *** donnyd has joined #openstack-nova | 11:23 | |
| *** ildikov has joined #openstack-nova | 11:23 | |
| *** ttx has joined #openstack-nova | 11:23 | |
| *** tesseract has joined #openstack-nova | 11:24 | |
| *** andreykurilin has joined #openstack-nova | 11:26 | |
| *** bbowen has quit IRC | 11:36 | |
| *** tbachman has quit IRC | 11:38 | |
| *** yedongcan has quit IRC | 11:48 | |
| *** yedongcan has joined #openstack-nova | 11:49 | |
| *** tetsuro has quit IRC | 11:56 | |
| *** tesseract has quit IRC | 11:56 | |
| *** ioni has joined #openstack-nova | 12:10 | |
| *** tesseract has joined #openstack-nova | 12:26 | |
| *** vishalmanchanda has quit IRC | 12:29 | |
| *** tesseract has quit IRC | 12:29 | |
| *** tesseract has joined #openstack-nova | 12:31 | |
| *** tesseract has quit IRC | 12:37 | |
| *** Luzi has joined #openstack-nova | 12:37 | |
| *** tesseract has joined #openstack-nova | 12:38 | |
| *** tesseract has quit IRC | 12:40 | |
| *** tesseract has joined #openstack-nova | 12:40 | |
| *** ratailor has quit IRC | 12:45 | |
| *** damien_r has quit IRC | 12:46 | |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: tox: Integrate mypy https://review.opendev.org/676208 | 12:46 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: mypy: Add type annotations to 'nova.pci' https://review.opendev.org/676209 | 12:46 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: trivial: Remove unused 'cache_utils' APIs https://review.opendev.org/705652 | 12:46 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: trivial: Address TODO https://review.opendev.org/705653 | 12:46 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: trivial: Bump minimum version of websockify https://review.opendev.org/705654 | 12:46 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: trivial: Merge unnecessary 'NovaProxyRequestHandlerBase' separation https://review.opendev.org/705655 | 12:46 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: trivial: Remove 'run_once' helper https://review.opendev.org/705656 | 12:46 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: mypy: Add nova.cmd, nova.conf, nova.console https://review.opendev.org/705657 | 12:46 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP: mypy: Add type annotations to top-level modules https://review.opendev.org/705658 | 12:46 |
| *** ociuhandu has quit IRC | 12:48 | |
| *** tesseract has quit IRC | 12:50 | |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: nova-net: Remove unused parameters https://review.opendev.org/703974 | 12:53 |
| *** bbowen has joined #openstack-nova | 12:56 | |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: hardware: Add TODO to remove '(un)pin_cpu_with_siblings' https://review.opendev.org/705666 | 12:58 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: Address release note nits for cpu-resources series https://review.opendev.org/705667 | 12:58 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Address some trivial nits with port QoS doc https://review.opendev.org/705668 | 12:58 |
| openstackgerrit | Merged openstack/nova master: Enable live migration with qos ports https://review.opendev.org/699066 | 12:58 |
| openstackgerrit | Merged openstack/nova master: Avoid fetching metadata when no subnets found https://review.opendev.org/679247 | 12:58 |
| *** N3l1x has joined #openstack-nova | 12:58 | |
| openstackgerrit | Chen Hanxiao proposed openstack/nova master: libvirt: don't call sync_guest_time if qga is not enabled https://review.opendev.org/524836 | 13:02 |
| *** tesseract has joined #openstack-nova | 13:03 | |
| *** tesseract has quit IRC | 13:07 | |
| *** damien_r has joined #openstack-nova | 13:10 | |
| *** artom has quit IRC | 13:11 | |
| *** tbachman has joined #openstack-nova | 13:12 | |
| *** tesseract has joined #openstack-nova | 13:15 | |
| *** luksky has quit IRC | 13:19 | |
| *** ociuhandu has joined #openstack-nova | 13:20 | |
| *** mdbooth has quit IRC | 13:20 | |
| *** mdbooth has joined #openstack-nova | 13:21 | |
| *** ociuhandu has quit IRC | 13:27 | |
| *** jmlowe has joined #openstack-nova | 13:27 | |
| *** jmlowe has quit IRC | 13:29 | |
| huaqiang | stephenfin: do you have updated comment for the mixed instance spec https://review.opendev.org/#/c/668656/ ? | 13:30 |
| *** tkajinam has joined #openstack-nova | 13:34 | |
| *** nweinber has joined #openstack-nova | 13:35 | |
| *** maciejjozefczyk has quit IRC | 13:36 | |
| *** b3nt_pin has joined #openstack-nova | 13:37 | |
| *** mkrai has joined #openstack-nova | 13:38 | |
| kashyap | sfinucan: or any rST-aware-human: On headings automatically getting anchors -- is that a Sphinx thing, or rST proper? | 13:39 |
| *** davidsha has quit IRC | 13:39 | |
| *** pcaruana has quit IRC | 13:43 | |
| *** yedongcan has left #openstack-nova | 13:43 | |
| *** maciejjozefczyk has joined #openstack-nova | 13:46 | |
| *** jmlowe has joined #openstack-nova | 13:49 | |
| *** sandonov has joined #openstack-nova | 13:52 | |
| *** damien_r has quit IRC | 13:57 | |
| *** damien_r has joined #openstack-nova | 13:58 | |
| *** shilpasd has quit IRC | 13:59 | |
| *** ociuhandu has joined #openstack-nova | 14:01 | |
| *** ociuhandu has quit IRC | 14:06 | |
| *** mkrai has quit IRC | 14:07 | |
| sean-k-mooney | kashyap: it depens on your theme i think | 14:09 |
| kashyap | The theme is Sphinx in this case (as alluded to above) | 14:10 |
| sean-k-mooney | kashyap: but heading in lists dont get css ids allcoated | 14:10 |
| sean-k-mooney | so if you look at the flavor docs for example because we are using a list none of the falvor exrta specs have clickable ancors | 14:11 |
| sean-k-mooney | the title in the list will stilll be bolded but the element that renders the list does not add the css id | 14:12 |
| sean-k-mooney | kashyap: i am assuming you are asking why overview has an ancor bug flavor ID does not right https://docs.openstack.org/nova/latest/user/flavors.html#overview | 14:13 |
| * kashyap clicks | 14:13 | |
| kashyap | sean-k-mooney: No, not really; the example is: | 14:14 |
| *** sapd1_x has joined #openstack-nova | 14:17 | |
| * kashyap getting a paste-bin | 14:17 | |
| *** spatel has joined #openstack-nova | 14:19 | |
| kashyap | sean-k-mooney: Compare and contrast: http://paste.openstack.org/show/789109/ | 14:19 |
| *** eharney has quit IRC | 14:19 | |
| kashyap | The bottom example is the round-about way; the first is the straight-forward way. Anyway | 14:20 |
| sean-k-mooney | oh you are tralking about the automatic refrences | 14:20 |
| sean-k-mooney | so that you can refer to it without needing to do .. _`first-section`: | 14:20 |
| kashyap | Yep | 14:21 |
| sean-k-mooney | ya that only works in the current doc/page | 14:21 |
| sean-k-mooney | if you need to reference someitn in a different rst file you have to do it manually | 14:21 |
| sean-k-mooney | `First Section`__ will not work aross rst files | 14:22 |
| *** udesale has joined #openstack-nova | 14:22 | |
| *** mriedem has joined #openstack-nova | 14:23 | |
| *** tbachman has quit IRC | 14:23 | |
| *** jmlowe has quit IRC | 14:23 | |
| *** spatel has quit IRC | 14:24 | |
| kashyap | Right, just within the file :-) All sorted | 14:25 |
| sean-k-mooney | yep we only use the _`first-section`: way when we need too | 14:26 |
| kashyap | sean-k-mooney: Unrelated, do you know how to look up what version of Debian does this package edk2-(0~20190606.20d2e5a1-2) have? | 14:26 |
| *** jmlowe has joined #openstack-nova | 14:26 | |
| *** ociuhandu has joined #openstack-nova | 14:26 | |
| bauzas | efried: sean-k-mooney: had fully read the etherpad and the proposals | 14:26 |
| bauzas | <3 for you | 14:26 |
| bauzas | now processing those | 14:26 |
| kashyap | Rephrasing: "... what version of Debian has this package edk2-(0~20190606.20d2e5a1-2)" | 14:26 |
| *** dtantsur|afk is now known as dtantsur | 14:27 | |
| sean-k-mooney | bauzas: cool, did it seam familar? i have proposed it in the past but with same same_subtree and a few other enhancements to placmeet it is now much easier to use | 14:28 |
| bauzas | sean-k-mooney: same_subtree should be good, yes | 14:28 |
| bauzas | sean-k-mooney: efried: just a question about upgrades | 14:28 |
| bauzas | I provided a config option for listing the resource types | 14:29 |
| bauzas | I understand you wouldn't want to use it | 14:29 |
| bauzas | but then that means that when we upgrade, then we would have to transform the inventories and allocations directly | 14:30 |
| bauzas | I'm cool with this | 14:30 |
| bauzas | but you all okay? | 14:30 |
| sean-k-mooney | i was ok with the config option | 14:31 |
| sean-k-mooney | we will still need at least a config option to say report numa or not. where it needs to be a list is debatable | 14:31 |
| ralonsoh | sean-k-mooney, stephenfin https://bugs.launchpad.net/nova/+bug/1861876 | 14:32 |
| openstack | Launchpad bug 1861876 in OpenStack Compute (nova) "[Neutron API] Neutron Floating IP not always have 'port_details'" [Undecided,New] | 14:32 |
| sean-k-mooney | i was ok with the list | 14:32 |
| *** tkajinam has quit IRC | 14:32 | |
| sean-k-mooney | ralonsoh: looking | 14:33 |
| ralonsoh | thanks | 14:33 |
| sean-k-mooney | oh the nova net removal | 14:33 |
| ralonsoh | yeah! | 14:33 |
| ralonsoh | just a couple of things | 14:33 |
| * stephenfin tries to figure out why we weren't doing that before | 14:34 | |
| openstackgerrit | Mykola Yakovliev proposed openstack/nova master: Fix boot_roles in InstanceSystemMetadata https://review.opendev.org/698040 | 14:34 |
| sean-k-mooney | ralonsoh: is this the issue https://review.opendev.org/#/c/697153/16/nova/api/openstack/compute/floating_ips.py@39 | 14:34 |
| ralonsoh | sean-k-mooney, exactly | 14:34 |
| sean-k-mooney | we shoudl be useing floating_ip.get('prot_detail') | 14:35 |
| sean-k-mooney | to not cause a key error if it is not set | 14:35 |
| ralonsoh | sean-k-mooney, and the way the "pool" key is retrieved | 14:35 |
| ralonsoh | the network id is stored in "floating_network_id" | 14:35 |
| ralonsoh | https://github.com/openstack/neutron/blob/master/neutron/db/l3_db.py#L1030-L1037 | 14:35 |
| sean-k-mooney | ah i see | 14:35 |
| sean-k-mooney | im glad we are so consistent | 14:36 |
| ralonsoh | hahahahaha | 14:36 |
| ralonsoh | sorry for that | 14:36 |
| sean-k-mooney | no its fine so that shoudl be an easy fix | 14:36 |
| efried | bauzas, sean-k-mooney: I really don't want the list. I think a boolean toggle is the right thing. As we move forward, for example moving VGPUs from under the root to under the NUMA RPs, things will still work correctly. | 14:36 |
| sean-k-mooney | efried: ya im totally fine with the boolean toggel | 14:37 |
| bauzas | efried: we don't really need a boolean for triggering if so | 14:37 |
| efried | We'll "gain" support for new flavors that express affinity of the VGPUs, but old flavors that don't express such affinity will still work. | 14:37 |
| efried | bauzas: we do; one of the important distinctions here is that we're segregating the data center into numa-aware and not. | 14:37 |
| sean-k-mooney | i think by defualt we shoudl not do the reshape on upgrade but when the config option is set we will do the reshape and it should not be possibel to undo while instance are on the host | 14:38 |
| bauzas | unless we wanna somehow prepare ops to switch when they want | 14:38 |
| bauzas | cool enough, let's then make it a boolean | 14:38 |
| sean-k-mooney | bauzas: we need the config option because we said we would partion the cloud into numa hosts and non numa hosts | 14:38 |
| efried | I agree we should reshape when the config option is set and the service is restarted. We knew the restriction of "reshape only on upgrade" was artificial/temporary when we made it. | 14:38 |
| sean-k-mooney | so that on the non numa hosts you could continue to run floating instance that use more resouces then fit in 1 numa node | 14:39 |
| sean-k-mooney | without haveing to make the multi numa instnces | 14:39 |
| stephenfin | ralonsoh: ah, so previously we were making two requests to neutron via neutronclient: one to retrieve all floating IPs and one to retrieve all ports | 14:39 |
| bauzas | that looks seamless indeed | 14:39 |
| bauzas | but my only concern is that this conf opt is only for Ussuri | 14:39 |
| sean-k-mooney | e.g. the i want to use openstack to run one giant vm per host to run anohter orcastrator on top usecase we all hate | 14:40 |
| *** jaosorior has joined #openstack-nova | 14:40 | |
| bauzas | and then we would turn into it either way in Victoria | 14:40 |
| sean-k-mooney | bauzas: i wont be | 14:40 |
| dansmith | efried: sean-k-mooney bauzas but they will have to reshape eventually, right? | 14:40 |
| stephenfin | ralonsoh: and then we simply matched 'port_id' for each entry in the former to the corresponding port from the latter. I tried to make that cleverer by using 'port_details', but you're saying that's an extension that I can't rely on | 14:40 |
| sean-k-mooney | i will need to be kept as long as we support non numa instnaces | 14:40 |
| bauzas | dansmith is expressing my concern | 14:40 |
| stephenfin | ralonsoh: I can fix that now if you haven't already, but how can I check if that extension is available? | 14:40 |
| efried | dansmith: I'm not sure we ever need to force them to make a host NUMA-aware if they don't want to. | 14:40 |
| ralonsoh | stephenfin, exactly, this is an extension and this key is not mandatory | 14:40 |
| bauzas | efried: if so, we somehow need to make the path clear that we *will* remove filter things in Victoria either way | 14:41 |
| sean-k-mooney | dansmith: they will have to reshape only if we decied that all instance will have a numa toplogy of 1 gust numa node by defualt | 14:41 |
| efried | iow the segregated-on-NUMA-ness is a permanent characteristic of the data center | 14:41 |
| dansmith | if they can stay off forever, then fine, but I imagine that leaves us with a pretty big variable for a long time | 14:41 |
| bauzas | also, | 14:42 |
| bauzas | what I'm not okay is keeping the old filter processing for NUMA placement for a while | 14:42 |
| dansmith | anyway, my point was that 95% of people will not pay attention and flip that flag until they have to, so reshape-on-flag only buys you N cycles until you turn it on permanently | 14:42 |
| ralonsoh | stephenfin, you can use the neutron-client | 14:42 |
| sean-k-mooney | dansmith: ya so i have been advocating that we should make all instnaces numa instance for a long time. but it breaks the "run one giant vm" usecase that some people care about | 14:42 |
| ralonsoh | stephenfin, you can retrieve the extension list | 14:43 |
| ralonsoh | but in this case, do you need it? just checking if this key is in the FIP dict | 14:43 |
| efried | Hm, dansmith won't "people who care about NUMA" (like "edge") flip it right away so they can take advantage? Otherwise NUMA-ness won't work at all. | 14:43 |
| dansmith | sean-k-mooney: you mean just in how they specify the one big VM, not that we need to be able to provide numa-ignorant vms right? | 14:43 |
| sean-k-mooney | dansmith: if we decided that if you want to do that you have to specify multiple numa nodes in the flavor then we could get rid of the flag | 14:43 |
| bauzas | efried: that's my point | 14:44 |
| *** Luzi has quit IRC | 14:44 | |
| *** luksky has joined #openstack-nova | 14:44 | |
| sean-k-mooney | dansmith: ya they would jsut add hw:numa_nodes=2 or whatever to the giant flavor | 14:44 |
| efried | Like, I thought we were making this dividing line here such that, if you ask for a NUMA topo, and you don't have any computes with that flag switched on, you just won't land. | 14:44 |
| stephenfin | ralonsoh: I need to figure out what instance the floating IP is associated with so I can return 'instance_id' in the API response | 14:44 |
| bauzas | efried: if we want them to flip the conf opt, we somehow need to stop supporting the existing by the filter | 14:44 |
| efried | bauzas: but we don't *want* them to flip the conf opt... unless they *need* NUMA on that host. | 14:44 |
| stephenfin | ralonsoh: which appears to be stored in the 'device_id' field of the floating IP's port | 14:44 |
| dansmith | efried: if it's required for numa at all then don't those people have to switch at upgrade anyway? | 14:45 |
| efried | dansmith: only if they want NUMA-aware VMs on that host. | 14:45 |
| *** davidsha_ has joined #openstack-nova | 14:45 | |
| bauzas | efried: correct | 14:45 |
| bauzas | efried: people who don't care a bit about NUMA wouldn't get reshapes | 14:45 |
| sean-k-mooney | dansmith: as it stand we should not be mixing numa vms and non numa vms on the same host | 14:45 |
| dansmith | efried: right so people that have numa guests right now, they do the upgrade and if they don't flip it, they're unable to boot new instances? | 14:45 |
| bauzas | but people who care should opt-in now so that in Victoria we could remove the filter bits responsible for placing instances | 14:46 |
| sean-k-mooney | that is becasue of how we track and affitize the numa vms memory | 14:46 |
| efried | ah, I see what you're saying. Yes dansmith that's right. | 14:46 |
| dansmith | sean-k-mooney: I understand | 14:46 |
| *** mkrai has joined #openstack-nova | 14:46 | |
| dansmith | efried: right, so anyone else will not flip that flag until they have to | 14:46 |
| efried | why is that a problem? | 14:46 |
| sean-k-mooney | dansmith: yes we could maybe check if the host has numa instnace currenly an for enable it? | 14:47 |
| dansmith | efried: as I said before, if we're going to support numa-aware and numa-ignorant forever, then maybe it's not | 14:47 |
| dansmith | sean-k-mooney: seems a little scary | 14:47 |
| sean-k-mooney | ya i agree | 14:47 |
| efried | Right, that's what I thought we were going to do. If FooHost doesn't ever care about NUMA instances, it can just leave that flag off forever, and never have a flavor with hw:numa* in it, and go on happily forever. | 14:47 |
| ralonsoh | stephenfin, yes, but I'm reviewing the code and if the extension is not enabled, this information won't be there, in the FIP | 14:47 |
| sean-k-mooney | i dont really like basing the behavior off what the current vms are using | 14:47 |
| efried | gibi, bauzas: To close on group_policy: sean-k-mooney and I talked about it a bit yesterday and decided that, in order to support both NUMA and bandwidth, we need to retain the group_policy=none default and do the anti-affinity in the NTF | 14:48 |
| efried | UNTIL we can design & implement proper granular anti-affinity syntax in placement, which IMO is too ambitious for Ussuri. | 14:48 |
| efried | sean-k-mooney: +1 | 14:48 |
| sean-k-mooney | efried: keep in mind that almost all host are numa hosts | 14:48 |
| dansmith | sean-k-mooney: in reality, ALL of them are | 14:48 |
| efried | meaning almost all hosts are *capable* of NUMA. | 14:48 |
| efried | Not that all hosts are hosting NUMA-aware instances. | 14:48 |
| sean-k-mooney | dansmith: yes | 14:48 |
| dansmith | not capable, they are numa and if not configured, are losing performance to that fact | 14:48 |
| sean-k-mooney | efried: correct | 14:49 |
| *** vishalmanchanda has joined #openstack-nova | 14:49 | |
| efried | right, which some VMs don't care about. | 14:49 |
| stephenfin | ralonsoh: WDYM? As I understood it, we won't have the 'port_details' field but the 'device_id' field will still be there in the ports API response, right? | 14:49 |
| sean-k-mooney | efried: no i think dansmit ment at the host level. not the vm level | 14:49 |
| dansmith | efried: no, they all care about it, just some operators don't care to take on the burden of configuring it because we make it so difficult | 14:49 |
| ralonsoh | stephenfin, no no | 14:49 |
| dansmith | nobody is opting out of numa for any reason other than the cost benefit isn't there for configuring it | 14:50 |
| ralonsoh | stephenfin, if you don't have 'port_details', you won't have this info | 14:50 |
| stephenfin | ohhhh, they're tied together | 14:50 |
| stephenfin | ? | 14:50 |
| ralonsoh | stephenfin, if you really need the host but you don't have 'port_details' | 14:50 |
| efried | dansmith: oh? Not because opting out lets them squeeze more VMs onto their host? | 14:50 |
| ralonsoh | then you have the "port_id" always | 14:50 |
| sean-k-mooney | efried: well it depends | 14:50 |
| ralonsoh | stephenfin, and then, you can call the Neutron API to retrieve the port info (and the host) | 14:50 |
| sean-k-mooney | in general no | 14:51 |
| efried | yes, it depends, that's what I'm saying. | 14:51 |
| sean-k-mooney | but if you use pinning or hugepage that disable oversubsription or cpus or memroy | 14:51 |
| dansmith | efried: only because complexity of what we provide makes that increasingly difficult as density increases | 14:51 |
| sean-k-mooney | if you jsut use numa over subsription is allowed | 14:51 |
| efried | right, and that's not a fitting problem we're going to solve any time soon. | 14:51 |
| bauzas | I feel we need to define a clear upgrade path | 14:52 |
| stephenfin | ralonsoh: I'm confused. You seem to be saying the same thing as me :) Let me try again | 14:52 |
| bauzas | 1/ for NUMA-aware instances | 14:52 |
| bauzas | 2/ for non-NUMA-aware instances | 14:52 |
| efried | 1/ flip the switch | 14:52 |
| efried | 2/ don't | 14:52 |
| efried | If we've already decided we're going to segregate, it really is that simple. | 14:53 |
| sean-k-mooney | so the boolean config option allows us to punt on the final decission on this for a cycle or two. | 14:53 |
| dansmith | is there some reason that the switch can't be flipped for everyone? | 14:53 |
| sean-k-mooney | e.g. default to on | 14:53 |
| sean-k-mooney | and you opt out? | 14:53 |
| *** links has quit IRC | 14:53 | |
| dansmith | having compute nodes behave like one thing or another isn't something I'd like to see us doing long-term | 14:53 |
| bauzas | we could also have an implicit switch | 14:53 |
| bauzas | like, if you ask for mempages, then basically you ask for NUMA things | 14:54 |
| bauzas | (even if, and I hate to say, is unrelated) | 14:54 |
| bauzas | or cpu_pin | 14:54 |
| bauzas | or whatever | 14:54 |
| efried | dansmith: the reason we didn't want to do that is because, if your priority is "land my VM", that becomes difficult/impossible as your cloud reaches saturation. | 14:54 |
| sean-k-mooney | bauzas: those are properties fo teh guest | 14:54 |
| dansmith | efried: that is specifically called out in our project scope as not a problem nova solves | 14:54 |
| sean-k-mooney | bauzas: not of the host | 14:54 |
| stephenfin | ralonsoh: I can do 'GET /floatingips' (or whatever the API is). Each item in the response may contain a 'port_details' field but only if this extension is enabled. Correct? | 14:55 |
| dansmith | efried: i.e. fitting the last VM into available memory | 14:55 |
| bauzas | sean-k-mooney: for cpu pinset, it's for host | 14:55 |
| bauzas | but I agree with large pages | 14:55 |
| bauzas | dammit, I'm torn | 14:55 |
| ralonsoh | stephenfin, exactly, the key 'port_details' will be there only if the extension is enabled | 14:55 |
| sean-k-mooney | ya so we could enable it by default if you have defiend cpu_dedicated_set | 14:55 |
| efried | bauzas: that's backwards though. If you ask the scheduler for large pages, you're asking to land on a host that knows how to do that. You can't use that question to decide to make a host large page-aware. | 14:56 |
| sean-k-mooney | if cpu_dedicated_set is defiend then you are reporting PCPU and the only instance that can consume PCPUs have a numa toplogy | 14:56 |
| *** pcaruana has joined #openstack-nova | 14:56 | |
| sean-k-mooney | so that is once case where yes we can implcitly enable the numa reporting | 14:56 |
| efried | dansmith: So how did we get to a point where we decided it was important to segregate the cloud? Hate to drag you into a second simultaneous discussion stephenfin, but weren't you part of that? | 14:57 |
| stephenfin | ralonsoh: Okay. So if I do 'GET /ports/{port_id}', will that response always contain a 'device_id' field? If not, is this because it's provided by the same extension? | 14:57 |
| sean-k-mooney | having hugepages allocated on the host is not really a good enough reason in my book and we should not assume that all numa hosts use cpu pinning | 14:57 |
| bauzas | sean-k-mooney: right, that's my point | 14:57 |
| *** artom has joined #openstack-nova | 14:57 | |
| bauzas | you could only care about large pages or just standard NUMA sharding | 14:58 |
| dansmith | efried: segregate what? numa and non-numa instances? | 14:58 |
| sean-k-mooney | bauzas: well you could be useing the hugepages on the host for a dpdk vswitch for example | 14:58 |
| efried | yes | 14:58 |
| sean-k-mooney | it might not be for the vms | 14:58 |
| bauzas | like, "I want 2 vCPUs on the same NUMA node" doesn't absolutely require CPU pinning | 14:58 |
| stephenfin | efried: Because we can't make everything have NUMA | 14:58 |
| ralonsoh | stephenfin, exactly https://github.com/openstack/neutron/blob/master/neutron/db/db_base_plugin_common.py#L231 | 14:58 |
| efried | stephenfin: right, so dansmith wants to know why not | 14:58 |
| sean-k-mooney | bauzas: right that just need hw:numa_nodes=1 | 14:58 |
| ralonsoh | stephenfin, the device_id will be there | 14:59 |
| sean-k-mooney | bauzas: i use hugepages on my home system but not pinning | 14:59 |
| stephenfin | efried: 2 sockets w/ a 32 core CPU in each socket (no HyperThreading). Go boot a 33 core instance | 14:59 |
| bauzas | either way, I think we need to move forward | 14:59 |
| sean-k-mooney | bauzas: beacue i want cpu oversubscition but not memory over subscrtion | 14:59 |
| bauzas | I'll write the new revision with a bool flag and mention the alternative of an automatic all-NUMA world in the spec | 15:00 |
| stephenfin | You can't because the instance will no longer split across the NUMA nodes, and we don't let an instance oversubscribe against itself | 15:00 |
| bauzas | people will chime in and we'll see | 15:00 |
| * efried <== choir stephenfin | 15:00 | |
| efried | dansmith: --^ | 15:00 |
| dansmith | stephenfin: efried: because what nova currently provides is "no numa means 1 numa" yeah? | 15:00 |
| sean-k-mooney | efried: yes we are aware that is the giant vm case. | 15:00 |
| stephenfin | ralonsoh: It will *always* be there? | 15:00 |
| stephenfin | dansmith: No, no NUMA means no NUMA | 15:00 |
| ralonsoh | stephenfin, yes | 15:00 |
| stephenfin | currently | 15:00 |
| *** tbachman has joined #openstack-nova | 15:01 | |
| bauzas | dansmith: nova currently provides "I can spread my VM across many NUMA nodes if I don't care' | 15:01 |
| dansmith | stephenfin: how is no numa and 1 numa node different to theguest/ | 15:01 |
| ralonsoh | stephenfin, in the port this key, "device_id", is mandatory | 15:01 |
| sean-k-mooney | dansmith: in the guest it does not | 15:01 |
| dansmith | bauzas: right, we lie and say it's one node when it's not you mean? | 15:01 |
| dansmith | sean-k-mooney: right exactly | 15:01 |
| bauzas | dansmith: while that being broken if you turn into the new modeling | 15:01 |
| sean-k-mooney | dansmith: but if you do hw:numa_nodes=1 we require that he guest virtual numa node be mapped to at most 1 host numa node | 15:01 |
| stephenfin | It's not for the guest, but we insist on 1 guest NUMA node being mapped to one host NUMA node | 15:02 |
| sean-k-mooney | and that is where it breaks | 15:02 |
| dansmith | so my point is, for the giant vm case right now, we either require you to ignore or be insulated from the numaness that *does* exist, or configure it in a detailed fashion | 15:02 |
| bauzas | dansmith: it's a breaking change tbc | 15:02 |
| stephenfin | dansmith: correct | 15:02 |
| bauzas | that's the proposal | 15:02 |
| dansmith | that's all I'm saying.. nobody is opting *into* this behavior, they're choosing it because it's less bad than having to hand configure flavors | 15:02 |
| dansmith | ...for their giant vms | 15:03 |
| stephenfin | don't use anything that would configure NUMA (hw:numa_nodes, hw:cpu_policy=dedicated, hw:mem_page_size=foo) or hand tune for your chosen host topology | 15:03 |
| stephenfin | dansmith: Yup, agreed | 15:03 |
| dansmith | efried: ^ | 15:03 |
| openstackgerrit | Kashyap Chamarthy proposed openstack/nova-specs master: Re-propose "Secure Boot support for KVM & QEMU guests" for Ussuri https://review.opendev.org/693844 | 15:03 |
| bauzas | the ideal would be us being able to serve an instance request *not* asking for NUMA with a NUMA-aware inventory | 15:03 |
| bauzas | because if so, we would just make the switch for *all* hosts | 15:04 |
| dansmith | right | 15:04 |
| dansmith | and | 15:04 |
| dansmith | we'd not be pretending with the topology | 15:04 |
| stephenfin | ralonsoh: Thanks! So I'm going to rework this to check if the port details extension is enabled. If it is, use 'device_id' from that. If it is not, make a second request to '/ports/{port_id}' and extract 'device_id' from that | 15:04 |
| stephenfin | ralonsoh: Does that sound reasonable? | 15:04 |
| efried | Am I understanding that you can't boot a huge VM today either? | 15:05 |
| stephenfin | ralonsoh: And assuming you're not planning to fix this yourself. If you've started, please continue :) | 15:05 |
| bauzas | so, basically, the flag is just an expression of us being unable to serve such query :( | 15:05 |
| bauzas | a technical limitation of our own | 15:05 |
| sean-k-mooney | efried: you can but only if you use no numa feature | 15:05 |
| ralonsoh | stephenfin, no, I didn't start doing it hehehe | 15:05 |
| ralonsoh | stephenfin, but yes, this should be the procedure | 15:05 |
| sean-k-mooney | or you use multiple guset numa nodes | 15:05 |
| stephenfin | efried: You can but only if you don't configure anything with NUMA | 15:05 |
| sean-k-mooney | got to join a call | 15:05 |
| stephenfin | darn, ninja'd by sean-k-mooney | 15:05 |
| efried | Feel like that came all the way back in a circle. | 15:05 |
| *** dtantsur is now known as dtantsur|afk | 15:06 | |
| stephenfin | efried: the original question was why can't we always report NUMA to placement, yeah? | 15:06 |
| efried | IOW to boot a huge instance today, you can artificially give it a multi-numa topo, or you can say nothing about NUMA. | 15:07 |
| efried | And the proposal we started the morning with would allow you to do the same. | 15:07 |
| efried | But now we're considering removing that first possibility by forcing all hosts to be NUMA-aware. | 15:07 |
| efried | sorry, removing the *second* possibility | 15:07 |
| stephenfin | I don't think it's possible to force all hosts to be NUMA-aware | 15:08 |
| bauzas | that's the crux of the problem | 15:09 |
| efried | stephenfin: I thought we had this all sussed out. I thought we were going to segregate the cloud into NUMA-aware (placement resources split along NUMA RPs) and non-NUMA-aware (what it looks like today, with all proc/mem on the root RP) hosts | 15:09 |
| efried | And you could only boot flavors with hw:numa*isms into the former; and you could only boot flavors *without* numa*isms into the latter. | 15:09 |
| efried | But dansmith has been arguing against that. | 15:09 |
| bauzas | are we able nowadays to express a placement query for a large VM with a NUMA-aware host ? | 15:09 |
| bauzas | given the new proposal you made in the etherpad | 15:10 |
| stephenfin | Agree on the first point | 15:10 |
| dansmith | efried: dude, can you let up a bit? I think multiple people are saying it would be nice to not have this restriction, no? | 15:10 |
| *** sapd1_x has quit IRC | 15:10 | |
| stephenfin | Don't recall agreeing to the latter | 15:10 |
| bauzas | like, "I want 8 VCPUs" can it be satisfied with 4 CPUs on each NUMA node ? | 15:10 |
| dansmith | efried: I'm not demanding anything, I'm just saying I don't think that expecting to need to segregate the fleet forever is the best long term plan | 15:10 |
| efried | It would be nice, but (and again I may be misremembering the discussions) I thought we decided to compromise because that would be too hard to do. | 15:11 |
| bauzas | like, could we assume a specific query attribute to placement unless others are expressed ? | 15:11 |
| efried | bauzas: no, that doesn't work. | 15:11 |
| bauzas | efried: I'm just challenging this idea | 15:11 |
| efried | bauzas: we've been down that road before -- that was the thing where you would have to ask for individual MB of memory in a zillion granular groups with group_policy=none, remember? | 15:12 |
| bauzas | I see | 15:12 |
| efried | We also proposed can_split to help with that, but abandoned the idea for reasons. | 15:13 |
| bauzas | yeah, I was considering can_spit | 15:13 |
| bauzas | split heh | 15:13 |
| efried | one reason was that it was going to be really hard to make the syntax work properly | 15:13 |
| efried | But the other reason was that we had decided on the above architecture and designed same_subtree etc. to accommodate it. | 15:13 |
| bauzas | like, until we somehow have a placement construction that allows us to 'spread a query across multiple RPs', then the option is mandatory :( | 15:14 |
| stephenfin | dansmith: Yeah, no reason this opt-out of NUMA behavior couldn't be phased out over multiple releases | 15:14 |
| dansmith | stephenfin: that's specifically what I'm saying | 15:14 |
| efried | stephenfin: so in order to fit my large VM, I would have to specify multiple NUMA nodes? | 15:14 |
| efried | ...in that future release? | 15:15 |
| stephenfin | efried: Yup | 15:15 |
| stephenfin | Or turn off NUMA on your host | 15:15 |
| stephenfin | It's usually tucked away in the BIOS | 15:15 |
| dansmith | from the user's perspective, | 15:15 |
| efried | okay, I didn't know that was even an option. So the driver would report effectively a single NUMA node in that case | 15:16 |
| stephenfin | correct | 15:16 |
| efried | well shit | 15:16 |
| stephenfin | fwiw, this is the same decision we made with the thread policies | 15:16 |
| dansmith | if we had a hw:numa_hodes_min= thing, then they could express in the flavor whether they *need* two numa nodes, or are willing to *tolerate* multiple nodes, the current thing being the upper limit if both specified, right? | 15:16 |
| bauzas | I need to come to a conclusion because parenting taxi duties | 15:16 |
| dansmith | the fact that we've backed ourselves into a corner with placement and expressivity notwithstanding | 15:17 |
| efried | dansmith: So yeah, I was going to address that. The problem is that we have no way to translate that into placement... yeah. | 15:17 |
| bauzas | A/ we are about to propose a flag for allowing NUMA architecture | 15:17 |
| stephenfin | dansmith: the biggest issues with that is that we've to make multiple requests to placement at the moment | 15:17 |
| bauzas | B/ we're not intending to remove this flag in a foreseenable future | 15:17 |
| dansmith | efried: and I'm saying that sucks for the users, and why they're opting into the dumb behavior (whether through nova or bios) because _we_ can't figure out how to organize our own data | 15:18 |
| bauzas | C/ we explicity ask our operators to turn this flag on to allow them to boot NUMA-aware guests on such hosts | 15:18 |
| dansmith | stephenfin: yep, understand | 15:18 |
| stephenfin | i.e. give me a host that can fit all N in 1 NUMA node, else give me one that fit them in 2 nodes, ... | 15:18 |
| stephenfin | *all N instance cores | 15:18 |
| efried | stephenfin: but if in 2 nodes, we can split evenly or asymmetrically... | 15:18 |
| bauzas | D/ I state in the alternatives section that this whole plan sucks because we miss placement expressivity | 15:18 |
| bauzas | WFY folks ? | 15:18 |
| * bauzas needs to go AFK | 15:19 | |
| dansmith | efried: right, and we'd want some "minimum split is 70/30" type expression too.. I get that it's not something we can do today, and will be harder to land that across now two separate projects | 15:19 |
| dansmith | I'm just saying, the user sees this as a rock and a hard place, with no real-life justification for it | 15:19 |
| * bauzas now drops | 15:20 | |
| bauzas | ttyl later folks and will scroll back | 15:20 |
| dansmith | I guess if you don't care about a specific topology, you want the same percentage of memory on each node as cpus | 15:20 |
| sean-k-mooney | ok back | 15:20 |
| gibi | efried: thanks the summary about group_policy, it works fo me | 15:20 |
| stephenfin | efried: yeah, correct, otherwise you force people to use those awful 'hw:numa.cpu{N}=<cpumap>' extra specs | 15:20 |
| stephenfin | dansmith: sure, though it's a bit of weird one, implementation wise | 15:21 |
| stephenfin | because placement will give us e.g. a 70/30 split on cores, but we wouldn't really be reflecting this in the pinning of the instance to the host | 15:22 |
| *** eharney has joined #openstack-nova | 15:22 | |
| stephenfin | so we'll have to be careful not to do strict NUMA memory affinity in that case | 15:22 |
| dansmith | yeah | 15:22 |
| dansmith | presumably there's a middle ground between fully constrained and unconstrained, | 15:23 |
| dansmith | where your vcpus are constrained to only run on cores that are on the numa node they represent, right? | 15:23 |
| stephenfin | Correct. That's what happens when you turn on a NUMA topology without pinning at the moment | 15:23 |
| dansmith | you balance between cores looser than pinning, but... right okay | 15:23 |
| stephenfin | i.e. use 'hw:numa_nodes' or 'hw:mem_page_size' | 15:24 |
| dansmith | that seems fine to me then | 15:24 |
| stephenfin | We "pin" to the whole range of enabled cores from N NUMA nodes | 15:24 |
| stephenfin | rn there's no way to say give me N $resource from adjacent/child providers, right? That's what the 'can_split' thing was supposed to do? | 15:24 |
| dansmith | if placement were able to cough up a topology for 1-2 numa nodes (i.e. i don't care) and then I get vcpus loosely pinned to cores on the right numa node according to the memory split... | 15:25 |
| stephenfin | yeah, ideal | 15:25 |
| dansmith | aye | 15:25 |
| stephenfin | I guess to retain the current behavior, you'd cough up a topology for *all* NUMA nodes on the host | 15:26 |
| stephenfin | but we can't do that since it would break e.g. a 1 core instance on a 2 node host | 15:26 |
| dansmith | that's why it has to be a range I think | 15:26 |
| stephenfin | yup | 15:26 |
| sean-k-mooney | you know we can totally allcoate memroy from multiple host numa nodes and expose it as one gues numa node with qemu right | 15:27 |
| sean-k-mooney | same with cores | 15:27 |
| dansmith | sure, but that's not helpful | 15:27 |
| efried | isn't that what we do today for a don't-care-about-NUMA guest? | 15:27 |
| efried | and is the exact flexibility we're talking about getting rid of? | 15:28 |
| dansmith | nobody is asking to be lied to :) | 15:28 |
| sean-k-mooney | dansmith: well im jsut saying we can always use the resources that correspond to the placmenet allcaotion and expose a different virtual numa toplogy if we were willing to not require the 1:1 mapping unless you said you cared about numa | 15:28 |
| dansmith | efried: no, that's not flexibility | 15:28 |
| dansmith | efried: nobody is asking for "show me one numa node even though that's not the truth" | 15:29 |
| sean-k-mooney | efried: lie to it yes | 15:29 |
| mriedem | ignorance is bliss | 15:29 |
| efried | If I ask for a sausage, I'm going to be fine if the sausage is beef or pork. | 15:29 |
| efried | If I ask for a kosher sausage, I'm going to be upset if it's pork. | 15:29 |
| dansmith | sean-k-mooney: gotcha | 15:29 |
| efried | It's not about being lied to. It's about not caring. | 15:29 |
| dansmith | sigh | 15:30 |
| efried | I'm not convinced that everyone cares. | 15:30 |
| dansmith | if we lie to the guest, then the guest *os* is *going* to make bad decisions that don't represent what is actually being offered | 15:30 |
| dansmith | nobody wants that, | 15:30 |
| dansmith | they're opting into that over the more painful "care about this in extreme detail" | 15:30 |
| sean-k-mooney | efried: if you add hw:numa_nodes=1 to a random flavor we normaly expepct about a 20-30% performance improvment | 15:31 |
| efried | then isn't it the responsibility of the libvirt driver (not the scheduler) to take a generic simple request and make a real numa topo out of it? | 15:31 |
| sean-k-mooney | even thoughg it is still floating over cores and using 4k small pages | 15:31 |
| sean-k-mooney | just becuase the memroy and cpus all come form a single numa node | 15:32 |
| efried | iow if my host is configured monolithically in placement and my VM requests simply VCPU=N,MEMORY_MB=M, we'll place the VM even if (and without knowing) the resources have to be spread across NUMA nodes. | 15:33 |
| efried | Now it's the job of the driver (via the overloaded NTF, presumably?) to carve those N VCPUs and M MEMORY_MBs out of whatever NUMA nodes they're available in, and create the appropriate topo for the guest, no matter how many nodes that happens to be? | 15:33 |
| dansmith | no? the virt driver doesn't have visibility into enough of the (nova) system to make those kinds of decisions I don't think | 15:34 |
| sean-k-mooney | if we model numa in placment then the rps the allcoation come form force the dirver to allcoate the resouces form spefici host numa nodes | 15:34 |
| efried | yes, but then we *must* frame the request accordingly. | 15:34 |
| sean-k-mooney | yes | 15:35 |
| efried | that's the whole problem we're trying to avoid | 15:35 |
| sean-k-mooney | the only way to avoid that is to not repor tnuma in placment | 15:35 |
| efried | because, once again, the VM didn't care about the specifics of the NUMA topology. By making it a real one, of whatever shape, we're still conferring the perf advantages to the VM. But we would do that at the host, having decided there are enough resources in total. | 15:35 |
| dansmith | efried: the request is the important part here because we're talking about multiple computers.. the scheduler is looking for something that fits best amongst the options, not "well, we're on this host how do we best cram this into the hole we have" | 15:35 |
| efried | right, I'm saying from the perspective of the scheduler, any number of fits can be considered "best". | 15:36 |
| sean-k-mooney | right we use weighers to determin what best is | 15:36 |
| sean-k-mooney | we have disused the idea of have a weigher based on the allcoation candiate in the past | 15:36 |
| dansmith | which is why the scheduler doesn't pick actual resources, it picks hosts, and why before placement, we got that wrong a *lot* | 15:36 |
| dansmith | which means we reschedule, which is super expensive | 15:36 |
| sean-k-mooney | but that still does not change the fact that the placment query is the import thing to get right | 15:37 |
| dansmith | sean-k-mooney: agreed | 15:37 |
| sean-k-mooney | in the non numa case if we had a weigher and we had 1 allcoation candiate with 1 numa node and another with 2 we could chosse the singel numa node | 15:37 |
| sean-k-mooney | but i dont know how to allow that today with the /ac api | 15:38 |
| sean-k-mooney | that is kind fo what can_split was ment to solve but that is not a thing currnly | 15:38 |
| sean-k-mooney | in the non numa case we would jsut lump everything in the un numberd group and say you can split the vcpus and ram | 15:39 |
| sean-k-mooney | then weigh by the least number of numa nodes | 15:39 |
| sean-k-mooney | but i dont see that happening anytime soon | 15:40 |
| *** jmlowe has quit IRC | 15:43 | |
| *** jaosorior has quit IRC | 15:43 | |
| efried | Agreed. | 15:45 |
| efried | So barring the ideal | 15:45 |
| efried | we agreed on this 80/20 approach | 15:45 |
| sean-k-mooney | with the partioning of the cloud | 15:45 |
| efried | yes | 15:45 |
| sean-k-mooney | ya so you know way way way back before numa and pinning was merged they was a counter propoal to make them host wide config options | 15:46 |
| sean-k-mooney | we are slowly getting back to that | 15:46 |
| efried | so that we can have one simple placement query for non-NUMA | 15:47 |
| efried | and one complex strict placement query for NUMA | 15:47 |
| efried | and almost never have to reschedule in either case. | 15:47 |
| sean-k-mooney | yes although i think at some point we will want to have 1 code path | 15:47 |
| efried | That's the 20 | 15:47 |
| sean-k-mooney | yes but it could also be a refinment of scope | 15:48 |
| efried | a refinement of scope for Ussuri? | 15:48 |
| efried | or adding restrictions in future releases? | 15:48 |
| sean-k-mooney | no. if we say all vms are numa vms in the future we reduce fucntionality as we did with cpu pinning | 15:48 |
| sean-k-mooney | but make this all simpler | 15:48 |
| sean-k-mooney | efried: to model PCPUs in placment we reduced the funcatiolity of the thread policies | 15:49 |
| sean-k-mooney | we could in a future relase consider the same here | 15:49 |
| *** jmlowe has joined #openstack-nova | 15:49 | |
| stephenfin | ralonsoh: One more question regarding this comment -> "The same patch also introduced an error when retrieving the network ID. The network ID is stored in a key named 'floating_network_id'" | 15:49 |
| sean-k-mooney | every time we try to do that we end up makeing no progress at all | 15:50 |
| sean-k-mooney | so im saying defer to V+ and take the incremental improvment in U | 15:50 |
| ralonsoh | stephenfin, you don't have the network name, only the network ID in this key 'floating_network_id'" | 15:50 |
| stephenfin | ralonsoh: Ah, so I don't think that's an issue since I'm building that field myself https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L2593-L2600 | 15:51 |
| stephenfin | ralonsoh: My question is would that make a good extension for neutron (adding 'network_details' to complement 'port_details') | 15:51 |
| sean-k-mooney | stephenfin: you should proably swap to using .get() for all those filed lookups by the way | 15:52 |
| ralonsoh | stephenfin, ahhhhh ok. BTW, do you really need to make this call? This is expensive and the ID, IMO, is good enough | 15:52 |
| stephenfin | tbf, we only need that information for this one (deprecated) API, but maybe it would be useful for others | 15:52 |
| ralonsoh | stephenfin, unless you specifically need the name | 15:52 |
| *** jmlowe has quit IRC | 15:52 | |
| ralonsoh | this could be an optimization, avoiding this "show_network" call | 15:53 |
| stephenfin | ralonsoh: Unfortunately, yes. It's a deprecated API but we expect to return network names first | 15:53 |
| ralonsoh | stephenfin, okidoki | 15:53 |
| stephenfin | I could probably make it optional for this deprecated API. Let me investigate that | 15:53 |
| stephenfin | ralonsoh: Wait, I lied. I've another question :) The 'alias' field will always be present in the 'GET /v2.0/extensions' response, right? https://docs.openstack.org/api-ref/network/v2/?expanded=list-extensions-detail#id5 | 15:57 |
| ralonsoh | stephenfin, let met check | 15:57 |
| stephenfin | We're caching the extension name and I've no idea why, because the alias seems a lot better to use a reference constant https://github.com/openstack/nova/blob/master/nova/network/neutron.py#L1254-L1255 | 15:58 |
| *** ociuhandu has quit IRC | 15:58 | |
| *** ociuhandu has joined #openstack-nova | 15:59 | |
| *** udesale has quit IRC | 16:00 | |
| *** tbachman has quit IRC | 16:02 | |
| *** mkrai has quit IRC | 16:04 | |
| *** ociuhandu has quit IRC | 16:04 | |
| ralonsoh | stephenfin, sorry, I took my a while, this is not a regular DB call | 16:05 |
| ralonsoh | stephenfin, the call returns a list of this | 16:05 |
| ralonsoh | <class 'dict'>: {'name': 'Address scope', 'alias': 'address-scope', 'description': 'Address scopes extension.', 'updated': '2015-07-26T10:00:00-00:00', 'links': []} | 16:06 |
| ralonsoh | (this is one element of the list) | 16:06 |
| *** eharney has quit IRC | 16:06 | |
| stephenfin | okay, so alias will always be there | 16:06 |
| stephenfin | I'll rework that to use aliases so | 16:06 |
| stephenfin | much clearer, IMO | 16:06 |
| ralonsoh | yes and this is something static | 16:06 |
| ralonsoh | sure, you can consider the alias as a constant | 16:06 |
| ralonsoh | and it's in neutron-lib | 16:06 |
| stephenfin | Bug fix done too. Just fixing up tests | 16:06 |
| *** lpetrut has quit IRC | 16:16 | |
| *** gyee has joined #openstack-nova | 16:17 | |
| *** Sundar has joined #openstack-nova | 16:17 | |
| *** eharney has joined #openstack-nova | 16:19 | |
| huaqiang | stephenfin: for the mixed vCPU instance spec https://review.opendev.org/#/c/668656/, do you have more comments? | 16:20 |
| huaqiang | I know there is no concensus now | 16:20 |
| huaqiang | should I raise a discussion in Thursday's team meeting? | 16:21 |
| huaqiang | which way is better for you? | 16:21 |
| *** mlavalle has joined #openstack-nova | 16:22 | |
| kashyap | stephenfin: That rST thing on line-38 didn't work out, afraid; going to revert to using explicit references (https://review.opendev.org/#/c/693844/5/specs/ussuri/approved/allow-secure-boot-for-qemu-kvm-guests.rst) | 16:22 |
| *** ociuhandu has joined #openstack-nova | 16:26 | |
| *** slaweq_ has joined #openstack-nova | 16:30 | |
| *** maciejjozefczyk has quit IRC | 16:32 | |
| *** slaweq has quit IRC | 16:33 | |
| *** jamesdenton has joined #openstack-nova | 16:39 | |
| huaqiang | which way is better for you? | 16:41 |
| *** ociuhandu has quit IRC | 16:44 | |
| *** ociuhandu has joined #openstack-nova | 16:45 | |
| *** ociuhandu has quit IRC | 16:46 | |
| *** ociuhandu has joined #openstack-nova | 16:46 | |
| stephenfin | huaqiang: Sorry, been working on a bug. I'll try look at that before the meeting but it would be good to bring up anyway | 16:52 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: Handle neutron without the fip-port-details extension https://review.opendev.org/705760 | 16:52 |
| stephenfin | ralonsoh: ^ | 16:52 |
| ralonsoh | stephenfin, reviewing it | 16:52 |
| stephenfin | efried, dansmith, bauzas: Apparently this is breaking neutron's gate so we should get this in once it's green | 16:52 |
| bauzas | mmmm ok | 16:52 |
| stephenfin | I ran/fixed a subset of tests that I though might break | 16:52 |
| stephenfin | *thought | 16:52 |
| efried | sounds like a review for gibi | 16:53 |
| stephenfin | oh, how'd I forget gibi | 16:53 |
| gibi | ack | 16:54 |
| gibi | but in 5 minutes it is beertime here | 16:54 |
| stephenfin | I bet you can get this done in 4 though | 16:54 |
| efried | heh | 16:54 |
| stephenfin | ;) | 16:54 |
| openstackgerrit | Sasha Andonov proposed openstack/nova master: rbd_utils: increase _destroy_volume timeout https://review.opendev.org/705764 | 16:55 |
| gibi | working on it ... | 16:55 |
| gibi | done. | 16:58 |
| gibi | in 3 | 16:58 |
| gibi | :D | 16:58 |
| *** lbragstad_ is now known as lbragstad | 16:59 | |
| * gibi runs away | 16:59 | |
| *** tesseract has quit IRC | 17:04 | |
| *** luksky has quit IRC | 17:07 | |
| openstackgerrit | Kashyap Chamarthy proposed openstack/nova-specs master: Re-propose "Secure Boot support for KVM & QEMU guests" for Ussuri https://review.opendev.org/693844 | 17:14 |
| *** nweinber_ has joined #openstack-nova | 17:17 | |
| *** ociuhandu has quit IRC | 17:20 | |
| *** ociuhandu has joined #openstack-nova | 17:20 | |
| *** tbachman has joined #openstack-nova | 17:22 | |
| *** Sundar has quit IRC | 17:24 | |
| *** sandonov has quit IRC | 17:24 | |
| *** ociuhandu_ has joined #openstack-nova | 17:25 | |
| *** rpittau is now known as rpittau|afk | 17:27 | |
| *** ociuhandu has quit IRC | 17:29 | |
| *** ociuhandu_ has quit IRC | 17:30 | |
| *** evrardjp has quit IRC | 17:33 | |
| *** evrardjp has joined #openstack-nova | 17:34 | |
| gmann | stephenfin: cmurphy melwitt alex_xu this is ready to re-review now. - https://review.opendev.org/#/c/701624/ | 17:35 |
| cmurphy | thanks gmann | 17:35 |
| *** ociuhandu has joined #openstack-nova | 17:35 | |
| *** davidsha_ has quit IRC | 17:35 | |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: Handle neutron without the fip-port-details extension https://review.opendev.org/705760 | 17:38 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: Avoid calling neutron for N networks https://review.opendev.org/705784 | 17:38 |
| stephenfin | ralonsoh: ^ | 17:38 |
| ralonsoh | stephenfin, I'm on it now | 17:38 |
| *** ociuhandu has quit IRC | 17:40 | |
| *** luksky has joined #openstack-nova | 17:50 | |
| *** martinkennelly has quit IRC | 17:52 | |
| *** igordc has joined #openstack-nova | 17:53 | |
| *** derekh has quit IRC | 18:00 | |
| *** tosky has quit IRC | 18:01 | |
| *** damien_r has quit IRC | 18:03 | |
| openstackgerrit | Vladyslav Drok proposed openstack/nova master: Minor improvements to cell commands https://review.opendev.org/698053 | 18:09 |
| *** ralonsoh has quit IRC | 18:15 | |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: Use extension aliases, not names https://review.opendev.org/705792 | 18:22 |
| *** tbachman_ has joined #openstack-nova | 18:29 | |
| *** tbachman has quit IRC | 18:30 | |
| *** tbachman_ is now known as tbachman | 18:30 | |
| gmann | melwitt: this is ready from gate side to change your vote from +1 -> +2 - https://review.opendev.org/#/c/705135/4 | 18:34 |
| gmann | you can see the tests of other-projects-context working as expected in https://review.opendev.org/#/c/705126/7 | 18:35 |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in os-attach-interfaces https://review.opendev.org/705799 | 18:49 |
| *** gyee has quit IRC | 19:00 | |
| *** nweinber has quit IRC | 19:00 | |
| *** Anticimex has quit IRC | 19:00 | |
| *** dtantsur|afk has quit IRC | 19:00 | |
| *** gyee has joined #openstack-nova | 19:02 | |
| *** nweinber has joined #openstack-nova | 19:02 | |
| *** Anticimex has joined #openstack-nova | 19:02 | |
| *** dtantsur|afk has joined #openstack-nova | 19:02 | |
| *** dtantsur|afk has quit IRC | 19:03 | |
| *** nweinber has quit IRC | 19:13 | |
| *** dtantsur has joined #openstack-nova | 19:15 | |
| *** vishalmanchanda has quit IRC | 19:53 | |
| *** jmlowe has joined #openstack-nova | 20:00 | |
| *** jmlowe has quit IRC | 20:05 | |
| openstackgerrit | Mykola Yakovliev proposed openstack/nova master: Fix boot_roles in InstanceSystemMetadata https://review.opendev.org/698040 | 20:24 |
| *** bbowen has quit IRC | 20:33 | |
| *** eharney has quit IRC | 20:40 | |
| *** jamesdenton has quit IRC | 20:48 | |
| *** TxGirlGeek has joined #openstack-nova | 21:01 | |
| *** umbSublime has joined #openstack-nova | 21:18 | |
| *** bbowen has joined #openstack-nova | 21:27 | |
| *** sean-k-mooney has quit IRC | 21:31 | |
| openstackgerrit | Michael Bayer proposed openstack/nova master: remove DISTINCT ON SQL instruction that does nothing on MySQL https://review.opendev.org/705850 | 21:38 |
| *** luksky has quit IRC | 21:41 | |
| *** xek has quit IRC | 21:42 | |
| *** eharney has joined #openstack-nova | 21:45 | |
| *** dpawlik has quit IRC | 22:00 | |
| *** spatel has joined #openstack-nova | 22:02 | |
| *** eharney has quit IRC | 22:04 | |
| *** sean-k-mooney has joined #openstack-nova | 22:05 | |
| *** spatel has quit IRC | 22:06 | |
| gmann | does anyone know way/hack to skip the deps installation while creating tox env | 22:07 |
| gmann | this could have helpful for me to fix <py3.6 - https://github.com/tox-dev/tox/issues/410 | 22:07 |
| gmann | stephenfin: ^^ | 22:07 |
| *** sean-k-mooney has quit IRC | 22:10 | |
| *** eharney has joined #openstack-nova | 22:10 | |
| *** sean-k-mooney has joined #openstack-nova | 22:10 | |
| *** sean-k-mooney has quit IRC | 22:23 | |
| *** sean-k-mooney has joined #openstack-nova | 22:23 | |
| *** damien_r has joined #openstack-nova | 22:28 | |
| *** nweinber_ has quit IRC | 22:28 | |
| *** damien_r has quit IRC | 22:32 | |
| openstackgerrit | Merged openstack/nova master: nova-net: Remove use of legacy 'Network' object https://review.opendev.org/697154 | 22:42 |
| efried | gmann: Can't you just hack out the relevant lines of the tox.ini section? | 22:48 |
| efried | or is this something you want to be able to do in a merged patch? | 22:48 |
| gmann | efried: config value we can set via skip_install but i wanted to skip while we create tox at runtime | 22:48 |
| gmann | on stable branch where i want to skip the master upper constraint dep hard coded in tempest.tox.ini master branch. | 22:49 |
| gmann | anyways i did it via env var to use stable constraint - https://review.opendev.org/#/c/705089/4/lib/tempest@703 | 22:49 |
| sean-k-mooney | there is a hack where you can just touch i think the egg.info file locally or somehting | 22:49 |
| sean-k-mooney | i know stephenfin had a way to work around it in the past | 22:50 |
| efried | Yeah, I'm still confused as to whether you're talking about needing to do it locally or in "prod". | 22:50 |
| gmann | ohk, that will be good to do instead of global env var at least for my local run on stable | 22:50 |
| gmann | efried: locally as well as in stable branches jobs testing | 22:51 |
| sean-k-mooney | im not sure if that will work in this case or not i just know he used to do something like that to skip instlaling deps | 22:52 |
| gmann | at runtime ? and not via skip_install config value in tox.ini | 22:53 |
| gmann | runtime i mean while running tox env not in tox.ini | 22:54 |
| sean-k-mooney | yes i think he used to do touch <file> && tox -e ... | 22:55 |
| gmann | ohk. if that happens before installing deps then that is something i am looking for. | 22:57 |
| *** tosky has joined #openstack-nova | 22:57 | |
| *** mriedem has quit IRC | 22:59 | |
| *** slaweq_ has quit IRC | 23:03 | |
| efried | dansmith: Sorry, I got started, but ran out of time. I'll try to get to that patch (cyborg request groups) early tomorrow. | 23:06 |
| efried | I got to the point where I was starting to remember asking Sundar to make this look more like how we feed bandwidth requests into the RequestSpec, and this doesn't look like it's doing that (at least the way I expected). But I'll dig in more tomorrow. | 23:07 |
| *** eharney has quit IRC | 23:07 | |
| *** nweinber_ has joined #openstack-nova | 23:07 | |
| *** tkajinam has joined #openstack-nova | 23:09 | |
| *** slaweq_ has joined #openstack-nova | 23:11 | |
| dansmith | efried: okay, well, glad I waited then but..yeah, would be good if we can get that feedback in the queue so he has some time to address it | 23:13 |
| *** slaweq_ has quit IRC | 23:16 | |
| *** nweinber_ has quit IRC | 23:24 | |
| openstackgerrit | Michael Bayer proposed openstack/nova master: remove DISTINCT ON SQL instruction that does nothing on MySQL https://review.opendev.org/705850 | 23:30 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: Enable hard/soft reboot with accelerators. https://review.opendev.org/697940 | 23:40 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: Enable start/stop of instances with accelerators. https://review.opendev.org/699553 | 23:40 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: Enable and use COMPUTE_ACCELERATORS trait. https://review.opendev.org/699554 | 23:40 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: Bump compute rpcapi version and reduce Cyborg calls. https://review.opendev.org/704227 | 23:40 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: Add cyborg tempest job. https://review.opendev.org/670999 | 23:40 |
| *** tosky has quit IRC | 23:55 | |
| *** igordc has quit IRC | 23:55 | |
| sean-k-mooney | im still fleshing out the script and ill continue working on it tomorrow but i am still seeing arq bidning issues | 23:56 |
| sean-k-mooney | this is what i ahve so far http://paste.openstack.org/show/789138/ | 23:56 |
| sean-k-mooney | that was the error reported to the user http://paste.openstack.org/show/789139/ | 23:57 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!