| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-23 | |||
| 20:35:01 | mriedem | or not count toward quota? | |
| 20:35:19 | aspiers | efried, sean-k-mooney: can we quickly bikeshed the name for the resource class? e.g. MEM_ENC_CTX vs. MEMORY_ENCRYPTED_CONTEXT etc. Do we even need the _CONTEXT suffix? I can't see any precedent for it | |
| 20:35:59 | sean-k-mooney | i think we need the sufics otherwise its not a noun | |
| 20:36:17 | aspiers | it could be ENCRYPTED_MEMORY | |
| 20:36:18 | efried | aspiers: The suffix is traditionally units. A sev context thingy is kinda unitless, so not sure that applies. | |
| 20:36:48 | sean-k-mooney | thats still technically an ajitive | |
| 20:36:52 | efried | ENCRYPTED_MEMORY makes it sound like a trait. | |
| 20:36:59 | sean-k-mooney | yep | |
| 20:37:10 | aspiers | encrypted is an adjective, memory is a noun | |
| 20:37:22 | sean-k-mooney | not really | |
| 20:37:27 | aspiers | really ;-) | |
| 20:38:09 | aspiers | well, for sure memory is a noun | |
| 20:38:16 | aspiers | I think encrypted is a gerund or maybe a gerundive | |
| 20:38:30 | aspiers | and they function as an adjective at least | |
| 20:38:39 | sean-k-mooney | my other issue with encryped_memory is the units it impiles | |
| 20:38:52 | aspiers | agreed | |
| 20:39:01 | sean-k-mooney | we have memory_mb | |
| 20:39:15 | sean-k-mooney | i woudl expect encrpted_memory to also be in mb | |
| 20:39:28 | aspiers | yup, so that doesn't work | |
| 20:39:30 | sean-k-mooney | encrypted_memory_context | |
| 20:39:46 | sean-k-mooney | i woudl expect ot have idfferent units | |
| 20:40:12 | aspiers | memory_encrypted_guests? | |
| 20:40:27 | aspiers | the unit is one guest | |
| 20:40:32 | sean-k-mooney | no the units are stil wrong | |
| 20:41:10 | aspiers | wrong how? | |
| 20:41:12 | sean-k-mooney | if i have a multi numa node guest how many sev contextes do i need 1 or more then 1 | |
| 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 | sean-k-mooney | like an ipsec context | |
| 20:50:27 | aspiers | it would be good to find something which conveys the "1 per guest" notion | |
| 20:50:38 | aspiers | like _SLOTS | |
| 20:51:01 | sean-k-mooney | slot have a more generic meaning to me | |
| 20:51:01 | aspiers | not sure if slots has other meanings in nova already? | |
| 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 | |