| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-23 | |||
| 13:11:11 | gibi | bauzas: we are struging here as we i) want a baby step but ii) doen't want to create a wrong precedence | |
| 13:11:15 | bauzas | ok, so they're conceptually different from nova | |
| 13:11:20 | gibi | precedent | |
| 13:11:26 | bauzas | gibi: agreed | |
| 13:11:37 | bauzas | gibi: that's why I dislike owner traits tbh | |
| 13:11:55 | bauzas | this looks to me an horrible hack for a single purpose | |
| 13:12:01 | sean-k-mooney | its not | |
| 13:12:23 | bauzas | sean-k-mooney: this is a hack, because this requires to touch the current modeling we have | |
| 13:12:24 | gibi | if we go with separate RC now, then we probably copy that for accelerator_direct + PCI in placement, and for disk_gb for cinder + nova too | |
| 13:12:37 | sean-k-mooney | i spent weeks tryign to come up with another way and that was the only way i coudl get jhone and other to consier moving ti forward | |
| 13:12:45 | bauzas | gibi: we can make a consensu | |
| 13:12:45 | gibi | and then I agree with sean that os-resource-classes has no use | |
| 13:13:00 | bauzas | gibi: or a statement if you prefer | |
| 13:13:08 | sean-k-mooney | bauzas: the current modeling does not fit our needs | |
| 13:13:30 | bauzas | gibi: if you have requirements for scheduling decisions that require your resources to be shared, you have to use other RCs | |
| 13:13:38 | bauzas | sharded* | |
| 13:13:45 | bauzas | and absolutely not shared | |
| 13:14:46 | bauzas | gibi: but if you are OK with having scheduling decisions that accept to mix your resources with other resources, then eventually the conductor (or the scheduling client rather) has to place the request to the right service | |
| 13:15:41 | sean-k-mooney | bauzas: we can supprot that but its a lot more work for the cyborg team | |
| 13:15:47 | gibi | bauzas: I think the scheduling decision can be made independently from the service providing the resources, the consumption of the resources on the hypervisor needs the information which service tracks the phyisical resource | |
| 13:15:49 | sean-k-mooney | are you willing to help them do that correctly | |
| 13:16:29 | bauzas | gibi: agreed with your statement, if you're talking about the "mixed case" | |
| 13:16:44 | bauzas | sean-k-mooney: for the cyborg team, they wanna do sharding | |
| 13:16:50 | gibi | bauzas: even in a not mixed case you have to claim the resource frome the service it is tracking it | |
| 13:17:10 | sean-k-mooney | bauzas: they only want to use the same resouce class because we told them to do that | |
| 13:17:19 | bauzas | gibi: the claim is the allocation | |
| 13:17:38 | sean-k-mooney | bauzas: we told them to do that to not add service specific standard resouce clases | |
| 13:18:43 | gibi | bauzas: nope, there is a claim in placement via the allocation, but you also need to talk to the service providint the resource to be able to use it (e.g. neutron to plug, cyborg to program and provide a pci address or mdev, cinder to provide the volume attachment information) | |
| 13:18:52 | bauzas | gibi: right | |
| 13:19:04 | bauzas | gibi: this is the conductor which would bind the arq | |
| 13:19:23 | bauzas | gibi: I mean, this is the conductor which would call cyborg-agent to bind the arq | |
| 13:19:23 | sean-k-mooney | bauzas: it can only do that if we have a device profile | |
| 13:19:38 | sean-k-mooney | if we do not we do not have the info requried to create and bind the arq | |
| 13:19:40 | bauzas | sean-k-mooney: correct, but we know the flavor | |
| 13:19:48 | bauzas | for the mixed case | |
| 13:20:07 | bauzas | say, we ask some flavor with a device profile that's turned into VGPUs | |
| 13:20:31 | bauzas | if this is acceptable to get a host not managed by cyborg, then the conductor won't call the agent to bind | |
| 13:20:50 | sean-k-mooney | that would be incorrct | |
| 13:21:00 | bauzas | but if the allocated host is cyborg-managed, then the conductor would have to call the agent | |
| 13:21:26 | sean-k-mooney | no that is not architeutaly valid | |
| 13:21:56 | sean-k-mooney | the device profile is not just a resouce calss. | |
| 13:22:12 | sean-k-mooney | its a resouce class, possibel soem traints and optionaly image to program | |
| 13:22:42 | sean-k-mooney | if the request comes form a device-porfile it __must__ be fulfiled form cyborg | |
| 13:22:49 | bauzas | you could end up with some non-cyborg managed host using the same RCs and traits, right? | |
| 13:23:13 | bauzas | sean-k-mooney: then, a device profile is ABSOLUTELY AND NECESSARLY a request to shard your cloud | |
| 13:23:14 | sean-k-mooney | today yes that is why ownwer traits were bting intoduced to make sure that will not happen | |
| 13:23:40 | bauzas | and for this, I think a different RC is the viable option | |
| 13:23:44 | gibi | hm | |
| 13:24:09 | gibi | if a device requested by a device profile is not just a pci resource but some extra capability (e.g. programming) | |
| 13:24:16 | gibi | then we should model that capability in placement | |
| 13:24:29 | gibi | and then the scheduling will be based on capability not based on ownership | |
| 13:25:02 | sean-k-mooney | that does not work for vgpus | |
| 13:25:04 | gibi | if a cyborg vgpu has same extra feature compared to nova vgpu then we shoud modell that | |
| 13:25:05 | sean-k-mooney | they are not programable | |
| 13:25:15 | sean-k-mooney | not in the way fpgas are | |
| 13:25:37 | sean-k-mooney | gpus are fixed function asics withthere own isntrcution set | |
| 13:25:50 | sean-k-mooney | they are just a co processor not a programble hardwarer device | |
| 13:25:51 | gibi | if the cyborg vgpu totally the same device as a nova vgpu then we should be able not to differentiate between them | |
| 13:26:13 | gibi | it is just a vgpu resource nothing more | |
| 13:26:13 | sean-k-mooney | gibi: they are litrally the same model of nvidia gpu | |
| 13:26:22 | gibi | regardless how you request it | |
| 13:26:36 | gibi | you as a user get the same vgpu in your vm | |
| 13:26:37 | bauzas | that's my point | |
| 13:27:17 | bauzas | if a device profile is a set of request groups, OK | |
| 13:27:17 | sean-k-mooney | that point is incompatbale with "use different RC to tack ownwership" they are identical form a user point of view so shoudl have the same resouce class | |
| 13:27:18 | gibi | so if two service represents non interchangeable resource then the difference in capability needs to be modelled in placement (as a trait) | |
| 13:27:54 | gibi | if the two service represents the interchangeable resource then we use the same RC and we forbid to deploy a mixed cloud | |
| 13:28:11 | gibi | as a mixed could would be undecideable | |
| 13:28:22 | bauzas | sean-k-mooney: in this case (the mixed one), this is absolutely OK to get allocation candidates from a device profile that AREN'T cyborg managed hosts | |
| 13:28:27 | sean-k-mooney | gibi: well you could use aggreate for that | |
| 13:28:36 | gibi | sean-k-mooney: yeah we can allow that | |
| 13:28:40 | gibi | maybe | |
| 13:29:23 | sean-k-mooney | bauzas: i dont agree | |
| 13:29:52 | sean-k-mooney | if that is the case then its absolutely ok to get allcoations form a pci passthough alias form cyborg | |
| 13:29:59 | sean-k-mooney | or to get mdevs from cyborg | |
| 13:30:07 | sean-k-mooney | when using generic mdevs | |
| 13:30:39 | bauzas | agreed, with VGPU standard request, you could end up getting a cyborg managed host | |
| 13:30:42 | sean-k-mooney | we can support that but if we do it has to be symetirc | |
| 13:30:45 | bauzas | and I'm OK with this | |
| 13:31:06 | bauzas | but you said it's more than a standard RC | |
| 13:31:24 | sean-k-mooney | lets take that case | |
| 13:31:32 | sean-k-mooney | you have resouce:vgpu1 | |
| 13:31:34 | bauzas | but as I said, I'm OK with getting results using an explicit request group that maps a device profile | |
| 13:31:42 | sean-k-mooney | its alocated form a cyborg RP | |
| 13:31:49 | sean-k-mooney | how do you boot that vm | |
| 13:32:23 | sean-k-mooney | bauzas: the device profile is in its own requet group by the way | |
| 13:32:24 | bauzas | the conductor which gets the candidates would see this is cyborg target and accordingly would ask the agent to bind the arq | |
| 13:32:32 | sean-k-mooney | bauzas: what arq | |
| 13:32:41 | sean-k-mooney | we just had resouces:vgpu | |
| 13:32:55 | sean-k-mooney | there is not arq or device type referenced in the flavor | |
| 13:33:02 | sean-k-mooney | *device-profile | |
| 13:33:17 | sean-k-mooney | and without a device-profile you cannot create an arq | |
| 13:34:01 | bauzas | so, again, that means we CAN'T be scheduler agnostic | |
| 13:34:23 | bauzas | in this case, you're asking for orange | |
| 13:34:29 | bauzas | and not appel | |
| 13:34:31 | bauzas | apple | |
| 13:34:45 | sean-k-mooney | but we agree that the device the guest sees is idential | |
| 13:34:53 | sean-k-mooney | so they are apples | |
| 13:35:13 | gibi | nova implementation needs a distintion but for the user the result is the same | |
| 13:35:14 | sean-k-mooney | they just have different requiremetn to consume them | |