| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-23 | |||
| 20:41:20 | aspiers | 1 | |
| 20:41:35 | aspiers | AFAIK | |
| 20:42:07 | sean-k-mooney | the bit that buggs me with memory_encrypted_guests is if we port the num_instance_filter to placement in the future | |
| 20:42:18 | sean-k-mooney | we could have an inventory of guests/isntance | |
| 20:42:23 | sean-k-mooney | ont he hypervior | |
| 20:42:59 | aspiers | why is that an issue/ | |
| 20:43:01 | sean-k-mooney | so it coudl be a bit strange to consome 1 allocation of memory_encrypted_guest and 1 allocation of insntace | |
| 20:43:50 | aspiers | doesn't seem particularly strange to me :) | |
| 20:44:13 | aspiers | they are different counts | |
| 20:44:15 | sean-k-mooney | why not just SEV_CONTEXT | |
| 20:44:35 | aspiers | because efried doesn't want a vendor-specific name | |
| 20:44:43 | sean-k-mooney | i had tought efried last stamet was to go with a speficig vendero one first | |
| 20:44:46 | aspiers | as discussed earlier | |
| 20:44:51 | aspiers | no, the opposite | |
| 20:44:55 | sean-k-mooney | efried: ? | |
| 20:45:02 | aspiers | I proposed SEV_CONTEXT and he argued for the opposite | |
| 20:45:09 | aspiers | you can see in the latest spec comments | |
| 20:45:28 | aspiers | https://review.opendev.org/#/c/641994/11/specs/train/approved/amd-sev-libvirt-support.rst@541 | |
| 20:45:35 | sean-k-mooney | we went back and fort on that a few times so i was nto sure what the latest was | |
| 20:46:12 | aspiers | there are pros and cons both ways | |
| 20:46:14 | aspiers | http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-04-23.log.html#t2019-04-23T18:03:32 | |
| 20:48:09 | sean-k-mooney | well unless its partiaclarly egregious im not going to -1 over the resocue class name | |
| 20:48:48 | aspiers | OK thanks but would still be nice to pick a good name ;-) | |
| 20:49:07 | aspiers | I was just wondering where the _CONTEXT idea came from | |
| 20:49:09 | sean-k-mooney | i take it you dislike the presence of context | |
| 20:49:16 | sean-k-mooney | proably me | |
| 20:49:25 | aspiers | only slightly, just feels a bit vague | |
| 20:49:47 | sean-k-mooney | well for me i thing of security context in many forms | |
| 20:49:51 | aspiers | but I haven't really come up with anything more precise except _GUEST | |
| 20:50:27 | aspiers | it would be good to find something which conveys the "1 per guest" notion | |
| 20:50:27 | sean-k-mooney | like an ipsec context | |
| 20:50:38 | aspiers | like _SLOTS | |
| 20:51:01 | aspiers | not sure if slots has other meanings in nova already? | |
| 20:51:01 | sean-k-mooney | slot have a more generic meaning to me | |
| 20:51:10 | sean-k-mooney | but kindof | |
| 20:51:23 | aspiers | well at least slots are clearly discrete integer values | |
| 20:51:40 | aspiers | context doesn't imply discrete or continuous or int or float etc. | |
| 20:51:52 | sean-k-mooney | you havent worked with enough hardware people | |
| 20:51:56 | aspiers | hahah | |
| 20:51:59 | aspiers | thankfully | |
| 20:52:41 | sean-k-mooney | you can make a nice logical assumtionlike slot can be subdevided an they will alwyas find a reason / way to make it happen | |
| 20:53:02 | aspiers | true | |
| 20:53:33 | sean-k-mooney | you can proable kick the precise name out of the sepc and leave it to the implemetnaiton | |
| 20:53:41 | aspiers | OK maybe let's wait for $0.02 from efried | |
| 20:53:45 | aspiers | yes good point | |
| 20:53:57 | aspiers | I'll stick with MEM_ENCRYPTED_CONTEXT for now | |
| 20:54:09 | aspiers | and I'm gonna check with AMD that it really is 1 per guest | |
| 20:54:24 | aspiers | https://www.redhat.com/archives/libvir-list/2019-January/msg00652.html is all I have to go on currently | |
| 21:01:12 | sean-k-mooney | aspiers: looking at the livirt schema | |
| 21:01:14 | sean-k-mooney | https://github.com/libvirt/libvirt/blob/545b0574fd27b56f243e21711935f99160cec214/docs/schemas/domaincommon.rng#L458-L490 | |
| 21:01:27 | sean-k-mooney | it only allows 1 launchSecurity element | |
| 21:02:22 | sean-k-mooney | so regarless of what amd requires libvirt can only enabel 1 | |
| 21:03:05 | aspiers | well, launchSecurity has a bunch of parameters | |
| 21:03:15 | sean-k-mooney | yes | |
| 21:03:18 | aspiers | and whatever hardware resource is being consumed by each guest could feasibly depend on other things | |
| 21:03:30 | aspiers | like it could be one per vcpu for example | |
| 21:03:32 | sean-k-mooney | but it can only exist once and non fo the sub element can be repeteded | |
| 21:03:43 | aspiers | then it wouldn't be dependent on this XML | |
| 21:03:51 | aspiers | or 1 per numa node | |
| 21:04:16 | aspiers | but I'm just sending an email to the AMD guys now to double-check | |
| 21:04:18 | sean-k-mooney | let me double check | |
| 21:04:21 | aspiers | so we should know for sure soon | |
| 21:04:30 | sean-k-mooney | cool | |
| 21:05:02 | aspiers | sent | |
| 21:05:20 | colby_ | mriedem: yea currently we use nova usage for billing purposes. I have gnocchi running and have not looked into if it excludes shelved instances or not from usage data | |
| 21:06:36 | sean-k-mooney | aspiers: i can only exist once in the domain https://github.com/libvirt/libvirt/blob/545b0574fd27b56f243e21711935f99160cec214/docs/schemas/domaincommon.rng#L81-L83 | |
| 21:07:54 | aspiers | sean-k-mooney: yeah, we already have code parsing that https://review.opendev.org/#/c/636318/3/nova/virt/libvirt/config.py | |
| 21:08:42 | aspiers | (which is unfinished BTW) | |
| 21:10:31 | efried | aspiers: I like MEM_ENCRYPTED_CONTEXT | |
| 21:10:51 | aspiers | efried: that's lucky, since I just did a search and replace to change everything to that ;-) | |
| 21:11:25 | efried | I agree with the gripe about _GUEST or _INSTANCE or similar. _SLOT seems too loaded with meaning, like I/O slot. | |
| 21:11:32 | aspiers | yeah fair | |
| 21:11:33 | efried | MEM_ENCRYPTION_CONTEXT would be better actually. | |
| 21:11:47 | efried | ION vs ED | |
| 21:12:01 | aspiers | oh yeah | |
| 21:12:22 | efried | otherwise it's the context that's mem-encrypted. | |
| 21:12:34 | efried | when really you want a mem encryption context | |
| 21:12:42 | efried | for your instance :) | |
| 21:12:52 | aspiers | right | |
| 21:14:17 | aspiers | efried: and the user-friendly extra spec / property name is gonna be what exactly? since we're bike-shedding :) | |
| 21:14:23 | aspiers | I'm adding that to the spec now | |
| 21:15:03 | sean-k-mooney | aspiers: hw:mem_encrypt=True | |
| 21:15:14 | sean-k-mooney | hw:mem_encrypt=sev | |
| 21:15:19 | aspiers | LOL | |
| 21:15:31 | efried | sean-k-mooney: Why the hw: prefix, out of curiosity? | |
| 21:15:33 | aspiers | well the whole point of this one is to be vendor-agnostic | |
| 21:15:54 | efried | otherwise, mem_encrypt=True is fine by me. (Is it True or true?) | |
| 21:15:59 | sean-k-mooney | because all standard flavor extraspecs are namespaced | |
| 21:16:03 | aspiers | especially since it will get mapped to resources:MEM_ENCRYPTION_CONTEXT=1 | |
| 21:16:44 | sean-k-mooney | efried:whatever the user provides we should lower case | |
| 21:17:06 | sean-k-mooney | and document "tRue" to mess with stephenfin | |
| 21:17:25 | efried | heh | |
| 21:18:07 | sean-k-mooney | im jsut catich up with the last few comment on the spec by they way | |
| 21:18:44 | efried | okay, if there's some good reason to have a prefix, and there's some good reason for that prefix to be hw:, then some variant of hw:mem_encrypt=$bool is fine with me. hw:mem_encryption would have a nice symmetry with the resource class name. | |
| 21:19:14 | sean-k-mooney | ya that would be good with me too | |
| 21:20:04 | aspiers | I like the consistency of the hw: prefix | |
| 21:20:13 | efried | btw, aspiers, can I strike this topic from the PTG agenda? | |
| 21:20:24 | efried | since it seems pretty much resolved? | |
| 21:20:35 | aspiers | efried: the spec topic? only if we get it merged before the PTG ;-) | |
| 21:20:48 | sean-k-mooney | :) | |