| *** sapd1_x has joined #openstack-nova | 00:01 | |
| *** tiendc has joined #openstack-nova | 00:03 | |
| *** awalende has joined #openstack-nova | 00:08 | |
| *** tetsuro has joined #openstack-nova | 00:10 | |
| *** _erlon_ has quit IRC | 00:11 | |
| *** awalende has quit IRC | 00:13 | |
| *** sapd1_x has quit IRC | 00:32 | |
| *** wxy-xiyuan_ has joined #openstack-nova | 00:54 | |
| *** lxkong_ has joined #openstack-nova | 00:54 | |
| *** TheJulia_ has joined #openstack-nova | 00:54 | |
| *** NobodyCam_ has joined #openstack-nova | 00:54 | |
| *** kmalloc_ has joined #openstack-nova | 00:54 | |
| *** coreycb_ has joined #openstack-nova | 00:54 | |
| *** fyx_ has joined #openstack-nova | 00:54 | |
| *** csatari_ has joined #openstack-nova | 00:55 | |
| *** tinwood_ has joined #openstack-nova | 00:56 | |
| *** mriedem has joined #openstack-nova | 01:00 | |
| *** lchabert_ has joined #openstack-nova | 01:01 | |
| *** yedongcan has joined #openstack-nova | 01:02 | |
| *** NobodyCam has quit IRC | 01:02 | |
| *** kmalloc has quit IRC | 01:02 | |
| *** TheJulia has quit IRC | 01:02 | |
| *** Dinesh_Bhor has quit IRC | 01:02 | |
| *** coreycb has quit IRC | 01:02 | |
| *** csatari has quit IRC | 01:02 | |
| *** fyx has quit IRC | 01:02 | |
| *** lxkong has quit IRC | 01:02 | |
| *** tinwood has quit IRC | 01:02 | |
| *** dannins has quit IRC | 01:02 | |
| *** lchabert has quit IRC | 01:02 | |
| *** jonspw has quit IRC | 01:02 | |
| *** melwitt has quit IRC | 01:02 | |
| *** wxy-xiyuan has quit IRC | 01:02 | |
| *** kmalloc_ is now known as kmalloc | 01:02 | |
| *** NobodyCam_ is now known as NobodyCam | 01:02 | |
| *** lxkong_ is now known as lxkong | 01:02 | |
| *** TheJulia_ is now known as TheJulia | 01:02 | |
| *** lchabert_ is now known as lchabert | 01:02 | |
| *** coreycb_ is now known as coreycb | 01:02 | |
| *** csatari_ is now known as csatari | 01:02 | |
| *** wxy-xiyuan_ is now known as wxy-xiyuan | 01:02 | |
| *** fyx_ is now known as fyx | 01:02 | |
| *** irclogbot_1 has quit IRC | 01:05 | |
| *** ricolin has joined #openstack-nova | 01:05 | |
| *** irclogbot_2 has joined #openstack-nova | 01:06 | |
| *** Dinesh_Bhor has joined #openstack-nova | 01:08 | |
| *** gyee has quit IRC | 01:20 | |
| *** whoami-rajat has joined #openstack-nova | 01:24 | |
| *** melwitt has joined #openstack-nova | 01:24 | |
| *** brinzhang has joined #openstack-nova | 01:35 | |
| *** brinzhang has quit IRC | 01:36 | |
| imacdonn | anyone know how to trigger GMR when nova(-api) is running under uWSGI? Seems that uWSGI has its own interpretation of SIGUSR2 :/ | 01:37 |
|---|---|---|
| *** brinzhang has joined #openstack-nova | 01:37 | |
| *** brinzhang has quit IRC | 01:38 | |
| *** brinzhang has joined #openstack-nova | 01:39 | |
| *** mriedem has quit IRC | 02:00 | |
| *** tkajinam has quit IRC | 02:15 | |
| *** tkajinam has joined #openstack-nova | 02:19 | |
| *** tkajinam has quit IRC | 02:31 | |
| *** itlinux has joined #openstack-nova | 02:32 | |
| *** nicolasbock has quit IRC | 02:36 | |
| *** psachin has joined #openstack-nova | 03:08 | |
| *** cfriesen has quit IRC | 03:08 | |
| *** tbachman has quit IRC | 03:10 | |
| *** brinzhang has quit IRC | 03:18 | |
| *** brinzhang has joined #openstack-nova | 03:20 | |
| openstackgerrit | ya.wang proposed openstack/nova-specs master: Expose auto converge and post copy https://review.openstack.org/651681 | 03:26 |
| *** wwriverrat has joined #openstack-nova | 03:27 | |
| *** tbachman has joined #openstack-nova | 03:27 | |
| *** itlinux has quit IRC | 03:32 | |
| *** itlinux has joined #openstack-nova | 03:38 | |
| *** tkajinam has joined #openstack-nova | 03:45 | |
| *** lpetrut has joined #openstack-nova | 03:54 | |
| *** imacdonn has quit IRC | 04:07 | |
| *** imacdonn has joined #openstack-nova | 04:08 | |
| *** brinzh has joined #openstack-nova | 04:09 | |
| *** brinzhang has quit IRC | 04:12 | |
| *** lbragstad has quit IRC | 04:16 | |
| *** lpetrut has quit IRC | 04:17 | |
| *** itlinux has quit IRC | 04:30 | |
| *** slaweq has joined #openstack-nova | 04:45 | |
| *** slaweq has quit IRC | 04:49 | |
| *** ratailor has joined #openstack-nova | 05:01 | |
| *** d34dh0r53 has quit IRC | 05:02 | |
| *** dpawlik has joined #openstack-nova | 05:04 | |
| openstackgerrit | Merged openstack/nova master: Remove 'nova-manage cell' commands https://review.openstack.org/651294 | 05:12 |
| openstackgerrit | Merged openstack/nova master: Stop handling cells v1 for console authentication https://review.openstack.org/651295 | 05:12 |
| *** ivve has joined #openstack-nova | 05:43 | |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: ksa auth conf and client for cyborg access https://review.openstack.org/631242 | 05:45 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: WIP: Add Cyborg device profile groups to request spec. https://review.openstack.org/631243 | 05:45 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: WIP: Create and bind Cyborg ARQs. https://review.openstack.org/631244 | 05:45 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: WIP: Get resolved Cyborg ARQs and add PCI BDFs to VM's domain XML. https://review.openstack.org/631245 | 05:45 |
| *** slaweq has joined #openstack-nova | 05:56 | |
| openstackgerrit | Boxiang Zhu proposed openstack/nova master: Fix live migration break group policy simultaneously https://review.openstack.org/651969 | 05:58 |
| openstackgerrit | Takashi NATSUME proposed openstack/nova master: Fix cleaning up console tokens https://review.openstack.org/637716 | 06:04 |
| *** lpetrut has joined #openstack-nova | 06:13 | |
| *** lpetrut has quit IRC | 06:14 | |
| *** lpetrut has joined #openstack-nova | 06:15 | |
| *** Luzi has joined #openstack-nova | 06:23 | |
| *** lpetrut has quit IRC | 06:30 | |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: ksa auth conf and client for cyborg access https://review.openstack.org/631242 | 06:38 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: WIP: Add Cyborg device profile groups to request spec. https://review.openstack.org/631243 | 06:38 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: WIP: Create and bind Cyborg ARQs. https://review.openstack.org/631244 | 06:38 |
| openstackgerrit | Sundar Nadathur proposed openstack/nova master: WIP: Get resolved Cyborg ARQs and add PCI BDFs to VM's domain XML. https://review.openstack.org/631245 | 06:38 |
| *** awalende has joined #openstack-nova | 07:10 | |
| *** ianw is now known as ianw_pto | 07:15 | |
| *** tesseract has joined #openstack-nova | 07:16 | |
| *** slaweq has quit IRC | 07:16 | |
| *** rpittau|afk is now known as rpittau | 07:17 | |
| *** lpetrut has joined #openstack-nova | 07:20 | |
| *** slaweq has joined #openstack-nova | 07:28 | |
| *** luksky has joined #openstack-nova | 07:28 | |
| openstackgerrit | Boxiang Zhu proposed openstack/nova master: Add host and hypervisor_hostname flag to create server https://review.openstack.org/645520 | 07:31 |
| *** pcaruana has joined #openstack-nova | 07:32 | |
| *** helenafm has joined #openstack-nova | 07:34 | |
| *** tosky has joined #openstack-nova | 07:42 | |
| *** tssurya has joined #openstack-nova | 07:47 | |
| openstackgerrit | Hamdy Khader proposed openstack/nova master: Do not perform port update in case of baremetal instance. https://review.openstack.org/649345 | 08:01 |
| *** awalende has quit IRC | 08:13 | |
| *** awalende has joined #openstack-nova | 08:13 | |
| openstackgerrit | Takashi NATSUME proposed openstack/python-novaclient master: Fix a description for config_drive parameter https://review.openstack.org/653683 | 08:15 |
| *** ralonsoh has joined #openstack-nova | 08:16 | |
| *** takashin has left #openstack-nova | 08:17 | |
| *** dtantsur|afk is now known as dtantsur | 08:25 | |
| *** dpawlik has quit IRC | 08:27 | |
| *** dpawlik has joined #openstack-nova | 08:27 | |
| *** awalende has quit IRC | 08:29 | |
| *** awalende has joined #openstack-nova | 08:30 | |
| *** tkajinam has quit IRC | 08:32 | |
| *** ttsiouts has joined #openstack-nova | 08:45 | |
| *** luksky has quit IRC | 08:59 | |
| *** mkarpiarz has joined #openstack-nova | 09:01 | |
| openstackgerrit | Surya Seetharaman proposed openstack/nova master: [WIP] Support adding the reason behind a server lock https://review.openstack.org/648662 | 09:04 |
| openstackgerrit | Surya Seetharaman proposed openstack/nova master: Plumbing for locking an instance with reason https://review.openstack.org/653691 | 09:04 |
| *** tssurya has quit IRC | 09:05 | |
| *** tssurya has joined #openstack-nova | 09:05 | |
| *** lpetrut has quit IRC | 09:10 | |
| *** markvoelker has joined #openstack-nova | 09:11 | |
| openstackgerrit | Boxiang Zhu proposed openstack/nova master: Make evacuation respects anti-affinity rule https://review.openstack.org/649963 | 09:14 |
| *** plestang has joined #openstack-nova | 09:15 | |
| openstackgerrit | Boxiang Zhu proposed openstack/nova master: Fix live migration break group policy simultaneously https://review.openstack.org/651969 | 09:16 |
| plestang | Hi all! | 09:19 |
| plestang | I have a question regarding nova-conductor | 09:19 |
| plestang | regurlarly compute hosts are requesting for unconfirmed migration by dest compute | 09:20 |
| *** alex_xu has quit IRC | 09:20 | |
| plestang | The function called is here: https://github.com/openstack/nova/blob/03322bb517925a9f5a04ebdb41c3fd31e7962440/nova/db/sqlalchemy/api.py#L4313 | 09:21 |
| plestang | the read_deleted params is set to yes | 09:21 |
| plestang | in model_query | 09:21 |
| plestang | it generates some load on our infra | 09:21 |
| plestang | because we have around 300000 lines in that table | 09:22 |
| plestang | so all compute hosts of our infra reads regularly all the database | 09:22 |
| plestang | when I explain the request | 09:24 |
| plestang | +------+---------------+------------+--------+-----------------+--------+-----------+--------+--------+-------------+ | 09:25 |
| plestang | | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | | 09:25 |
| plestang | |------+---------------+------------+--------+-----------------+--------+-----------+--------+--------+-------------| | 09:25 |
| plestang | | 1 | SIMPLE | migrations | ALL | <null> | <null> | <null> | <null> | 261177 | Using where | | 09:25 |
| plestang | +------+---------------+------------+--------+-----------------+--------+-----------+--------+--------+-------------+ | 09:25 |
| *** boxiang has quit IRC | 09:25 | |
| plestang | I was asking if it were a good idea to set the read_deleted to no instead of yes | 09:25 |
| *** boxiang has joined #openstack-nova | 09:26 | |
| plestang | it would make the MariaDB query plan use one of the index that use the delete column | 09:26 |
| *** ratailor_ has joined #openstack-nova | 09:27 | |
| plestang | if I add "and deleted=0" the query plan becomes | 09:27 |
| plestang | +------+---------------+------------+--------+---------------------------------------------------------------------------------+-----------------------------------------+-----------+-------+--------+------------------------------------+ | 09:27 |
| plestang | | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | | 09:27 |
| plestang | |------+---------------+------------+--------+---------------------------------------------------------------------------------+-----------------------------------------+-----------+-------+--------+------------------------------------| | 09:27 |
| plestang | | 1 | SIMPLE | migrations | ref | migrations_by_host_nodes_and_status_idx,migrations_instance_uuid_and_status_idx | migrations_instance_uuid_and_status_idx | 5 | const | 23610 | Using index condition; Using where | | 09:28 |
| plestang | +------+---------------+------------+--------+---------------------------------------------------------------------------------+-----------------------------------------+-----------+-------+--------+------------------------------------+ | 09:28 |
| plestang | in other word the question is what is the idea behind requesting finished migration in deleted status for compute host | 09:28 |
| *** ratailor has quit IRC | 09:29 | |
| *** alex_xu has joined #openstack-nova | 09:31 | |
| *** luksky has joined #openstack-nova | 09:41 | |
| *** markvoelker has quit IRC | 09:41 | |
| *** ttsiouts has quit IRC | 09:51 | |
| *** ttsiouts has joined #openstack-nova | 09:53 | |
| *** lpetrut has joined #openstack-nova | 09:54 | |
| *** luksky has quit IRC | 09:57 | |
| *** brinzh has quit IRC | 10:07 | |
| *** ttsiouts has quit IRC | 10:09 | |
| *** ttsiouts has joined #openstack-nova | 10:10 | |
| *** Luzi has quit IRC | 10:28 | |
| *** ttx has quit IRC | 10:31 | |
| *** ttx has joined #openstack-nova | 10:31 | |
| *** bbowen has quit IRC | 10:33 | |
| aspiers | plestang: you might have more luck when the Americans come online | 10:35 |
| aspiers | kashyap: any thoughts on how to split the getDomainCapabilities() patch up? | 10:35 |
| kashyap | aspiers: Hiya, I want to spend some careful time on it | 10:35 |
| *** nicolasbock has joined #openstack-nova | 10:35 | |
| kashyap | aspiers: Right now, I'm chugging through a few things that I "need" to finish | 10:35 |
| aspiers | I guess I could manufacture something to test which isn't ever used in the real world | 10:36 |
| kashyap | aspiers: Rest assured, since I have a "vested interest" in it | 10:36 |
| aspiers | OK np | 10:36 |
| aspiers | Sure, I noticed ;-) | 10:36 |
| kashyap | Hehe | 10:36 |
| aspiers | In the mean time I guess I can rebase at least | 10:36 |
| kashyap | Let me quickly re-read it, actually | 10:36 |
| aspiers | Need to fix the merge conflicts | 10:36 |
| *** pcaruana has quit IRC | 10:36 | |
| *** markvoelker has joined #openstack-nova | 10:38 | |
| *** ratailor__ has joined #openstack-nova | 10:41 | |
| *** luksky has joined #openstack-nova | 10:42 | |
| *** ratailor_ has quit IRC | 10:44 | |
| *** tbachman has quit IRC | 10:47 | |
| openstackgerrit | Ivaylo Mitev proposed openstack/nova master: VMware: Attach volumes using adapter type from instance https://review.openstack.org/616599 | 10:47 |
| stephenfin | dansmith: When you're about, this is probably worth you looking at https://review.openstack.org/#/c/651296/ | 10:51 |
| *** pcaruana has joined #openstack-nova | 10:58 | |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: tests: autospecs all the mock.patch usages https://review.openstack.org/470775 | 11:00 |
| openstackgerrit | Stephen Finucane proposed openstack/nova master: hyper-v: autospec classes before they are instantiated https://review.openstack.org/342211 | 11:00 |
| *** erlon has joined #openstack-nova | 11:06 | |
| *** zigo has joined #openstack-nova | 11:07 | |
| *** cdent has joined #openstack-nova | 11:09 | |
| *** markvoelker has quit IRC | 11:11 | |
| *** slaweq is now known as slaweq|lunch | 11:15 | |
| kashyap | aspiers: Responded on the change. I can understand if my response is not fully satisfying... | 11:16 |
| * kashyap --> lunch | 11:16 | |
| aspiers | kashyap: thanks! | 11:17 |
| kashyap | First see if I make sense :-) Free to correct me if I didn't consider something else. | 11:17 |
| aspiers | sure | 11:19 |
| * aspiers gets lunch too | 11:19 | |
| *** eharney has quit IRC | 11:25 | |
| *** panda is now known as panda|lunch | 11:26 | |
| *** sapd1_x has joined #openstack-nova | 11:27 | |
| *** slaweq|lunch is now known as slaweq | 11:33 | |
| *** yedongcan has left #openstack-nova | 11:34 | |
| *** bbowen has joined #openstack-nova | 11:35 | |
| *** erlon has quit IRC | 11:37 | |
| openstackgerrit | Hamdy Khader proposed openstack/nova master: Do not perform port update in case of baremetal instance. https://review.openstack.org/649345 | 11:41 |
| *** ttsiouts has quit IRC | 11:59 | |
| plestang | aspiers: ok thx waiting a couple of hours | 12:05 |
| *** plestang has quit IRC | 12:06 | |
| *** plestang has joined #openstack-nova | 12:08 | |
| *** markvoelker has joined #openstack-nova | 12:08 | |
| *** ttsiouts has joined #openstack-nova | 12:09 | |
| *** ttsiouts has quit IRC | 12:12 | |
| *** ttsiouts_ has joined #openstack-nova | 12:12 | |
| openstackgerrit | Lee Yarwood proposed openstack/nova master: fixtures: Return a mocked class instead of method within fake_imagebackend https://review.openstack.org/619804 | 12:12 |
| *** cdent has quit IRC | 12:15 | |
| *** johnthetubaguy has joined #openstack-nova | 12:16 | |
| *** lbragstad has joined #openstack-nova | 12:18 | |
| *** tbachman has joined #openstack-nova | 12:33 | |
| *** ratailor__ has quit IRC | 12:38 | |
| *** lbragstad has quit IRC | 12:40 | |
| *** markvoelker has quit IRC | 12:41 | |
| openstackgerrit | Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA affinity for vGPUs https://review.openstack.org/650963 | 12:43 |
| bauzas | dansmith: efried: thanks for commenting the vGPU affinity spec, I made it way simplier ^ | 12:44 |
| bauzas | efried: about your comment on the new field name, I just wanted to make this field as arbitrary as possible, since other features could want to affinitize it too (think of... network ports :) heh gibi) | 12:45 |
| *** eharney has joined #openstack-nova | 12:49 | |
| *** tetsuro has quit IRC | 12:52 | |
| *** tiendc has quit IRC | 12:52 | |
| *** sapd1_x has quit IRC | 12:57 | |
| *** jdillaman has joined #openstack-nova | 13:00 | |
| efried | bauzas: But you're already calling it "devices". The part that makes it clearer is the "rp_uuids" bit. Otherwise the only thing you have to go on is the fact that it's a UUIDField. Are you saying it could include UUIDs *other* than RP UUIDs? How would the code know which is which?? | 13:02 |
| bauzas | ok, we can call it rp_uuids if so | 13:03 |
| bauzas | or related_rp_uuids | 13:03 |
| bauzas | FWIW, I'm very bad at naming things but my children | 13:03 |
| sean-k-mooney | bauzas: ya i think rp_uuids is good | 13:03 |
| sean-k-mooney | -1 to related_rp_uuids | 13:03 |
| sean-k-mooney | too much typeing | 13:03 |
| openstackgerrit | Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA affinity for vGPUs https://review.openstack.org/650963 | 13:05 |
| bauzas | sean-k-mooney: efried: my pleasure ^ | 13:05 |
| efried | bauzas: So now does it include the UUID of the NUMA cell RP? | 13:06 |
| sean-k-mooney | no | 13:06 |
| *** ttsiouts_ has quit IRC | 13:06 | |
| sean-k-mooney | maybe child_rps woould be better... | 13:07 |
| sean-k-mooney | actully it could | 13:07 |
| efried | Yeah, good idea, child_rp_uuids | 13:07 |
| sean-k-mooney | we coudl do it either way | 13:07 |
| sean-k-mooney | if it doen not include it we shoudl have a field for the numa node RP | 13:08 |
| efried | I don't love including the NUMA cell RP UUID, because how would you tell which one that is. But yes, this ^ | 13:08 |
| sean-k-mooney | but this spec does not depend on have numa nodes as RPs in placment | 13:08 |
| efried | then make the field nullable | 13:08 |
| efried | or set it to the compute RP UUID. | 13:09 |
| efried | um, not that second thing - because there can still be more than one, eh? | 13:09 |
| sean-k-mooney | so in this spec i think have it as just child_rp_uuids makes sense | 13:10 |
| sean-k-mooney | and if we also do the numa in placement spec add a rp_uuid filed for the numa node RP | 13:10 |
| *** pcaruana has quit IRC | 13:10 | |
| efried | So summarizing: | 13:11 |
| efried | - Add rp_uuid (the UUID of the NUMA cell) as a nullable UUIDField, only set if the NUMA cell is represented as a nested RP | 13:11 |
| efried | - Name the new ListOfUUIDField `child_rp_uuids` and it includes all & only UUIDs of child RPs like PGPUs, NICs, etc. | 13:11 |
| sean-k-mooney | +1 | 13:12 |
| sean-k-mooney | bauzas: what do you think ^ | 13:12 |
| *** ttsiouts has joined #openstack-nova | 13:13 | |
| * bauzas shrugs | 13:13 | |
| bauzas | efried: I don't want the vGPU affinity spec to tell about any NUMA node being a nested RP | 13:14 |
| bauzas | it's a different spec | 13:14 |
| bauzas | for the moment, pGPUs are a specific RP, sure, but NUMA nodes are just using the root RP | 13:14 |
| sean-k-mooney | bauzas: well you could leave adding the the nullable rp_uuid fiedl to the other spec | 13:15 |
| bauzas | sean-k-mooney: maybe, I'm not sure we need it | 13:15 |
| openstackgerrit | Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA affinity for vGPUs https://review.openstack.org/650963 | 13:16 |
| bauzas | bikeshed update ^ | 13:16 |
| sean-k-mooney | :) that looks fine too me | 13:17 |
| sean-k-mooney | the other thing i wanted to point out is if we did not have the numa-as-nested-rp spec then this is enought to do numa with placement in general | 13:17 |
| efried | mdbooth: https://bugs.launchpad.net/nova/+bug/1823251 <== have you had a chance to look into this? (weird db race brought up two nova meetings ago) | 13:18 |
| openstack | Launchpad bug 1823251 in OpenStack Compute (nova) "Spike in TestNovaMigrationsMySQL.test_walk_versions/test_innodb_tables failures since April 1 2019 on limestone-regionone" [High,Confirmed] | 13:18 |
| sean-k-mooney | take sriov as an example if we just model the pfs as RPs of the compute node and add the rps to the child_rp_uuids then it will work | 13:18 |
| sean-k-mooney | well we will need to do a few tweeks but the datamdoel will support it | 13:19 |
| sean-k-mooney | so if we dont make progress on the richer query syntax this cycle then we can atleast model the capasity with placement and use the numa toplogy filter to track the numa locality | 13:20 |
| efried | sean-k-mooney: Can you give me a rundown of the reviews you have open for CI-ish stuff? | 13:21 |
| efried | Is it just this one https://review.openstack.org/#/c/652197/ ? | 13:22 |
| sean-k-mooney | that is the main one | 13:22 |
| *** dpawlik has quit IRC | 13:22 | |
| efried | can I call on you in the nova meeting to give a brief summary of that effort? | 13:22 |
| sean-k-mooney | am sure | 13:23 |
| sean-k-mooney | i plan to allso add a tempest-dpdk job | 13:23 |
| sean-k-mooney | and i might work with the ovn folk to create a tempest-dpdk-ovn job after | 13:23 |
| sean-k-mooney | i have a dpdk job in my thirdparty ci just need to port it | 13:24 |
| *** mriedem has joined #openstack-nova | 13:24 | |
| efried | cool. You can say all of that again for the crowd :) | 13:24 |
| sean-k-mooney | hehe yes we have a topic at the ptg too | 13:24 |
| sean-k-mooney | there are related things to talk about but ill give a summary in the meeting | 13:24 |
| openstackgerrit | ya.wang proposed openstack/nova-specs master: Expose auto converge and post copy https://review.openstack.org/651681 | 13:25 |
| efried | mriedem: https://review.openstack.org/#/q/project:openstack/nova+branch:stable/pike+topic:bug/1669054 merged, are we ready to update the pike-em patches and make them go or are we waiting for other things? | 13:26 |
| *** mchlumsky has joined #openstack-nova | 13:26 | |
| *** awaugama has joined #openstack-nova | 13:27 | |
| efried | https://review.openstack.org/#/c/613263/ ? | 13:27 |
| mriedem | i personally don't think we need that change, it was only noticed on newer branches related to some other changes in the RT which aren't backported to queens, not sure why rado is backporting it to pike | 13:28 |
| mriedem | mel wants https://review.openstack.org/#/c/653514/ | 13:28 |
| mriedem | dansmith: this is quite old and we talked about this fix at the last ptg in denver - would be nice to flush it https://review.openstack.org/#/c/581912/ | 13:29 |
| mriedem | efried: so yeah there are still more changes we want in pike | 13:29 |
| mriedem | i'm working on it | 13:29 |
| mriedem | i might just start approving things | 13:30 |
| *** lbragstad has joined #openstack-nova | 13:30 | |
| efried | mriedem: ack; should we make a pike-em-potential etherpad or something, or is it okay for this to be all in your head? | 13:30 |
| efried | mmedvede: I've noticed http://ciwatch.mmedvede.net/project?project=nova&time=7+days is a little wonky lately, some rows seem to be duplicated, are you aware? | 13:31 |
| mriedem | efried: i can do that - one might already exist | 13:31 |
| efried | thanks | 13:32 |
| mriedem | elod: did you create a pike-em potential etherpad for each project? | 13:32 |
| mriedem | or one that was tracking all projects/ | 13:32 |
| mriedem | ? | 13:32 |
| mriedem | ah yes https://etherpad.openstack.org/p/pike-final-release-before-em | 13:32 |
| mriedem | https://etherpad.openstack.org/p/nova-stable-pike-em | 13:32 |
| *** pcaruana has joined #openstack-nova | 13:32 | |
| dansmith | mriedem: hmm, that im=None isn't used huh? | 13:34 |
| openstackgerrit | Ivaylo Mitev proposed openstack/nova master: VMware VMDK detach: get adapter type from instance VM https://review.openstack.org/653738 | 13:34 |
| mriedem | dansmith: been awhile but the logic i think is if we have the api db and get the not found, we should raise b/c that shouldn't happen. if we don't have the api db configured, we assume we're in the cell conductor and we don't need to target the context anyway. | 13:36 |
| mriedem | the latter is the devstack case, the former is like everyone else in real life right now | 13:37 |
| dansmith | mriedem: okay I'm not sure I follow that, but also not sure that's what is here | 13:37 |
| dansmith | not found does not raise | 13:37 |
| gibi | bauzas: I left a question about the GPU weigher in https://review.openstack.org/#/c/650963 | 13:37 |
| mriedem | sorry not the not found, the CantStartEngineError | 13:38 |
| *** markvoelker has joined #openstack-nova | 13:38 | |
| dansmith | mriedem: right, I get that logic, I'm just talking about the line you removed | 13:38 |
| mriedem | if we're in the cell conductor with no api db config, like devstack, reschedules will fail b/c of CantStartEngineError | 13:38 |
| mriedem | that's dead code | 13:38 |
| dansmith | mriedem: the im=None, but I don't know why that was there in the first place | 13:38 |
| mriedem | it's dead, my ide shows it as dead so i removed it most likely | 13:38 |
| dansmith | "my ide made me do it".. jesus, these kids. | 13:39 |
| *** jmlowe has quit IRC | 13:39 | |
| mriedem | "my text based terminal editor doesn't show me fun stuff like this" jesus these oldies | 13:40 |
| mriedem | <3 | 13:40 |
| dansmith | heh | 13:41 |
| bauzas | gibi: ack, will look | 13:42 |
| *** markvoelker has quit IRC | 13:42 | |
| *** lbragstad has quit IRC | 13:43 | |
| *** lbragstad has joined #openstack-nova | 13:46 | |
| gibi | mriedem, dansmith: about the https://review.openstack.org/#/c/652608/4/specs/train/approved/server-move-operations-with-ports-having-resource-request.rst@190 do you have a feeling which one is easier: 1) implement multiple portbinding usage for every server move operation 2) pass around the RequestSpec in the compute RPC API? | 13:51 |
| mriedem | i'm not sure i understand the question | 13:52 |
| mriedem | you need the request spec in methods like unshelve to do the port binding in the networking api methods properly right? | 13:52 |
| mriedem | oh, | 13:53 |
| mriedem | you mean change all move ops to do the port binding stuff that live migration does? | 13:53 |
| gibi | mriedem: cannot set up the portbinding in the conductor for unshelve? | 13:53 |
| mriedem | i'd think you'd still have behavioral changes in the compute if you did that | 13:54 |
| gibi | mriedem: yeah, do multiple portbinding in the conducotr for every move operation then the binding is created in the conductor | 13:54 |
| mriedem | it's really hard for me to say without it being poc'ed first | 13:54 |
| gibi | mriedem: true, we anyhow need a behavior change in the compute either due to the requestspec or due to the multiple portbinding | 13:54 |
| mriedem | for live migration we create the port bindings in the conductor but there were changes in the compute to use those port bindings if they existed | 13:54 |
| gibi | mriedem: yes | 13:54 |
| mriedem | changing the compute rpc api interface is much more straightforward to me | 13:55 |
| gibi | mriedem: OK that is the kind of input I'm looking for as for me both is blackbox now | 13:55 |
| gibi | mriedem: thanks | 13:55 |
| *** sapd1 has joined #openstack-nova | 13:56 | |
| mriedem | if you haven't heard, there is some weird issue sean-k-mooney is working on with the port binding live migratoin stuff too, so until the root cause of that is figured out i'd be nervous about switching everything over | 13:56 |
| gibi | mriedem: yeah I saw that weirdness too | 13:56 |
| *** takashin has joined #openstack-nova | 13:57 | |
| efried | Nova meeting real soon in #openstack-meeting | 13:58 |
| kashyap | (Sigh, conflicting call) | 13:59 |
| openstackgerrit | sean mooney proposed openstack/nova master: [WIP] Libvirt: add nfv job https://review.openstack.org/652197 | 14:00 |
| sean-k-mooney | i still have the other gate jobs disabled in ^ but if its clean ill uncomment them and drop the [WIP] | 14:00 |
| *** cfriesen has joined #openstack-nova | 14:01 | |
| sean-k-mooney | ... i have that emacs adds tabs... | 14:01 |
| efried | just reprogram it | 14:03 |
| efried | how's yer lisp? | 14:03 |
| openstackgerrit | sean mooney proposed openstack/nova master: [WIP] Libvirt: add nfv job https://review.openstack.org/652197 | 14:04 |
| mdbooth | efried: Sorry, I did not in the end. I had good intentions :/ | 14:10 |
| *** lpetrut has quit IRC | 14:10 | |
| *** cdent has joined #openstack-nova | 14:10 | |
| efried | mdbooth: Okay. Should I keep you associated with it on my radar or no? | 14:10 |
| mriedem | gibi: replied to the rest of your comments in your spec https://review.openstack.org/#/c/652608/ - question inline about why can't we heal the missing port allocatoins during the _heal_instance_info_cache periodic? | 14:11 |
| gibi | mriedem: ack | 14:11 |
| mdbooth | efried: Given how the next 2-3 weeks looks, it would probably be best not to. | 14:11 |
| efried | mdbooth: okay, thanks. | 14:12 |
| *** tinwood_ is now known as tinwood | 14:14 | |
| *** vishakha has joined #openstack-nova | 14:15 | |
| *** jaosorior has quit IRC | 14:15 | |
| mriedem | sean-k-mooney: can you split the 3rd party NFV / HPC / etc CI testing section out of https://etherpad.openstack.org/p/nova-ptg-train into another etherpad, because it's getting really big in the main one | 14:17 |
| mriedem | ~L99 | 14:17 |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova-specs master: Spec for API inconsistency cleanup https://review.openstack.org/603969 | 14:18 |
| sean-k-mooney | mriedem: yes ill do that and update it with a link | 14:19 |
| mriedem | thanks | 14:20 |
| *** awalende has quit IRC | 14:20 | |
| *** awalende has joined #openstack-nova | 14:21 | |
| *** awalende_ has joined #openstack-nova | 14:24 | |
| *** awalende has quit IRC | 14:25 | |
| *** markvoelker has joined #openstack-nova | 14:26 | |
| *** awalende_ has quit IRC | 14:29 | |
| *** samueldmq has joined #openstack-nova | 14:29 | |
| *** ricolin has quit IRC | 14:32 | |
| kashyap | mriedem: I was _just_ about to say that; to split out that giant CI JSON bits away from the main Etherpa | 14:32 |
| *** jmlowe has joined #openstack-nova | 14:34 | |
| *** mlavalle has joined #openstack-nova | 14:35 | |
| *** florius has joined #openstack-nova | 14:41 | |
| *** ttsiouts has quit IRC | 14:44 | |
| *** tbachman has quit IRC | 14:44 | |
| *** ttsiouts has joined #openstack-nova | 14:44 | |
| *** awalende has joined #openstack-nova | 14:48 | |
| kashyap | cfriesen: Heya, mind having a gander at this Secure Boot spec: https://review.openstack.org/#/c/506720 | 14:49 |
| openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Add missing libvirt exception during device detach https://review.openstack.org/651642 | 14:49 |
| kashyap | mriedem: Heh, I was referring to this (Hyper-V) commit of yours & Claudiu: http://git.openstack.org/cgit/openstack/nova/commit/?h=master&id=29dab997 | 14:50 |
| kashyap | The stuff I'm adding in the spec is similar, but for the open source hypervisor | 14:51 |
| mriedem | kashyap: don't confuse me as the author there, that was probably due to a bad rebase which changed the author | 14:52 |
| mriedem | i was likely just helping to clean up nits to get it approved | 14:52 |
| kashyap | Yeah, I know Claudiu was driving it | 14:52 |
| *** awalende has quit IRC | 14:52 | |
| mriedem | cdent: if you have hooks to rado, can you ask if we really need this in pike? https://review.openstack.org/#/c/613263/ | 14:54 |
| cdent | i can probalby find him, yeah | 14:54 |
| sean-k-mooney | mriedem: by the way for NewBruce RDO -> OSA bug. they tested my backported fix last night and it worked at least for the test instnace. | 14:55 |
| mriedem | sean-k-mooney: i need to read your commit message to figure out what the problem was | 14:56 |
| mriedem | or we don't know what the problem was, but this works around it | 14:56 |
| mriedem | i'm also doing about 10 other things atm | 14:56 |
| sean-k-mooney | so we know what the problem is and this works fixes it but i still dont know what teh cause is. im going to try and figure out a reporducer | 14:56 |
| elod | mriedem: only that have stable-policy-follows tag | 14:57 |
| cdent | mriedem: i've pinged him, but based on a cursory examination I think your analysis is correct. If we don't hear anything from him, probably safe to kill/ignore | 14:57 |
| sean-k-mooney | mriedem: no worries i just wanted to say im going to be away for a few days due to pulic holidays but ill try to get back to working on it before the ptg | 14:57 |
| mriedem | cdent: cool thanks | 14:58 |
| elod | mriedem: did i miss something? | 14:58 |
| mriedem | i'm glad you dropped the b rather than l in 'public' | 14:58 |
| mriedem | elod: no i'm just trying to organize the nova pike-em work | 14:58 |
| mriedem | using https://etherpad.openstack.org/p/nova-stable-pike-em | 14:58 |
| sean-k-mooney | :) yes so am i | 14:59 |
| elod | mriedem: ok, is see. actually the pads are quite out-of-date, maybe i should update them | 15:00 |
| gibi | mriedem: replied in https://review.openstack.org/#/c/652608/ but I have to disappear now | 15:00 |
| elod | mriedem: i see that you updated nova's etherpad already | 15:00 |
| *** gibi is now known as gibi_off | 15:01 | |
| *** takashin has left #openstack-nova | 15:01 | |
| *** ratailor has joined #openstack-nova | 15:01 | |
| *** _erlon_ has joined #openstack-nova | 15:02 | |
| mriedem | elod: yeah i'm working on onva's | 15:04 |
| mriedem | *nova's | 15:04 |
| mriedem | cdent: i left some more details about why maybe that patch would still be good for vcenter but i'm not sure - maybe only in the 1:M host:node case but i thought we stopped doing that with vcenter back in like kilo or liberty - long before you had to care about it :) | 15:08 |
| mriedem | tl;dr i think we can drop it | 15:08 |
| cdent | mriedem: in addition to all that, from a vio/vmware standpoint, pike doesn't really matter any more | 15:14 |
| mriedem | heh that was my other guess | 15:15 |
| *** florius has quit IRC | 15:16 | |
| *** cdent has quit IRC | 15:18 | |
| cfriesen | kashyap: it looks like centos 7.6 has modified the OVMF-20180508-3 rpm to no longer contain the file /usr/share/OVMF/OVMF_CODE.fd that nova looks for in nova/virt/libvirt/driver.py. Instead it now seems to be named /usr/share/OVMF/OVMF_CODE.secboot.fd | 15:25 |
| kashyap | cfriesen: I think it is following just RHEL. | 15:25 |
| kashyap | cfriesen: It's a good step: because it keeps things simpler | 15:25 |
| cfriesen | likely...but either way nova has an issue | 15:25 |
| kashyap | cfriesen: Because we hardcode the file | 15:26 |
| kashyap | I know | 15:26 |
| kashyap | That will go away. We will use the convenient formal interfaces provided by libvirt and QEMU | 15:26 |
| cfriesen | is anyone planning on making it a config option or something? | 15:26 |
| cfriesen | ah | 15:26 |
| kashyap | cfriesen: They've _vastly_ simplified it. | 15:26 |
| kashyap | It took more than one year (necessarily so) to get all the work done across EDK2/OVMF, QEMU, libvirt merged | 15:27 |
| kashyap | cfriesen: Since I've see you on #qemu, OFTC. I know you're comfortable with looking at some QEMU docs, let me point you to somethin | 15:27 |
| *** ttsiouts has quit IRC | 15:27 | |
| cfriesen | kashyap: you started this in 2017? yikes. :) | 15:28 |
| kashyap | cfriesen: The firmware.json file, and specifically read the "@Firmware:" bit: https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/firmware.json#l297 | 15:28 |
| kashyap | cfriesen: Yes! I've posted periodic updates. :-) Because work needs to be done in QEMU | 15:28 |
| kashyap | cfriesen: The main work started with this RFC I posted to 'qemu-devel': | 15:29 |
| *** ttsiouts has joined #openstack-nova | 15:29 | |
| kashyap | https://lists.nongnu.org/archive/html/qemu-devel/2018-03/msg01978.html | 15:29 |
| kashyap | "[RFC] Defining firmware (OVMF, et al) metadata format & file" | 15:29 |
| cfriesen | for some reason it's taking forever to open that link | 15:29 |
| kashyap | cfriesen: Which one? The git.qemu.org? Strange. Since you have the repo locally, look at it | 15:30 |
| openstackgerrit | Adam Spiers proposed openstack/nova-specs master: Re-approve AMD SEV support for Train https://review.openstack.org/641994 | 15:30 |
| kashyap | cfriesen: See the "Work Items" section in the spec. I've spent a lot of time tring to be as clear as I can | 15:30 |
| *** pcaruana has quit IRC | 15:31 | |
| kashyap | cfriesen: Note, I had to pause the spec for a year, because the main libvirt bits (firmware auto-selection) merged in 5.2, which released earlier this week :-) | 15:31 |
| mriedem | melwitt: your rocky/queens/pike backports for https://review.openstack.org/#/q/Iefab05e84ccc0bf8f15bdbbf515a290d282dbc5d are all failing unit tests for a real issue | 15:33 |
| openstackgerrit | Adam Spiers proposed openstack/nova-specs master: Re-approve AMD SEV support for Train https://review.openstack.org/641994 | 15:33 |
| melwitt | mriedem: yeah, I saw zuul -1s and concerned it's real but I haven't dug in yet | 15:34 |
| cfriesen | kashyap: just read the @Firmware section. that looks useful. do any distros support it yet? | 15:34 |
| kashyap | cfriesen: Very good question. | 15:35 |
| kashyap | cfriesen: The firmware.json file is supported by current QEMU versions. But, they went one step ahead, and also provided the firmware descriptor files | 15:35 |
| mriedem | bauzas: dansmith: can you hit these backports? https://review.openstack.org/#/q/topic:bug/1819963+(status:open+OR+status:merged)+branch:stable/queens | 15:36 |
| kashyap | cfriesen: That thing will be in QEMU 4.1 (July/August). Should be ready for Train | 15:36 |
| aspiers | efried: latest patch set of SEV spec is fully converted to the resource class approach https://review.openstack.org/#/c/641994/9 | 15:36 |
| bauzas | mriedem: on a meeting (again) but sure, will look | 15:36 |
| mriedem | lyarwood: melwitt: want to hit this backport? https://review.openstack.org/#/c/647630/ | 15:36 |
| openstackgerrit | Boxiang Zhu proposed openstack/nova master: Add host and hypervisor_hostname flag to create server https://review.openstack.org/645520 | 15:36 |
| efried | aspiers: Cool. Did you get feedback from other stakeholders on that approach before you did that? | 15:37 |
| *** helenafm has quit IRC | 15:37 | |
| kashyap | cfriesen: Look at this one, which has the documentation: https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg01558.html | 15:37 |
| melwitt | mriedem: queued | 15:37 |
| efried | aspiers: (once again, I'm not caught up) | 15:37 |
| kashyap | cfriesen: Those files will be part of QEMU 4.1, which will be shipped by distros Real Soon Now. | 15:37 |
| * kashyap bbiab; "meeting" | 15:37 | |
| aspiers | efried: Not yet, but I can't actually imagine how else we could solve the guest limit problem, so any other version of the spec proposal would be incomplete or dishonest right now | 15:37 |
| aspiers | efried: and there's always git if I need to revert bits ;-) | 15:38 |
| dansmith | mriedem: yeah | 15:38 |
| efried | aspiers: fair enough. | 15:38 |
| mriedem | dansmith: thanks | 15:38 |
| *** gyee has joined #openstack-nova | 15:38 | |
| aspiers | kashyap: finally reading your comments | 15:38 |
| mriedem | need a stable core on https://review.openstack.org/#/c/647913/ as well | 15:39 |
| mriedem | smcginnis: tonyb[m]: ^? | 15:39 |
| smcginnis | Looking | 15:40 |
| aspiers | kashyap: sounds reasonable, I'll take a stab at splitting up shortly | 15:41 |
| aspiers | going out for a run in the sun first though :) | 15:41 |
| kashyap | aspiers: Ah, good. I was briefly worrying if I missed to consider anything else | 15:41 |
| kashyap | aspiers: Go for it; more important. Damn screens can cait. | 15:41 |
| kashyap | s/cait/wait/ | 15:41 |
| aspiers | ;-) | 15:41 |
| efried | mdbooth, lyarwood: Thoughts on how long https://etherpad.openstack.org/p/ptg-train-xproj-nova-cinder should take? | 15:41 |
| efried | be conservative, please. | 15:41 |
| cfriesen | So as I mentioned to Kashyap, I think we've got an issue with UEFI boot on recent CentOS/RHEL. https://bugs.launchpad.net/nova/+bug/1825386 | 15:42 |
| openstack | Launchpad bug 1825386 in OpenStack Compute (nova) "nova is looking for OVMF file no longer provided by latest CentOS" [Undecided,New] | 15:42 |
| smcginnis | I think in the past we've always done half a day, but there's not as many in-flight nova-cinder things at the moment. | 15:43 |
| kashyap | cfriesen: An ugly workaround is to symlink the file name | 15:43 |
| cfriesen | kashyap: all sorts of possible workarounds, but I'm assuming we want nova to work out of the box. | 15:43 |
| mdbooth | efried: Depends. If it branches into a separate discussion of 'internal apis' it could take a long time. | 15:44 |
| efried | smcginnis: Half a day? I've remembered an hour or two over the past three PTGs or so, never half a day. In any case, a) there's one small-looking topic on that list, and b) very compressed time. | 15:44 |
| efried | mdbooth: See b) above. We've got to time box it. | 15:44 |
| efried | given that, what do you think, an hour? | 15:45 |
| mdbooth | efried: Purely api definition and discussion, 30-60 mins. | 15:45 |
| efried | okay, thanks. | 15:45 |
| aspiers | Yikes, SEV is the second largest nova spec to date | 15:45 |
| efried | aspiers: what's the largest? | 15:46 |
| aspiers | specs/newton/implemented/generic-resource-pools.rst | 15:46 |
| efried | phew. I thought it was going to be one of mine | 15:46 |
| aspiers | XD | 15:46 |
| elod | mriedem: meanwhile i've generated the unreleased Changes between 16.1.7 and 9191083, so i can paste it to etherpad if you need | 15:46 |
| efried | maybe would have been if dansmith hadn't red-penned it | 15:46 |
| *** luksky has quit IRC | 15:46 | |
| aspiers | Well surely SEV has to be up there in the red-pen stakes X-D | 15:47 |
| *** ivve has quit IRC | 15:48 | |
| smcginnis | efried: Maybe it just felt like half a day. :) | 15:48 |
| kashyap | cfriesen: Oh, yes! | 15:48 |
| kashyap | cfriesen: Please read the spec. All that hard-coding in Nova is fugly, and will go | 15:48 |
| cfriesen | kashyap: reading it now. I think we should fix (or at least bandaid) nova in the meantime. | 15:49 |
| cfriesen | kashyap: so is /usr/share/OVMF/OVMF_CODE.secboot.fd a superset of /usr/share/OVMF/OVMF_CODE.fd ? I haven't gone digging yet. | 15:50 |
| kashyap | cfriesen: I would not the word "superset", but they are two distinct things | 15:51 |
| kashyap | cfriesen: The binary: /usr/share/OVMF/OVMF_CODE.secboot.fd -- has Secure Boot + SMM built into it | 15:51 |
| *** plestang has quit IRC | 15:51 | |
| kashyap | cfriesen: While the "plain" /usr/share/OVMF/OVMF_CODE.secboot.fd -- does *not* have Secure Boot ability baked into it at buld time | 15:52 |
| kashyap | cfriesen: Can add a band-aid to look for this file, too. In addition to what Nova already looks | 15:52 |
| cfriesen | kashyap: I think we've also got to deal with https://bugs.launchpad.net/nova/+bug/1633447 and https://bugs.launchpad.net/nova/+bug/1785123 before secure boot is really useful, right? | 15:54 |
| openstack | Launchpad bug 1633447 in OpenStack Compute (nova) "nova stop/start or reboot --hard resets uefi nvram" [Undecided,In progress] - Assigned to Jack Ding (jackding) | 15:54 |
| openstack | Launchpad bug 1785123 in OpenStack Compute (nova) "UEFI NVRAM lost on cold migration or resize" [Low,In progress] - Assigned to Jack Ding (jackding) | 15:54 |
| kashyap | cfriesen: I've had a cursory look, but needs more concentration; for tomm / Tuesday (Mon is a holiday). | 15:55 |
| openstackgerrit | melanie witt proposed openstack/nova stable/rocky: libvirt: set device address tag only if setting disk unit https://review.openstack.org/653511 | 15:57 |
| cfriesen | I'm off most of next week, so don't expect quick response if you leave review comments. (I'm mostly taking over for jackding.) | 15:57 |
| kashyap | (Nod) | 15:58 |
| *** ttsiouts has quit IRC | 16:00 | |
| openstackgerrit | melanie witt proposed openstack/nova stable/queens: libvirt: set device address tag only if setting disk unit https://review.openstack.org/653512 | 16:04 |
| mriedem | efried: https://etherpad.openstack.org/p/nova-stable-pike-em is up to date | 16:04 |
| efried | thanks mriedem | 16:05 |
| *** ratailor has quit IRC | 16:05 | |
| mriedem | tl;dr novaclient is ready for final release, no open changes, | 16:05 |
| mriedem | os-vif has no open changes nor any changes since the last release, so it's ready for em | 16:05 |
| mriedem | nova has 6 pending | 16:06 |
| efried | tonyb[m]: ^ FYI | 16:09 |
| openstackgerrit | melanie witt proposed openstack/nova stable/pike: libvirt: set device address tag only if setting disk unit https://review.openstack.org/653514 | 16:09 |
| lyarwood | efried / mdbooth ; sorry was stuck on a call, I'd say 30mins to be conservative | 16:10 |
| *** tesseract has quit IRC | 16:10 | |
| efried | lyarwood: Cool, we've set it up for 1115-1150 | 16:10 |
| efried | if really needed we can come back after team picture and go til lunch | 16:11 |
| *** panda|lunch is now known as panda | 16:11 | |
| lyarwood | efried: ack thanks | 16:13 |
| *** tssurya has quit IRC | 16:14 | |
| *** cdent has joined #openstack-nova | 16:14 | |
| cfriesen | kashyap: what happens if you have running instances using /usr/share/OVMF/OVMF_CODE.fd, then you shut down the node, upgrade the OVMF RPM, and boot the node. Are the instances all toast? | 16:16 |
| kashyap | cfriesen: Have not tested it; but I'd expect some error. I don't think instance will be "toast". Because it's "only" the firmware. | 16:17 |
| cfriesen | but we wouldn't be able to boot it, as the xml would be specifying the "wrong" file | 16:18 |
| kashyap | cfriesen: Can you try on one instance, by doing the fugly workaround of: | 16:18 |
| kashyap | ln -sf /usr/share/OVMF/OVMF_CODE.secboot.fd /usr/share/OVMF/OVMF_CODE.fd | 16:18 |
| kashyap | Does it boot, if you do the above? | 16:18 |
| cfriesen | I don't have a suitable setup at the moment. | 16:18 |
| kashyap | cfriesen: But yes -- obviously, instance won't boot if the file is missing | 16:20 |
| *** wwriverrat has quit IRC | 16:20 | |
| cfriesen | I'm wondering why RHEL/Centos didn't include both OVMF_CODE.fd and OVMF_CODE.secboot.fd in the RPM | 16:20 |
| gmann | mriedem: fixed all formatting and scheduler_hints - https://review.openstack.org/#/c/603969/ | 16:20 |
| cfriesen | kashyap: oooh, interesting. the fedora package has both | 16:22 |
| kashyap | cfriesen: Yes | 16:22 |
| kashyap | cfriesen: This whole OVMF binary file names across distributions is a cluster fuck sized Jupiter | 16:22 |
| kashyap | cfriesen: But ... good news! | 16:22 |
| kashyap | cfriesen: That's why upstream QEMU we introduced a formal *schema* (the @Firmware thing you read) | 16:22 |
| kashyap | cfriesen: Because the firmware paths and names differ _across_ distros. E.g. see this on Ubuntu: https://packages.ubuntu.com/disco/all/ovmf/filelist | 16:23 |
| kashyap | cfriesen: Anyway, all of this is resolved now (and much more simpler) thanks to a lot of work in EDK2/OVMF, QEMU & libvirt. | 16:27 |
| kashyap | More details in a firefox tab (with the Secure Boot spec) near you :D | 16:27 |
| * kashyap --> AFK; my brain is fried | 16:28 | |
| cfriesen | yeah, it'll be better in another release cycle. | 16:28 |
| cfriesen | later | 16:28 |
| mriedem | gmann: comments inline :) but it's pretty good. | 16:28 |
| mriedem | gmann: i'll probably just +1 once you fix those since we're close to the ptg and i want to make sure other cores (and ops/users) are aware of what's being proposed here before we move forward | 16:29 |
| gmann | mriedem: sure, i will update | 16:29 |
| mriedem | i think the majority of the team needs to approve or at least be aware and not care since this is a pretty big change | 16:29 |
| gmann | make sense. | 16:29 |
| *** sapd1 has quit IRC | 16:31 | |
| *** rcernin has quit IRC | 16:32 | |
| openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Drop legacy-grenade-dsvm-neutron-multinode-live-migration from Pike https://review.openstack.org/653811 | 16:35 |
| mriedem | dansmith: melwitt: ^ spring cleaning | 16:35 |
| openstackgerrit | Ghanshyam Mann proposed openstack/nova-specs master: Spec for API inconsistency cleanup https://review.openstack.org/603969 | 16:38 |
| gmann | mriedem: ^^ done | 16:38 |
| melwitt | mriedem: curious how the job is broken if it's passing? | 16:41 |
| mriedem | it's not | 16:42 |
| mriedem | non-voting | 16:42 |
| mriedem | see https://review.openstack.org/#/c/640207/ | 16:42 |
| mriedem | if you really want to go mad, you can read my ramblings in https://review.openstack.org/#/c/640197/ trying to fix the job in queens | 16:42 |
| melwitt | oh, ok. I was confused by "removes the (broken) non-voting job" | 16:43 |
| mriedem | tl;dr one of the nodes is using nova-cpu.conf and one is using nova.conf and as a result, only one of them has the rbd creds which means the ceph stuff all fails during live migration | 16:44 |
| mriedem | i guess one way for me to deal with the busted job on queens is to just nix the rbd testing so we still have just block migration live migration | 16:44 |
| melwitt | ah ok | 16:44 |
| *** rcernin has joined #openstack-nova | 16:45 | |
| *** lbragstad has quit IRC | 16:47 | |
| *** lbragstad has joined #openstack-nova | 16:48 | |
| *** igordc has joined #openstack-nova | 16:49 | |
| *** igordc has quit IRC | 16:49 | |
| *** dtantsur is now known as dtantsur|afk | 16:50 | |
| *** lbragstad_ has joined #openstack-nova | 16:52 | |
| *** lbragstad has quit IRC | 16:56 | |
| *** lbragstad_ is now known as lbragstad | 16:56 | |
| *** tosky has quit IRC | 16:56 | |
| aspiers | sean-k-mooney: latest patch set of SEV spec is fully converted to the resource class approach https://review.openstack.org/#/c/641994/9 | 16:57 |
| aspiers | cdent / jaypipes might be interested too | 16:57 |
| cdent | thanks aspiers, putting it on the list | 17:01 |
| aspiers | cheers | 17:01 |
| *** pcaruana has joined #openstack-nova | 17:02 | |
| openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Fix legacy-grenade-dsvm-neutron-multinode-live-migration https://review.openstack.org/640197 | 17:02 |
| openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Move legacy-grenade-dsvm-neutron-multinode-live-migration in-tree https://review.openstack.org/640198 | 17:02 |
| *** jchhatbar has joined #openstack-nova | 17:03 | |
| sean-k-mooney | aspiers: loook like there is a pep8 issue jsut an fyi | 17:04 |
| aspiers | darn | 17:04 |
| aspiers | weird, can't see that locally | 17:05 |
| aspiers | oh, wrong environment | 17:05 |
| aspiers | I wonder why tox -e flake8 is allowed | 17:05 |
| *** lbragstad has quit IRC | 17:05 | |
| *** lbragstad has joined #openstack-nova | 17:06 | |
| openstackgerrit | Adam Spiers proposed openstack/nova-specs master: Re-approve AMD SEV support for Train https://review.openstack.org/641994 | 17:07 |
| aspiers | sean-k-mooney: fixed | 17:07 |
| *** jchhatbar has quit IRC | 17:08 | |
| *** lbragstad has quit IRC | 17:17 | |
| *** psachin has quit IRC | 17:27 | |
| cdent | aspiers: that's the just the unfortunate way tox works... | 17:32 |
| openstackgerrit | Merged openstack/nova master: libvirt: set device address tag only if setting disk unit https://review.openstack.org/611974 | 17:32 |
| *** mvkr has quit IRC | 17:33 | |
| *** ralonsoh has quit IRC | 17:43 | |
| *** rpittau is now known as rpittau|afk | 17:49 | |
| efried | aspiers: Re-reviewed SEV spec | 17:59 |
| aspiers | efried: thanks | 17:59 |
| efried | cdent: I tried to explain there ^ why we don't ever remove things from os-traits, even if they're trash. | 17:59 |
| efried | perhaps you can reinforce/augment | 18:00 |
| cdent | efried: looking | 18:00 |
| aspiers | efried, cdent: To "The pathological theoretical case is where somebody (not limited to nova) is on 0.11.0 or 0.12.0, sees the trait and uses it for $whatever", my question is: what could $whatever possibly be? Literally there is zero code which uses it. | 18:05 |
| efried | I'm basically saying it doesn't matter | 18:06 |
| aspiers | And even if they somehow concocted some way to use it, that couldn't possibly relate to SEV in any way, because again there is zero SEV code merged which uses it anywhere. | 18:06 |
| cdent | aspiers, efried : the additional aspect is that whenever a placement service sees a new version of os-traits it syncs up its database with the strings that are in the package, creating a row in the traits table, with an id that becomes a foreign key in other tables | 18:06 |
| cdent | s/becomes/can become/ | 18:06 |
| aspiers | Ahah | 18:06 |
| aspiers | Now that sounds like it could be a good reason | 18:06 |
| cdent | nothing is present is in placement to do a reverse sync | 18:06 |
| aspiers | Gotcha | 18:07 |
| aspiers | In any case, it's trivial to ditch the removal from the spec, and I'm happy to do that | 18:07 |
| aspiers | I just wanted to understand the rationale out of curiosity ;-) | 18:07 |
| cdent | that wasn't the reason why we can't remove, but once we decided we -weren't- going to remove, then it became safe for the sync mechanism to be that | 18:07 |
| openstackgerrit | melanie witt proposed openstack/nova master: Count instances from mappings and cores/ram from placement https://review.openstack.org/638073 | 18:07 |
| openstackgerrit | melanie witt proposed openstack/nova master: Set [quota]count_usage_from_placement = True in nova-next https://review.openstack.org/653146 | 18:07 |
| openstackgerrit | melanie witt proposed openstack/nova master: Use instance mappings to count server group members https://review.openstack.org/638324 | 18:07 |
| aspiers | Yep that makes sense | 18:07 |
| cdent | but the general ideas was simply: an extensible only enumeration is easier to manage than one than can be shrunk | 18:08 |
| aspiers | Sure | 18:08 |
| aspiers | OK, so it stays | 18:08 |
| aspiers | In that case I'll just need to amend the docs to say not to use it for anything | 18:08 |
| cdent | yeah, that's probably a good idea | 18:08 |
| efried | Yeah, I kept trying to phrase that in terms of this specific trait, where it doesn't necessarily apply. That wasn't the most convincing approach. | 18:09 |
| efried | thanks for the save cdent | 18:09 |
| efried | :* | 18:09 |
| cdent | :hugs: | 18:09 |
| cdent | It does suggest that we probably need some kind of "are you really really sure" mechanism when we start adding traits | 18:09 |
| sean-k-mooney | i am trying to think is there still a usecase for the trait but with the resouce class approch not really | 18:10 |
| cdent | when these went by I don't remember them seeming bad or suspect in any way | 18:10 |
| cdent | so it _might_ be that they are still okay in general, just not for this use | 18:10 |
| sean-k-mooney | the only one i have is a forbiden trait | 18:10 |
| aspiers | efried: Your idea of combining the resources: extra spec with an AMD trait is a nice idea. We're into bikeshedding territory now which is probably not ideal when formulating specs, but it is *conceivable* (if not likely) that in the future AMD might release another memory encryption technology - I dunno, maybe SEV2 or something | 18:10 |
| sean-k-mooney | e.g. i have only a few host that support SEV so please avoaid them | 18:10 |
| aspiers | In that case, not having an SEV-specific resource class would be problematic | 18:10 |
| aspiers | sean-k-mooney: that's an interesting idea. Maybe could be done with anti-affinity scheduler somehow? | 18:11 |
| efried | aspiers: Well now, this could be an argument for use of the trait :) | 18:11 |
| efried | in the future | 18:11 |
| aspiers | ... based on the premise that you can do anti-affinity for traits but not resources? | 18:12 |
| sean-k-mooney | aspiers: well if we report both the inventory of the sev resouce class + add the sev trait to the RP | 18:12 |
| *** vishakha has quit IRC | 18:12 | |
| sean-k-mooney | then operators can do it by just adding a forbidon trait to there non sev flavor | 18:12 |
| cdent | Having provided a tiny bit of useful information, I think I'm going to bow out. Since those of you who will be in denver, in denver. | 18:12 |
| * cdent waves | 18:12 | |
| openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Move legacy-grenade-dsvm-neutron-multinode-live-migration in-tree https://review.openstack.org/640207 | 18:12 |
| cdent | s/Since/See/ | 18:12 |
| aspiers | sean-k-mooney: I'm fine with that (the trait provision code is already written) | 18:12 |
| cdent | sigh | 18:12 |
| aspiers | cdent: looking forward to it! | 18:12 |
| * cdent waves again | 18:12 | |
| *** cdent has quit IRC | 18:12 | |
| sean-k-mooney | cdent: o/ | 18:12 |
| efried | I care that my memory encryption is done specifically with SEV2: resources:MEM_ENCRYPT_CONTEXT=1,trait:HW_CPU_AMD_SEV2=required | 18:12 |
| aspiers | efried: right, so we're back to traits then ;-) | 18:13 |
| aspiers | Playing devil's advocate, are there any downsides to sort of duplicating info between a resource class and a trait? | 18:13 |
| sean-k-mooney | please dont call it MEM_ENCRYPT_CONTEXT | 18:13 |
| efried | For now, since there's only one way to do it, we don't need to use the trait | 18:13 |
| aspiers | efried: OK, so we could just declare the trait as reserved for potential future use? | 18:14 |
| efried | just so. | 18:14 |
| sean-k-mooney | actully i was going to say that was confusing with intels SGX | 18:14 |
| sean-k-mooney | but SGX does not encrypt | 18:14 |
| efried | aspiers: As for the duplication question: IMO it would be nice to strive to not duplicate anything ever. | 18:14 |
| aspiers | sean-k-mooney: right, Intel has MKTME instead | 18:15 |
| sean-k-mooney | ya | 18:15 |
| aspiers | efried: +1 ;-) | 18:15 |
| sean-k-mooney | ok im going to have dinner ill try and review the sepc again before i sign off for the long weekend | 18:16 |
| sean-k-mooney | aspiers: efried i take it taht we are close however on the spec? | 18:16 |
| aspiers | sean-k-mooney: thanks! | 18:16 |
| aspiers | it feels close to me but I'm usually over-optimistic | 18:16 |
| efried | aspiers: The inventory (resource class) is telling you how many of a thing your provider can give. The trait is telling you characteristics of the provider. I don't really see a difference between VCPU:1&HW_CPU_X86_AVX512F:required and MEM_ENC_CTX:1&HW_CPU_AMD_SEV:required | 18:16 |
| efried | aspiers: I feel we're close on the bits I understand, yes :) | 18:17 |
| aspiers | hehe | 18:17 |
| sean-k-mooney | efried: yes that is a fair comparison | 18:17 |
| aspiers | I see a big difference actually | 18:17 |
| sean-k-mooney | so we could have MEM_ENC_CTX:1&HW_CPU_INTEL_MKTME:required also | 18:17 |
| sean-k-mooney | maybe | 18:17 |
| efried | sean-k-mooney: exactly | 18:18 |
| efried | if you don't care which technology you use, omit the traits | 18:18 |
| efried | If you want to restrict to one (or more - I think we implemented traits=in:[list], didn't we?) use traits. | 18:18 |
| sean-k-mooney | aspiers: i forget does the guest need to do anything to use sev | 18:19 |
| sean-k-mooney | e.g. would an app in the guest care | 18:19 |
| aspiers | The difference is that the presence of HW_CPU_AMD_SEV implies MCM_ENC_CTX, whereas HW_CPU_X86_AVX512F doesn't imply VCPU:1 (because AFAIK you can't have a guest without a vcpu) | 18:19 |
| sean-k-mooney | or is it jsut something that the host/qemu need to care about | 18:19 |
| aspiers | sean-k-mooney: just the host I think, apart from UEFI boot | 18:20 |
| efried | aspiers: say wha? What sense would HW_*CPU*_X86_AVX512F make if you weren't using any CPUs? | 18:20 |
| *** jmlowe has quit IRC | 18:20 | |
| aspiers | efried: I didn't explain it very well, but my point was that VCPU:1 is essentially a no-op | 18:20 |
| aspiers | s/1/2/ and my point is much clearer | 18:21 |
| efried | nope, sorry, not following you. | 18:21 |
| sean-k-mooney | i see you point but form a placement point of view a VCPU and SEV context are both jsut resouces | 18:21 |
| sean-k-mooney | it doesnt care | 18:21 |
| sean-k-mooney | and traits are jsut strings | 18:21 |
| aspiers | sure, but efried was saying we should avoid duplication | 18:21 |
| aspiers | HW_CPU_AMD_SEV implies MEM_ENC_CTX:1 therefore there is duplication | 18:22 |
| *** awalende has joined #openstack-nova | 18:22 | |
| aspiers | whereas with VCPU:2&HW_CPU_X86_AVX512F there is none | 18:22 |
| aspiers | both constraints are needed in the latter, but not in the former | 18:22 |
| efried | I've said I want two VCPUs. They have to support x86 AVX 512F. If I just say "I want x86 AVX 512F", you still don't know how many VCPUs I want. I could theoretically have made HW_CPU_X86_AVX512F a resource class so I could just say HW_CPU_X86_AVX512F=2 | 18:22 |
| efried | but then I would need a separate flavor for every possible flag | 18:22 |
| sean-k-mooney | we are ratholeing i think :) | 18:22 |
| mriedem | melwitt: heh you said the same as i did before i could post it https://review.openstack.org/#/c/653145/ | 18:23 |
| efried | and couldn't ever say "I'll accept any one of these variants" | 18:23 |
| efried | etc etc. | 18:23 |
| efried | That's why we have quantitative and qualitative separated. | 18:23 |
| aspiers | I think we're on the same page, but I was responding specifically to the example you were describing as equivalent | 18:23 |
| melwitt | mriedem: hah, nice | 18:23 |
| aspiers | I don't think that specific example exhibits equivalence | 18:24 |
| efried | There I go again using a poor specific example. | 18:24 |
| aspiers | but yeah if you made HW_CPU_X86_AVX512F a resource class that would be a totally different thing | 18:24 |
| aspiers | ;) | 18:24 |
| efried | I actually haven't a clue what AVX512F means. | 18:24 |
| aspiers | haha, nor me | 18:24 |
| efried | Or, for that matter, SEV | 18:24 |
| aspiers | I know it's a CPU flag though ;-) | 18:24 |
| efried | just that both are qualitative characteristics of a thing. | 18:24 |
| aspiers | anyway I have enough to go on for another patch set | 18:25 |
| efried | cool | 18:25 |
| aspiers | are you around much longer today? | 18:25 |
| aspiers | just wondering if it's worth trying to get it done shortly | 18:25 |
| efried | aspiers: was going to say, in further response to your "almost ready" question, that if we got an ack from danpb at this point, I would +2 with the discussed changes. | 18:25 |
| efried | I'm around for at least another 3.5h | 18:26 |
| aspiers | OK I'll try to ditch the trait removal then | 18:26 |
| *** awalende has quit IRC | 18:26 | |
| aspiers | which timezone is danpb? | 18:26 |
| efried | ...noting of course that I still definitely want someone like jaypipes to weigh in on the using-rc-vs-trait shift. | 18:26 |
| efried | no idea. | 18:26 |
| aspiers | oh yeah, me too :) | 18:27 |
| aspiers | don't know if he's around though | 18:27 |
| mriedem | UK | 18:27 |
| mriedem | london i think specifically | 18:27 |
| aspiers | no way! | 18:27 |
| aspiers | that's where I am | 18:27 |
| aspiers | had no idea | 18:27 |
| mriedem | he's your neighbor you weird hermit | 18:27 |
| aspiers | haha | 18:27 |
| mriedem | he's probably in your garden right now | 18:27 |
| * aspiers checks | 18:28 | |
| mriedem | by garden i mean "back yard" | 18:28 |
| aspiers | I have a garden | 18:28 |
| aspiers | communal, but I'm counting it | 18:28 |
| efried | anyway, aspiers, I'm not sure we're shooting to get this merged today, but couldn't hurt to have a ps without a blocking issue (os-traits reduction) in it for whenever those guys do get to looking. | 18:28 |
| aspiers | hrm, need to google a pic of him first | 18:28 |
| aspiers | efried: agreed | 18:28 |
| aspiers | I'll try to address shortly | 18:28 |
| efried | thanks for your patience aspiers | 18:28 |
| aspiers | efried: likewise!! | 18:29 |
| artom | We do beg your pardon, we are in your garden | 18:40 |
| aspiers | X-D | 18:47 |
| *** jmlowe has joined #openstack-nova | 18:49 | |
| *** jmlowe has quit IRC | 18:54 | |
| *** jangutter has joined #openstack-nova | 19:15 | |
| *** lbragstad has joined #openstack-nova | 19:24 | |
| openstackgerrit | Erik Olof Gunnar Andersson proposed openstack/nova master: [WIP] Validate that ironic_url works with regions https://review.openstack.org/653839 | 19:30 |
| *** lyarwood has quit IRC | 19:30 | |
| openstackgerrit | Merged openstack/nova master: Remove old-style cell v1 instance listing https://review.openstack.org/651296 | 19:39 |
| efried | mriedem: Since Spec: https://review.openstack.org/#/c/645458/ (Add host and hypervisor_hostname flag to create server) is merged/approved, can I strike it from the PTG agenda? | 19:41 |
| openstackgerrit | melanie witt proposed openstack/nova master: Add get_usages_counts_for_quota to SchedulerReportClient https://review.openstack.org/653145 | 19:44 |
| openstackgerrit | melanie witt proposed openstack/nova master: Count instances from mappings and cores/ram from placement https://review.openstack.org/638073 | 19:44 |
| openstackgerrit | melanie witt proposed openstack/nova master: Set [quota]count_usage_from_placement = True in nova-next https://review.openstack.org/653146 | 19:44 |
| openstackgerrit | melanie witt proposed openstack/nova master: Use instance mappings to count server group members https://review.openstack.org/638324 | 19:44 |
| openstackgerrit | melanie witt proposed openstack/nova master: Add documentation for counting quota usage from placement https://review.openstack.org/653845 | 19:44 |
| mriedem | efried: i think so | 19:45 |
| efried | thx | 19:45 |
| openstackgerrit | melanie witt proposed openstack/nova master: Add documentation for counting quota usage from placement https://review.openstack.org/653845 | 19:47 |
| openstackgerrit | melanie witt proposed openstack/nova master: Add documentation for counting quota usage from placement https://review.openstack.org/653845 | 19:48 |
| *** jangutter has quit IRC | 19:49 | |
| *** eharney has quit IRC | 19:55 | |
| *** boxiang has quit IRC | 20:02 | |
| *** jangutter has joined #openstack-nova | 20:04 | |
| *** jangutter has quit IRC | 20:09 | |
| *** bbowen has quit IRC | 20:15 | |
| openstackgerrit | Erik Olof Gunnar Andersson proposed openstack/nova master: [WIP] Validate that ironic_url works with regions https://review.openstack.org/653839 | 20:16 |
| *** tjgresha has joined #openstack-nova | 20:22 | |
| *** tjgresha has quit IRC | 20:26 | |
| openstackgerrit | Merged openstack/nova stable/queens: Add functional recreate test for bug 1819963 https://review.openstack.org/648414 | 20:41 |
| openstack | bug 1819963 in OpenStack Compute (nova) queens "Reverting a resize does not update the instance.availability_zone value to the source az" [Medium,In progress] https://launchpad.net/bugs/1819963 - Assigned to Matt Riedemann (mriedem) | 20:41 |
| openstackgerrit | sean mooney proposed openstack/nova master: [WIP] Libvirt: add nfv job https://review.openstack.org/652197 | 20:42 |
| *** pcaruana has quit IRC | 20:47 | |
| *** luksky has joined #openstack-nova | 20:51 | |
| *** awaugama has quit IRC | 20:55 | |
| *** efried has quit IRC | 20:55 | |
| *** efried has joined #openstack-nova | 20:56 | |
| efried | mriedem: re deprecating nova-console: I read http://lists.openstack.org/pipermail/openstack-dev/2018-October/135422.html as "no objections". Is there anything to be gained by discussing it at the PTG, someone who happens to be in the room voicing an objection? | 21:07 |
| *** tbachman has joined #openstack-nova | 21:08 | |
| efried | "...PTG, *beyond* someone who happens to be in the room..." | 21:09 |
| *** tjgresha has joined #openstack-nova | 21:12 | |
| sean-k-mooney | efried: maybe at the fourm | 21:13 |
| sean-k-mooney | get operators to weigh in | 21:13 |
| efried | It just seems pretty hit or miss to me. We ask the question and nobody responds, we're not really any better off than we were. Maybe the guy who cares just left the room, or isn't at the summit, or whatever. | 21:14 |
| efried | I would think the ML would be a better way to canvass the right cross-section of people. And that's been done. | 21:15 |
| *** tjgresha has quit IRC | 21:16 | |
| sean-k-mooney | well we can deprecated it in train and then the have until U to say "hay we use that" | 21:16 |
| efried | Then we deprecate it for a release or two (or six, viz. nova-network), giving people yet more time to make noise. | 21:16 |
| mriedem | efried: i agree that the ML is likely better than the PTG since i don't expect any xen/citrix people to be at the ptg | 21:16 |
| mriedem | Bob's reply in the ML wasn't exactly clear to me about there being a replacement people are using | 21:16 |
| mriedem | the service has already been deprecated technically | 21:16 |
| efried | mriedem: ack. I was focusing on the part where he said "yeah, deprecate" | 21:16 |
| efried | mriedem: okay. I'm going to put it at the bottom of the list, for like 4:55pm Saturday. | 21:17 |
| efried | do you want to fup on the ML? or want me to do so? Or leave it alone? | 21:17 |
| mriedem | deprecated as of stein https://review.openstack.org/#/c/610075/ - the bigger question for me was if we drop the service, the APIs have to also start returning a 401 | 21:17 |
| mriedem | *410 | 21:17 |
| efried | mm | 21:17 |
| mriedem | this is just like if we remove the nova-cells and nova-network services, the APIs that rely on those will just not work | 21:18 |
| mriedem | well, won't work in train - might work in stein | 21:18 |
| efried | right; which we're fine with | 21:18 |
| efried | But, are you considering taking this on in train? | 21:18 |
| efried | or hoodwinking stephenfin into doing so :P | 21:19 |
| sean-k-mooney | by the way i moved the ci stuff here https://etherpad.openstack.org/p/nova-ptg-train-ci but im not really sure what we want to get out of it | 21:19 |
| mriedem | efried: it's not really much to take on | 21:19 |
| efried | sean-k-mooney: Good, since you're here, that's a question I'm basically trying to ask everyone about their topics. | 21:19 |
| mriedem | rm -rf nova/console | 21:19 |
| efried | mriedem: death of a thousand cuts? | 21:19 |
| mriedem | this is definitely not a priority for me | 21:20 |
| efried | k. I'll fup on the ML like I did for the privsep topic, proposing to cut it from the agenda unless objections. | 21:20 |
| mriedem | i see the tc has a ptg item about "can we just start breaking stuff so people can get all the fancy new awesome cloud stuff" so we could just drop, say it's the tc's fault, and then move on | 21:21 |
| efried | perfect | 21:22 |
| sean-k-mooney | efried: can you get some of the intel folks to attend https://etherpad.openstack.org/p/nova-ptg-train-ci that will be setting up/runing the cis | 21:34 |
| efried | hrm, I'm actually not sure if our boots-on-the-ground CI folk are going to be attending. | 21:35 |
| efried | But I believe dtroyer is the, ahem, spokesperson for the effort. | 21:35 |
| *** mvkr has joined #openstack-nova | 21:35 | |
| sean-k-mooney | ok well 2 of the feature intel is pushing for this cycle would need 3rd part ci. | 21:37 |
| sean-k-mooney | persitent memeoy and rmd | 21:37 |
| efried | oh, yes, we are well aware. | 21:37 |
| aspiers | sean-k-mooney: do you have a suggestion for a resource class name instead of MEM_ENCRYPTED_CONTEXT? | 21:39 |
| efried | sean-k-mooney: I can see you're still working on that agenda; as you go along, if you could be thinking about what we hope to achieve in the room, that we actually need to all be in a room for, that would be neat. | 21:40 |
| sean-k-mooney | if we combine it with the trait i think it fine but i was also oke with SEV_CONTEXT | 21:40 |
| aspiers | efried: sean-k-mooney's earlier suggestion of trait:HW_CPU_AMD_SEV=forbidden as a valid use case has finally sunk in. It seems to me that operators could use this in flavors as soon as the SEV code merged, for keeping non-SEV guests off SEV machines. | 21:41 |
| sean-k-mooney | efried: well i would like mriedem input on that | 21:41 |
| aspiers | Of course this would mean providing the trait from day 0, but I'm tempted to think that it's already a compelling enough use case that maybe I should propose that in the spec | 21:42 |
| sean-k-mooney | this item basicaly came form the fact the nfv ci went way(on the nova side) and we got a bunch of new numa/hardware feature requests | 21:42 |
| efried | if it's important to keep SEV-capable machines free of non-SEV instances. Do we care? | 21:42 |
| aspiers | I would definitely expect some operators to want that, yes | 21:42 |
| sean-k-mooney | aspiers: some but not all | 21:42 |
| sean-k-mooney | ? | 21:42 |
| aspiers | Surely it would be likely that a compute plane would be mostly non-SEV hosts, with a few SEV hosts to cater for the more demanding customers | 21:42 |
| aspiers | sean-k-mooney: sorry, you lost me - not all what? | 21:43 |
| efried | Okay. Then cool, I have no problem reintroducing the trait for that purpose - and also the future purpose of being able to distinguish between different mem encryption technologies. | 21:43 |
| sean-k-mooney | aspiers: i think the quest efiried is asking is it required for it to work | 21:43 |
| efried | no, I was just asking whether it matters that we consume non-sev-context resources on a sev-capable machine | 21:44 |
| aspiers | It's probably not *required*, but the trait is already in os-traits and the code to provide it is already working, so ... :) | 21:44 |
| aspiers | efried: Yes, I think it would matter to many operators | 21:44 |
| efried | aspiers: Yes, and adding the trait at the same time as you add the context inventory is trivial, and enables this use case with no additional work. | 21:44 |
| aspiers | AFAIK SEV hardware is still niche (and maybe more expensive too, I dunno) | 21:44 |
| aspiers | efried: exactly | 21:44 |
| efried | other than that 2LOC in update_provider_tree, you get to write a paragraph in the docs. That's it. | 21:45 |
| aspiers | Right | 21:45 |
| aspiers | I'll mention the potential future use case too | 21:45 |
| efried | except... didn't we have a better way to turn on a "don't land here" by default? | 21:45 |
| efried | rather than having to put it in every non-SEV flavor? | 21:45 |
| aspiers | Probably not | 21:46 |
| efried | Forbidden aggregates... | 21:46 |
| aspiers | Oh | 21:46 |
| aspiers | And required traits would override that? | 21:46 |
| efried | https://review.openstack.org/#/c/609960/ | 21:46 |
| efried | it's... a little complicated. | 21:47 |
| aspiers | hah | 21:47 |
| aspiers | but similar looking | 21:47 |
| sean-k-mooney | efried: you mean the RP forbiden traits feature i suggested liek a year ago or soemthing else | 21:47 |
| sean-k-mooney | * RP required tratis | 21:47 |
| sean-k-mooney | wwell actuly it was both | 21:48 |
| efried | sean-k-mooney: Yes, exactly the same use case. | 21:48 |
| efried | it's just, you were the only person in the world who could get their mind around reverse-required traits. | 21:48 |
| sean-k-mooney | haha | 21:48 |
| efried | This solution isn't beautiful, but it's at least *slightly* less confusing to mere mortals. | 21:49 |
| sean-k-mooney | if only the term required traits was not already used | 21:49 |
| efried | aspiers: I would have to reread that spec to understand whether the SEV trait would be applicable, or whether it would have to be a different kind of trait or aggregate somethingsomething. | 21:50 |
| *** francoisp has quit IRC | 21:51 | |
| aspiers | Yeah | 21:51 |
| efried | ah, okay, yes | 21:51 |
| aspiers | Well I'll make the SEV spec raise the idea of using the trait sooner rather than later, but I'll leave it up for debate in subsequent reviews | 21:51 |
| efried | so aspiers it would actually want to work more like this: you would want a generalized trait - basically exactly matching the freaking resource class - for people to isolate all their mem-enc-capable systems for mem-enc-only VMs. | 21:52 |
| efried | or | 21:52 |
| efried | you could still have the traits be granular, and the operator would simply have to add all of them to the agg metadata. | 21:53 |
| efried | that would be fine too. | 21:53 |
| sean-k-mooney | or you could not do it in placement and just have a 4 like weigher | 21:53 |
| sean-k-mooney | *4 line | 21:53 |
| aspiers | maybe a topic for Denver? | 21:54 |
| efried | aspiers: I think it would be goodness for you to set the trait on sev-capable hosts, but not suggest any specific uses for it in the docs. | 21:54 |
| sean-k-mooney | it might be intersting to have a generalised weigher that operates on traits | 21:54 |
| aspiers | efried: OK, but the spec would still need to justify setting it | 21:54 |
| sean-k-mooney | efried: yep i think that is a good idea too | 21:55 |
| sean-k-mooney | aspiers: not really | 21:55 |
| efried | aspiers: In the spec, you can mention the two cases we've discussed here: 1) When more than one mem-enc technology is available, you can use it to get a specific one; and 2) it can be used with <reference forbidden aggs spec> to keep non-SEV guests clear of SEV-capable hosts. | 21:55 |
| aspiers | ack | 21:55 |
| efried | "...but those impls are outside the scope of this spec." | 21:55 |
| aspiers | +1 | 21:56 |
| sean-k-mooney | ya the ... out of scope is the imporant bit | 21:56 |
| efried | and \o/ the trait is no longer trash :) | 21:56 |
| sean-k-mooney | :) | 21:56 |
| aspiers | haha | 21:56 |
| aspiers | but this needs to be updated still https://docs.openstack.org/os-traits/latest/reference/index.html#amd-sev | 21:56 |
| aspiers | well, just the last sentence | 21:57 |
| aspiers | the rest is good I think | 21:57 |
| efried | hmph, that paragraph is a lie | 21:57 |
| aspiers | Instead it probably needs to caution *against* relying on just trait:HW_CPU_AMD_SEV=required | 21:57 |
| efried | implies that you can get SEV by specifying the trait. That's not true yet. | 21:57 |
| efried | so yeah, that doc should be updated regardless. Sooner rather than later, even. | 21:58 |
| sean-k-mooney | efried: or ever with out the resoruce request | 21:58 |
| aspiers | Good point. We originally expected it all to be merged within Stein :-( | 21:58 |
| efried | aspiers: Re Denver, if we can possibly get away with resolving this before we get there, I will be very happy. | 21:58 |
| aspiers | But yeah, I guess the last paragraph should have started out as a forward-looking statement | 21:59 |
| aspiers | and then been changed to present tense later, when it was all implemented | 21:59 |
| aspiers | Lesson learnt for next time | 21:59 |
| sean-k-mooney | efried: actully on the traits weigher thing. would it make sense to have a weigh that looked at teh traits on the selcect resouce providers and looked at the traits you requested and used that to calulate a weight for the host | 22:00 |
| sean-k-mooney | unrealted to SEV | 22:01 |
| efried | sean-k-mooney: The ol' "preferred traits" deal | 22:01 |
| sean-k-mooney | kind of but not quite | 22:01 |
| efried | It be like a "reverse preferred traits" deal | 22:01 |
| sean-k-mooney | perferred tratis worked by you saying i would like x | 22:01 |
| efried | right, you're saying "If I didn't ask for X, prefer hosts that *don't* have X" | 22:01 |
| sean-k-mooney | ya | 22:02 |
| efried | That would be a pretty cool weigher. Sounds like fun to write too. | 22:02 |
| sean-k-mooney | or rather prefer the host whos traits match the ones you asked for the closes | 22:02 |
| *** mchlumsky has quit IRC | 22:02 | |
| sean-k-mooney | i might hack on it before the ptg | 22:02 |
| sean-k-mooney | the premmis being host with less traits have less intersting stuff | 22:03 |
| sean-k-mooney | so prefer the boaring hosts | 22:03 |
| efried | it would also be nice to know which traits were more interesting than other traits. | 22:05 |
| efried | Like, I probably care way less about HW_CPU_X86_AVX512F than I do HW_AMD_SEV | 22:05 |
| sean-k-mooney | we can sprinkle in a little ML/AI it will be grand | 22:05 |
| sean-k-mooney | but yes | 22:05 |
| efried | edleafe would suggest using trait metadata on the placement side so we can rank the traits in priority order. | 22:05 |
| sean-k-mooney | if we had a histogram of how often traits exisit for a given resouce class | 22:06 |
| sean-k-mooney | we could use that as an input | 22:06 |
| edleafe | efried: I would?? | 22:06 |
| sean-k-mooney | edleafe: ofcouse efried just said so above :) | 22:06 |
| sean-k-mooney | it would be eaiser to do some of this on the placement side however | 22:07 |
| efried | oh, edleafe, is this *your* goat? | 22:07 |
| mriedem | oh nice a stack overflow in unit tests http://logs.openstack.org/45/649345/7/check/openstack-tox-py36/ba15c17/job-output.txt.gz#_2019-04-18_18_10_53_423952 | 22:07 |
| edleafe | Weighers in Placement - yay! | 22:07 |
| sean-k-mooney | mriedem: so there is definetly an infinity loop between _get and __getattr__ in tha tpatch | 22:09 |
| efried | but only in py36 | 22:09 |
| mriedem | sean-k-mooney: i've seen this TestRPC class intermittently failing unit tests all over the gate today | 22:09 |
| mriedem | it's not this patch | 22:09 |
| sean-k-mooney | with the same oslo config issue? | 22:10 |
| mriedem | maybe? | 22:10 |
| mriedem | http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22%7C%20Fatal%20Python%20error%3A%20Cannot%20recover%20from%20stack%20overflow.%5C%22%20AND%20tags%3A%5C%22console%5C%22&from=7d | 22:10 |
| mriedem | what did we merge on april 15? | 22:11 |
| sean-k-mooney | in oslo config. apparently droping python 35 testing | 22:12 |
| mriedem | ... | 22:12 |
| mriedem | why would that matter in a nova py36 job? | 22:12 |
| mriedem | especially if an oslo.config change is unreleased for us to use it | 22:13 |
| sean-k-mooney | i assume this is a version bump in upper constratins or a new release? | 22:13 |
| mriedem | https://github.com/openstack/requirements/commit/a96ee0e258aafb2880149b3e25dd5959f7b37c09 | 22:13 |
| efried | sean-k-mooney: are you at the PTG through Saturday? | 22:13 |
| sean-k-mooney | im flying there the friday before and leaving the Starday afternoon so yes | 22:14 |
| sean-k-mooney | mriedem: oslo.config 4.11.2 came out 2 days ago | 22:14 |
| efried | sean-k-mooney: I'm going to assert that the CI topic is one we don't need jaypipes for; and dtroyer is booked Th+Fr. So I'll set the CI topic for Saturday a.m., cool? | 22:15 |
| sean-k-mooney | oh never mind | 22:15 |
| sean-k-mooney | that is old | 22:15 |
| sean-k-mooney | efried: ya that sound fine | 22:15 |
| mriedem | we're using 6.8.1 from 2 months ago | 22:15 |
| mriedem | i also started seeing seg faults in pip 3.6 installs yesterday, so maybe something in py36 on bionic nodes since april 15 | 22:16 |
| mriedem | https://bugs.launchpad.net/nova/+bug/1825435 | 22:18 |
| openstack | Launchpad bug 1825435 in OpenStack Compute (nova) "TestRPC unit tests intermittently fail with "'>' not supported between instances of 'NoneType' and 'datetime.datetime'"" [Undecided,Confirmed] | 22:18 |
| aspiers | sean-k-mooney: I forgot to get your take on whether hugepages are still helpful for SEV, in terms of accounting | 22:19 |
| sean-k-mooney | am i think they are | 22:19 |
| aspiers | sean-k-mooney: I'm a little confused by recent discussions but I got the impression they can only be used for accounting guest RAM | 22:19 |
| sean-k-mooney | mainly because you still have to lock the memory | 22:19 |
| aspiers | and QEMU allocates a whole bunch of other stuff | 22:19 |
| sean-k-mooney | yes it does for mmio/dma | 22:20 |
| sean-k-mooney | with SEV instace there will be no oversubsription of memory | 22:20 |
| sean-k-mooney | that is also true of hugepages | 22:20 |
| aspiers | is it useful to only track part of what is allocated though? | 22:20 |
| sean-k-mooney | yes which will be most of it | 22:21 |
| sean-k-mooney | the qemu overhead is ment to be tracked using the resved meory config option | 22:21 |
| aspiers | Yeah, that's the bit which danpb is suggesting should have an rlimit at the top /machine.slice cgroup I think? | 22:22 |
| sean-k-mooney | or on a hugepage host its assumed you leave enough free non hugepage memeroy on the host for the os and any qemu memroy required outside of the guest ram | 22:22 |
| sean-k-mooney | ya | 22:22 |
| aspiers | i.e. reserving some memory for the host | 22:22 |
| *** awalende has joined #openstack-nova | 22:23 | |
| aspiers | I added some paras in the spec about this - please could you check them if you didn't already? | 22:23 |
| sean-k-mooney | so my suggetion is still use the locked element but dont set the hard_limit | 22:23 |
| aspiers | Yes, I already changed the spec to propose that | 22:23 |
| sean-k-mooney | and preferably use hugepages | 22:23 |
| aspiers | it pretty much says that too | 22:23 |
| aspiers | Most of my recent edits were just copying your advice ;) | 22:23 |
| sean-k-mooney | if you dont use hugepages we need to tell the operators to set the ram_allocatoin_raito to 1.0 | 22:23 |
| aspiers | but I'm not 100% sure I got it all accurate | 22:24 |
| sean-k-mooney | ill take a look at it before the ptg | 22:24 |
| aspiers | cool thanks | 22:24 |
| *** awalende has quit IRC | 22:27 | |
| mriedem | "'>' not supported between instances of 'NoneType' and 'datetime.datetime'" seems to be showing up in stephen's cells v1 removal series first...i'm not sure what could have introduced that | 22:27 |
| sean-k-mooney | did we merge any of that yet | 22:28 |
| mriedem | yes | 22:28 |
| sean-k-mooney | maybe the instance list change | 22:32 |
| sean-k-mooney | maybe not im wondering if we change how we are handeling the sorted list | 22:34 |
| sean-k-mooney | we used to call self._get_instances_by_filters and now we call instance_list.get_instance_objects_sorted | 22:35 |
| sean-k-mooney | acutly no _get_instances_by_filters just calls instance_list.get_instance_objects_sorted | 22:39 |
| *** _erlon_ has quit IRC | 22:40 | |
| sean-k-mooney | just skimmed through the few that have merged but nothing obvious jumped out at me | 22:46 |
| efried | sean-k-mooney: Are you particularly motivated to discuss provider yaml at the PTG? | 22:47 |
| sean-k-mooney | no | 22:47 |
| sean-k-mooney | i mean we can but i didnt think many people were interested | 22:48 |
| sean-k-mooney | and im not planning to work on it in train | 22:48 |
| efried | Right, lack of interest had put it way on the back burner for me | 22:48 |
| sean-k-mooney | ya same | 22:48 |
| efried | It's not something we can discuss without jaypipes, so putting it at the back of the agenda is kinda pointless. I'm just going to scrub it, k? | 22:48 |
| sean-k-mooney | sure | 22:49 |
| sean-k-mooney | i think we have more pressing things for Train | 22:49 |
| efried | right | 22:49 |
| *** tkajinam has joined #openstack-nova | 22:54 | |
| *** luksky has quit IRC | 22:59 | |
| sean-k-mooney | looking at the etherpads i dont really have much propsoed anymore | 23:00 |
| efried | sean-k-mooney: It's not a requirement for you to have stuff on there :) | 23:00 |
| sean-k-mooney | ya i know | 23:00 |
| efried | besides, I think the CI topic is plenty, don't you? | 23:00 |
| sean-k-mooney | well the ci topic was not originally my idea | 23:01 |
| sean-k-mooney | but i ment it more as what i will like be working in trains has shifited some what so i have not really need to propose much to discuss | 23:01 |
| *** whoami-rajat has quit IRC | 23:03 | |
| sean-k-mooney | thats actully a good thing as i need to still figure out what cyborg/plaement topics i shoudl attend | 23:03 |
| *** bbowen has joined #openstack-nova | 23:08 | |
| efried | sean-k-mooney: It's not a bad thing if the stuff you will be working on is well enough understood that we don't need PTG time for it. | 23:08 |
| efried | If we could do that for everything, we wouldn't need a PTG :) | 23:08 |
| efried | gotta run o/ | 23:08 |
| sean-k-mooney | o/ | 23:08 |
| *** igordc has joined #openstack-nova | 23:20 | |
| openstackgerrit | Adam Spiers proposed openstack/nova-specs master: Re-approve AMD SEV support for Train https://review.openstack.org/641994 | 23:20 |
| openstackgerrit | melanie witt proposed openstack/nova master: Create request spec, build request and mappings in one transaction https://review.openstack.org/586742 | 23:55 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!