| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-23 | |||
| 13:04:18 | sean-k-mooney | todate we dodn thave any service that share a common resouce class because we have not modeled ownwersyhip yet | |
| 13:04:39 | bauzas | sean-k-mooney: we don't need to model ownership for shared resources | |
| 13:04:43 | sean-k-mooney | stephenfin: it has some nice things yest like that swtich statement based on patern matchin | |
| 13:04:55 | sean-k-mooney | stephenfin: we should be able to bump our min python to 3.8 soon | |
| 13:04:56 | bauzas | if we have same resources, this is conceptually the same | |
| 13:05:10 | opendevreview | Rodolfo Alonso proposed openstack/os-vif master: Make explicit the network backend used in the CI jobs https://review.opendev.org/c/openstack/os-vif/+/797640 | |
| 13:05:18 | sean-k-mooney | stephenfin: im hoping that 3.8 bump happens next cycle | |
| 13:05:31 | bauzas | you're asking for apples, whether they are provided by a grocery or by something else | |
| 13:05:43 | sean-k-mooney | bauzas: what makes a cyborg vgpu different form a nova one | |
| 13:05:44 | opendevreview | Rodolfo Alonso proposed openstack/nova master: Make explicit the network backend used in the CI jobs https://review.opendev.org/c/openstack/nova/+/797641 | |
| 13:06:06 | sean-k-mooney | they are identical | |
| 13:06:10 | bauzas | sean-k-mooney: if you're asking for a resource that's not the same than an apple, this is not an apple | |
| 13:06:11 | sean-k-mooney | form a user persective | |
| 13:06:41 | bauzas | the user sees flavors | |
| 13:06:49 | sean-k-mooney | not in all cases | |
| 13:06:52 | bauzas | he doesn't see resources | |
| 13:07:02 | sean-k-mooney | the extra specs are not alwasy visable to users | |
| 13:07:13 | bauzas | I'm done with our "power users" | |
| 13:07:14 | sean-k-mooney | in fact they might not be visable by default that is contoled by policy | |
| 13:07:45 | bauzas | sean-k-mooney: but with cyborg, they don't see VGPUs when looking at the flavors, right? | |
| 13:08:02 | sean-k-mooney | both are stored in the flavor as an extra spec | |
| 13:08:04 | bauzas | they see device profiles, right? | |
| 13:08:16 | sean-k-mooney | e.g. resouce:vgpu or device-profile=whatever | |
| 13:08:17 | bauzas | this is like ironic | |
| 13:08:29 | sean-k-mooney | or pci_ailais=my-gpu | |
| 13:08:48 | bauzas | resource:vgpu=1 is only a nova syntax for nova-managed vgpus, right? | |
| 13:08:59 | gibi | flavors with resource:vgpu and flavors with device-profile could be interchangeable from the user perspective if he gets a VM with vGPU passed through in both case | |
| 13:09:01 | bauzas | in the flavor, I mean | |
| 13:09:28 | bauzas | gibi: you're mentioning a mixed usecase | |
| 13:09:32 | sean-k-mooney | bauzas: kind of yes. you could use the sriov based vgpus with pci passthough alias but for mdevs yes | |
| 13:09:45 | bauzas | gibi: where users don't care whether vgpus are offered by nova or cyborg | |
| 13:09:51 | gibi | bauzas: sort of yes | |
| 13:10:00 | sean-k-mooney | bauzas: yes but 99% they wont | |
| 13:10:01 | gibi | bauzas: I want to figure out which resource is interchangeable | |
| 13:10:10 | sean-k-mooney | cyborg is an mostly admin only api | |
| 13:10:25 | sean-k-mooney | so normally user wont interact with it | |
| 13:10:32 | bauzas | I think we're boiling the ocean and we need to babystep | |
| 13:10:52 | bauzas | *for the moment* cyborg flavors are using device profiles, right? | |
| 13:10:57 | sean-k-mooney | yes | |
| 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 | gibi | and then I agree with sean that os-resource-classes has no use | |
| 13:12:45 | bauzas | gibi: we can make a consensu | |
| 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 | sean-k-mooney | bauzas: it can only do that if we have a device profile | |
| 13:19:23 | bauzas | gibi: I mean, this is the conductor which would call cyborg-agent to bind the arq | |
| 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 | sean-k-mooney | gibi: they are litrally the same model of nvidia gpu | |
| 13:26:13 | gibi | it is just a vgpu resource nothing more | |
| 13:26:22 | gibi | regardless how you request it | |