| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-12 | |||
| 12:25:24 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: WIP: Include direct-physical in compute manager events check https://review.opendev.org/664431 | |
| 12:25:24 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: [DNM] testing bug/1813789 revert resize events https://review.opendev.org/664442 | |
| 12:29:01 | alex_xu | efried: sean-k-mooney bauzas do you have any idea how can I process when the user specify both the hw:pmem and resources extraspec https://review.opendev.org/#/c/601596/14/specs/train/approved/virtual-persistent-memory.rst@261 | |
| 12:29:28 | sean-k-mooney | im reading that spec at the moment | |
| 12:29:44 | alex_xu | I thought we should have similar problem when we have numa on placement. how to deal with hw:numa_* stuff and resources | |
| 12:30:33 | sean-k-mooney | well at present the resouces:* extra spec are merged with teh auto calluated set | |
| 12:31:08 | sean-k-mooney | so we caluate teh vcpu and ram form the flavor and then you can override that using resouces:MEMORY_MB=X | |
| 12:31:31 | sean-k-mooney | but ideally i think we would prefer people not to ues resouces: directly | |
| 12:32:07 | alex_xu | +1 on not use resources directly | |
| 12:32:32 | sean-k-mooney | if they use hw:pmem that give us the flexablity adapt to placment modeling changes without needing to modify flavors | |
| 12:33:15 | alex_xu | sean-k-mooney: the problem is we have instance.vpmems field, and we extra the vpmem from extra spec, and put them in instance.vpmems. if the user uses resources directly, then we should parse resources, and put them back to the instance.vpmems? | |
| 12:33:16 | sean-k-mooney | usign resouces:* directly works but its a leaky abstraction | |
| 12:33:35 | alex_xu | also agree with that | |
| 12:34:30 | alex_xu | I thought we will have same problem for instance.numa_topology. if the user use the resources directly, how can we parse the guest numa topo from resources extra spec, and put them back to isntance.numa_topology | |
| 12:35:00 | sean-k-mooney | well today we dont model numa in placmenet | |
| 12:35:20 | sean-k-mooney | if we did then it would be a proablem we would have to sovle yes | |
| 12:35:41 | alex_xu | it is a problem for pmem now :) | |
| 12:35:43 | sean-k-mooney | the hw:* extrapecs are the ahtoritive ones for how the guest is virtualised | |
| 12:36:07 | sean-k-mooney | the resouces:* are authritive for resouce usage | |
| 12:36:19 | sean-k-mooney | if there is a conflcit wew could rais an exception | |
| 12:36:37 | sean-k-mooney | i need to finish re reading the spec but are we adding a request prefilter for this | |
| 12:36:57 | sean-k-mooney | i.e. to convert form hw:pmem to the placement requests? | |
| 12:37:15 | alex_xu | do we need? or just parse the hw:pmem in the ResourceRequest.from_extra_specs ? | |
| 12:37:18 | sean-k-mooney | if so then i would have it validate them and raise an exception if there is a conflict | |
| 12:37:31 | aspiers | sean-k-mooney, alex_xu: I just did something very similar for SEV | |
| 12:37:40 | aspiers | https://review.opendev.org/#/c/664420/4 | |
| 12:37:49 | sean-k-mooney | alex_xu: am we could just parse it there yes | |
| 12:37:51 | alex_xu | aspiers: nice | |
| 12:38:04 | alex_xu | sean-k-mooney: yea | |
| 12:38:14 | sean-k-mooney | aspiers: your using a request prefilter | |
| 12:38:26 | aspiers | yes | |
| 12:39:16 | alex_xu | at least request prefilter is better than mixing everything ResourceRequest.from_extra_specs | |
| 12:39:54 | sean-k-mooney | right the ohter option is to do it here https://github.com/openstack/nova/blob/master/nova/scheduler/utils.py#L387 | |
| 12:40:08 | sean-k-mooney | and in resources_from_request_spec | |
| 12:40:19 | sean-k-mooney | but the prefilter i think are cleaner | |
| 12:40:33 | sean-k-mooney | both would work | |
| 12:40:40 | alex_xu | yes, agree | |
| 12:40:47 | alex_xu | we can add that for pmem | |
| 12:41:48 | sean-k-mooney | alex_xu: as aspiers has done you can do your validation like this https://review.opendev.org/#/c/664420/4/nova/scheduler/request_filter.py@197 | |
| 12:42:05 | sean-k-mooney | to ensure there is no conflict | |
| 12:42:27 | aspiers | right | |
| 12:42:29 | alex_xu | sean-k-mooney: then the instance is going to error status? | |
| 12:42:52 | sean-k-mooney | yes i think so | |
| 12:42:57 | alex_xu | I guess people hate the instance is going to error status.... | |
| 12:43:02 | sean-k-mooney | we will refuse to sechdule | |
| 12:43:34 | sean-k-mooney | well if we did not validate it would still go into error | |
| 12:43:41 | sean-k-mooney | but it woudl be a no valid host error | |
| 12:43:46 | alex_xu | we can validate that in the API layer | |
| 12:43:54 | sean-k-mooney | as teh livbrt driver would presuably fail to swapn it | |
| 12:44:01 | alex_xu | the request prefilter is only do the placement translation | |
| 12:44:23 | sean-k-mooney | where in the api laryer? | |
| 12:44:44 | sean-k-mooney | on flavor setting properties on teh flaovr or on instance spawn | |
| 12:45:07 | alex_xu | like somewhere we validate the hw:numa_* extra specs | |
| 12:45:14 | sean-k-mooney | we dont | |
| 12:45:27 | sean-k-mooney | well the first validation happens in the numa toplogy filter | |
| 12:46:07 | sean-k-mooney | but its not really validation we try to use the values to filter a host and that either work or it doesnt | |
| 12:46:34 | sean-k-mooney | so i think doing it in the prefilter which is even earlier in scheduling is fine | |
| 12:46:51 | alex_xu | wo do, let me find the link | |
| 12:47:28 | alex_xu | https://github.com/openstack/nova/blob/master/nova/compute/api.py#L659 | |
| 12:48:37 | sean-k-mooney | oh ok i really never knew that was there | |
| 12:48:47 | sean-k-mooney | in that case sure you can add the same validate for pmem | |
| 12:48:49 | alex_xu | so we can resolve the conflict of hw:pmem and resource:* somewhere like that | |
| 12:49:00 | alex_xu | \o/ finally find something sean-k-mooney doesn't know | |
| 12:49:58 | alex_xu | so I can override resources:* when hw:pmem present. | |
| 12:49:59 | sean-k-mooney | hehe :) there are plenty of things i dont know like how to use a mac without breaking it or how to spell litrally everything | |
| 12:50:06 | aspiers | XD | |
| 12:50:12 | alex_xu | hah | |
| 12:50:46 | aspiers | sean-k-mooney: maybe not, but I bet you can help me with this problem | |
| 12:50:53 | alex_xu | the last question is what should I do for the user only specify the resources:*. so I can prase the resources:* and put them into instance.vpmems. | |
| 12:50:55 | aspiers | https://review.opendev.org/#/c/644565/5/nova/virt/libvirt/driver.py@1625 | |
| 12:51:26 | aspiers | I need to change _sev_required() so that it checks the resource allocations for the instance (the MEMORY_ENCRYPTION_CONTEXT class) | |
| 12:51:53 | aspiers | but the callers don't have access to the resource allocations | |
| 12:51:58 | aspiers | AFAICS | |
| 12:51:58 | sean-k-mooney | alex_xu: i think we shoudl require uses to use hw:pmem personally as we might want to use the resouce class for something else in the future | |
| 12:52:23 | aspiers | they have access to the request context and the instance, but not the allocations | |
| 12:52:25 | sean-k-mooney | alex_xu: im thinking of the case where we might want to back guest ram by PMEM | |
| 12:52:34 | sean-k-mooney | e.g. as an alternive to hugepages | |
| 12:52:39 | sean-k-mooney | or file backed memeory | |
| 12:53:07 | sean-k-mooney | aspiers: looking | |
| 12:53:19 | alex_xu | good idea | |
| 12:53:34 | aspiers | I found _instance_to_allocations_dict() in scheduler/client/report.py which maybe could extract the allocations from the instance, but I don't know if that's right | |
| 12:53:47 | alex_xu | do you mean reject pmem resource class in extra spec resource:*? | |
| 12:53:55 | aspiers | also, nothing uses that method any more, since Iec02942d38 removed the last callers of it | |
| 12:54:46 | sean-k-mooney | alex_xu: we could but i was thinking just not populating the instance.vpmems from it | |
| 12:55:34 | alex_xu | that will do an allocation in the placement, but in the end, the instance won't attach the pmem | |
| 12:55:39 | sean-k-mooney | aspiers: do you need to cehck the resouce allocation or jsut the flavor | |
| 12:55:46 | aspiers | sean-k-mooney: the allocation | |
| 12:55:54 | aspiers | that's what efried said yesterday | |
| 12:56:37 | sean-k-mooney | im not sure why checking the request_sepc or flavor/image would not be enough | |
| 12:56:52 | aspiers | sean-k-mooney: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2019-06-11.log.html#t2019-06-11T16:49:51 | |
| 13:00:08 | aspiers | sean-k-mooney: but maybe when efried wrote that he didn't know that _sev_required() needs to be called from multiple locations in the driver code which don't have access to allocations | |
| 13:00:18 | aspiers | I guess I could set another instance variable | |
| 13:00:22 | sean-k-mooney | the instance contains the request_sepc and the request spec contains the request_resouces | |
| 13:00:29 | sean-k-mooney | https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L98 | |
| 13:01:04 | aspiers | but requested_resources is different from allocations, no? | |
| 13:01:12 | sean-k-mooney | it is | |
| 13:01:24 | sean-k-mooney | and it does not currenly hav the info you want see the comment above | |
| 13:01:43 | aspiers | right | |
| 13:01:48 | sean-k-mooney | im just wondering is that better to use in the future | |
| 13:01:51 | aspiers | in fact efried wants me to help fix that | |