| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-05 | |||
| 12:03:17 | sean-k-mooney | aspiers: for the fast fail on create server i think that is all you can do | |
| 12:03:27 | aspiers | hang on | |
| 12:03:31 | sean-k-mooney | then you can do the late check in the dirver | |
| 12:03:45 | aspiers | either we *require* hw_machine_type=q35 image property or we make it optional | |
| 12:03:49 | aspiers | which are you suggesting? | |
| 12:03:58 | aspiers | I mean in the SEV case | |
| 12:04:01 | sean-k-mooney | we will not require it | |
| 12:04:06 | sean-k-mooney | or should not | |
| 12:04:14 | aspiers | OK so then what's the point of an API check? | |
| 12:04:16 | sean-k-mooney | we can check if hw_machine_type is set | |
| 12:04:27 | sean-k-mooney | and if its not q35 reject | |
| 12:04:32 | aspiers | OK yeah | |
| 12:04:41 | aspiers | then if not set, it will fail later | |
| 12:04:46 | sean-k-mooney | but the api check was not for create it was for live migrate and suspend originaly | |
| 12:04:51 | aspiers | perhaps horribly on multiple compute hosts | |
| 12:04:51 | sean-k-mooney | yep | |
| 12:05:02 | aspiers | no live migrate/suspend is a different topic | |
| 12:05:09 | aspiers | that's not related to machine type | |
| 12:05:22 | aspiers | that relies on checking for hw_mem_encryption | |
| 12:05:30 | sean-k-mooney | we could maybe report machine types as traits in the future | |
| 12:05:36 | sean-k-mooney | but that is not ideal | |
| 12:05:37 | aspiers | that's this one https://review.opendev.org/#/c/680158/3 | |
| 12:05:47 | aspiers | kashyap: didn't we talk about that? | |
| 12:05:59 | aspiers | kashyap: about machine types as traits? | |
| 12:06:08 | aspiers | thought I vaguely remembered some discussion on that | |
| 12:06:10 | aspiers | maybe not | |
| 12:06:12 | sean-k-mooney | i think that is leaking too much info personally | |
| 12:06:33 | aspiers | I don't see a security risk but different rathole | |
| 12:06:43 | aspiers | maybe you're right but let's not go there now | |
| 12:06:44 | sean-k-mooney | no that is not what i ment | |
| 12:07:19 | sean-k-mooney | we could advertise that the host has q35 support | |
| 12:07:24 | aspiers | OK so to summarise, the plan is this: | |
| 12:07:37 | aspiers | hw_machine_type=q35 image prop is optional for SEV | |
| 12:07:57 | aspiers | we have an API check enforcing that if it's there, it has to be q35 family | |
| 12:08:19 | aspiers | but if it's not there then we just hope the scheduler picks a machine with nova.conf defaulting x86_64 to q35 | |
| 12:08:35 | aspiers | if it doesn't it will fail and try other compute hosts | |
| 12:08:44 | sean-k-mooney | and check it in the driver | |
| 12:08:46 | sean-k-mooney | but yes | |
| 12:08:57 | sean-k-mooney | it will fail and rescdule | |
| 12:09:18 | sean-k-mooney | and you can use host aggreates ectra if you want too to reduce the chance of that happening | |
| 12:09:32 | aspiers | so the operator should configure CONF.libvirt.machine_type to x86_64=q35 on all SEV hosts | |
| 12:09:35 | sean-k-mooney | if you dont want to set q35 in the image or the config | |
| 12:09:55 | sean-k-mooney | yes i think that is what we shoudl recommend | |
| 12:10:03 | aspiers | OK | |
| 12:10:05 | aspiers | BUT | |
| 12:10:15 | aspiers | does that fix the import cycle? | |
| 12:10:28 | aspiers | it means there are two types of q35 check | |
| 12:10:37 | aspiers | one image-only, and one including nova.conf | |
| 12:10:42 | sean-k-mooney | yes in hardware.py you dont need to import the utils funciton anymore | |
| 12:10:52 | sean-k-mooney | hardware.py just does the image check | |
| 12:11:11 | sean-k-mooney | and the driver just does the final machine type check using the image+config | |
| 12:11:38 | aspiers | I don't follow | |
| 12:11:40 | sean-k-mooney | so no import of libvirt.utils is need in hardware.py | |
| 12:11:53 | sean-k-mooney | ill comment on the patch | |
| 12:11:57 | aspiers | wait | |
| 12:12:05 | aspiers | which one of the two types of q35 check are you suggesting happens in hardware.py? | |
| 12:12:13 | aspiers | the API one or the driver one? | |
| 12:12:28 | aspiers | the driver one *does* need libvirt.utils | |
| 12:12:34 | aspiers | to read the config | |
| 12:12:58 | aspiers | sean-k-mooney: ^^ (in case you are already commenting on the patch) | |
| 12:13:13 | sean-k-mooney | the api one should happen in hardware.py and it should only check the image | |
| 12:13:26 | aspiers | OK so where does the driver one happen? | |
| 12:13:31 | aspiers | in driver.py? | |
| 12:13:37 | sean-k-mooney | yes in driver.py | |
| 12:13:47 | aspiers | hmm | |
| 12:14:18 | sean-k-mooney | it can call the hardware.py if it wans ill type up som sudo code. | |
| 12:14:33 | aspiers | yeah OK I think that might work | |
| 12:16:13 | aspiers | artom: I think sean-k-mooney's proposal should work ^^^ | |
| 12:16:22 | aspiers | kashyap too, in case you are interested | |
| 12:16:46 | aspiers | efried: you might just want to wait for the new patch sets rather than wade through this conversation ... | |
| 12:16:55 | aspiers | OK gotta go | |
| 12:17:06 | aspiers | lunch | |
| 12:18:04 | brinzhang | gmann: Would you prefer https://review.opendev.org/#/c/673133/15/nova/tests/unit/api/openstack/compute/test_volumes.py@1036 ? | |
| 12:18:41 | Sundar | sean-k-mooney: Re. "testing patch that runs the tempst job on nova", I believe that would be https://review.opendev.org/#/c/670999/ | |
| 12:18:53 | brinzhang | gmann: I think this test already test pre 2.78 microversion, and the 'delete_on_termination' field not in the response body. | |
| 12:19:02 | gmann | brinzhang: yeah that is good test and same we need for list and show API operation | |
| 12:19:27 | gmann | brinzhang: that is for POST and same we should test for other modified API also. | |
| 12:20:32 | brinzhang | gmann: got it, I will update it, beacause it will be conflict, https://review.opendev.org/#/c/621476/ this patch will be merged first | |
| 12:20:52 | brinzhang | gmann: no need a follow-up patch. | |
| 12:21:54 | gmann | brinzhang: ok but we cna check how matt prefer. it will be easy for him to re+2 if you only rebase on microverison and do other changes in followup. | |
| 12:22:17 | gmann | i am ok either way | |
| 12:22:37 | brinzhang | gmann: thanks. | |
| 12:24:41 | sean-k-mooney | aspiers: when you get back see if that makes sense. https://review.opendev.org/#/c/680065/6/nova/virt/hardware.py | |
| 12:27:47 | sean-k-mooney | Sundar: yes alther when i ran it 3 weeks ago it failed | |
| 12:27:52 | sean-k-mooney | ill recheck it | |
| 12:28:56 | sean-k-mooney | Sundar: actully that patch does not pull in the nova integration code unless the cyborge cod is | |
| 12:29:29 | sean-k-mooney | Sundar: so no that is propsoed agains nova but it does not run any of the nova cyborge integration code | |
| 12:29:52 | Sundar | sean-k-mooney: The dependencies need to be fixed there too. Will follow up. Thanks. | |
| 12:30:20 | sean-k-mooney | that should jsut be rebased on top of the final cyborg patch | |
| 12:31:36 | Sundar | Ok, I will ask thr author or do it myself | |
| 12:31:40 | Sundar | *the | |
| 12:32:00 | sean-k-mooney | i think we can do that in the gerrit ui | |
| 12:32:09 | sean-k-mooney | want me too try | |
| 12:32:43 | sean-k-mooney | this is the final patch in teh series right https://review.opendev.org/#/c/673735/ | |
| 12:33:33 | openstackgerrit | sean mooney proposed openstack/nova master: [WIP] add cyborg tempest job https://review.opendev.org/670999 | |
| 12:33:35 | Sundar | sean-k-mooney: Yes, 673735 | |
| 12:33:59 | sean-k-mooney | ok its rebased and i updated the topic | |
| 12:34:18 | Sundar | Thank you | |
| 12:34:39 | sean-k-mooney | and i kicked off an experimental build so we should get results in an hour or so | |
| 12:35:34 | Sundar | It will probably fail because the Cyborg code dependencies are not set yet? | |