| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-23 | |||
| 13:41:34 | sean-k-mooney | that works if the class is only shared across 2 service but not 3+ | |
| 13:41:36 | bauzas | nothing would change for operators who don't give a single penny to cyborg | |
| 13:41:54 | sean-k-mooney | there is another way i guess | |
| 13:42:05 | sean-k-mooney | we could use placment aggreate to track ownership | |
| 13:42:07 | bauzas | the other way is aggregates | |
| 13:42:29 | bauzas | "placement, don't give me apples coming from those supermarkets" | |
| 13:42:32 | sean-k-mooney | each proejct woudl add all there rps to an aggate | |
| 13:42:49 | bauzas | sean-k-mooney: I insist | |
| 13:42:52 | sean-k-mooney | and then nova would in the nova case add a member_of requirement to the vgpu request group | |
| 13:43:21 | bauzas | sean-k-mooney: whatever the solution is, the prefilter which would have the excluding logic (for the nova case) should only do this if cyborg manages hosts | |
| 13:43:26 | opendevreview | Lee Yarwood proposed openstack/nova master: Add check job for FIPS https://review.opendev.org/c/openstack/nova/+/790519 | |
| 13:43:45 | sean-k-mooney | bauzas: that is trival to do | |
| 13:43:57 | sean-k-mooney | bauzas: we just have a config option for it | |
| 13:44:06 | sean-k-mooney | like pcpus | |
| 13:44:06 | bauzas | sean-k-mooney: I don't want upgrade impacts if the operator doesn't use cyborg yet | |
| 13:44:44 | bauzas | sean-k-mooney: can we express "give me hosts that are not from this aggregate" ? | |
| 13:44:44 | sean-k-mooney | there wont be one if we do this correctly regarless of ownwer traits ro differnt resouce classes | |
| 13:44:54 | sean-k-mooney | bauzas: yes | |
| 13:45:09 | bauzas | ok, so there are no operations for nova-managed hosts | |
| 13:45:12 | sean-k-mooney | but i do not think we shoudl do a negitive member_or for cyborg | |
| 13:45:20 | bauzas | sean-k-mooney: the other way | |
| 13:45:33 | bauzas | sean-k-mooney: cyborg would manage an aggregate of managed hosts | |
| 13:45:53 | sean-k-mooney | for nova the prefilter when enabled would do member_op=nova-aggate or member_of=cyborg-aggreate | |
| 13:45:56 | bauzas | the prefilter would ask for hosts that are members of this agg in the cyborg case | |
| 13:46:03 | sean-k-mooney | when prefilter is off it wont do anything | |
| 13:46:25 | bauzas | but in the nova case, the prefilter would ask hosts that AREN'T hosts of this agg | |
| 13:46:40 | bauzas | sean-k-mooney: again, I don't wanna manage a fleet of nova hosts | |
| 13:46:42 | sean-k-mooney | bauzas: no i dont think that is the corrct way to do that | |
| 13:46:54 | sean-k-mooney | bauzas: that is short sighted in my opipion | |
| 13:47:09 | sean-k-mooney | we can have nova automatic regesiter in the nova host aggrate | |
| 13:47:16 | bauzas | eeek | |
| 13:47:26 | sean-k-mooney | we just need to choose a fixed uuid for it using uuid5 | |
| 13:47:40 | bauzas | yet again some hack for a non-necessary need in the case of operators don't care about cyborg | |
| 13:47:46 | gibi | I think we should forbid to have two services provide exactly the same thing. As soon as one of the service provides an extra capability like programability then we can schedule based on that. Ownership is an artificial quality we invented as there is no difference between the two vGPU devices. | |
| 13:48:10 | sean-k-mooney | gibi: ok so we are going to reject the cybrog vgpu spec then | |
| 13:48:22 | sean-k-mooney | gibi: since it provides nothing over novs implemenation ? | |
| 13:48:23 | gibi | so I'm back to my argument that I don't like duplicating capabilities between services | |
| 13:48:39 | gibi | as it adds 0 value | |
| 13:48:57 | bauzas | I have to bail out for 20 mins | |
| 13:49:25 | sean-k-mooney | should we schdule a call on this topic to get wider input | |
| 13:49:48 | gibi | sean-k-mooney: do you know who else cares about one or the other vgpu support? | |
| 13:49:50 | sean-k-mooney | gibi: ill bring up the idea of supporting cyborg in our product again today and see if there is any apitate for that | |
| 13:50:08 | sean-k-mooney | gibi: not not really | |
| 13:50:29 | bauzas | sean-k-mooney: I don't see it happening in OSP18 | |
| 13:50:37 | bauzas | soooo, 1+ | |
| 13:50:37 | gibi | as I only argue from the complexity persepective I cannot argue about the business perspective, I have no business in this area | |
| 13:50:38 | bauzas | A+ | |
| 13:50:38 | sean-k-mooney | i was jsut wondering if we want dansmith or johnthetubague | |
| 13:50:49 | sean-k-mooney | basicaly the wider core team | |
| 13:51:41 | opendevreview | Stephen Finucane proposed openstack/nova stable/wallaby: Test numa and vcpu topologies bug: #1910466 https://review.opendev.org/c/openstack/nova/+/797652 | |
| 13:51:42 | opendevreview | Stephen Finucane proposed openstack/nova stable/wallaby: Fix max cpu topologies with numa affinity https://review.opendev.org/c/openstack/nova/+/797653 | |
| 13:51:50 | dansmith | well, I can't really speak to the business side either, | |
| 13:51:56 | dansmith | but I totally agree with gibi on a technical level | |
| 13:52:22 | dansmith | it makes no sense to me to build half of cyborg inside nova unless there's some reason it has to be done that way | |
| 13:52:41 | sean-k-mooney | re no duplication i dont nessisarly dissagree just practicalities | |
| 13:53:22 | dansmith | practicalities of "it's just easier to hack in the bits we care about into nova than to coordinate with or contribute to another project" right? | |
| 13:53:45 | sean-k-mooney | ok taking downstream out of this i think it would be goind to do a paper exersise of thinking howe we woudl supprot shareing of resouce classes ectra in general between services | |
| 13:54:28 | dansmith | isn't that what the long-awaited consumer types is supposed to help with? | |
| 13:54:36 | bauzas | dansmith: that's my main concern | |
| 13:54:41 | sean-k-mooney | dansmith: well not just its easier because if we are bing honest its not eair to land thing in nova | |
| 13:54:53 | bauzas | adding nova traits for the whole purpose of cyborg seems invasive | |
| 13:54:56 | sean-k-mooney | dansmith: not really no | |
| 13:55:11 | sean-k-mooney | consumer type does nto help with shareing resouce classes between services | |
| 13:55:40 | dansmith | sean-k-mooney: well, it does if you have a nested provider so you know where the seam is | |
| 13:56:02 | sean-k-mooney | dansmith: no because cybrog creates RPs under the compute node RP | |
| 13:56:10 | sean-k-mooney | so we cant use same subtree here | |
| 13:56:14 | sean-k-mooney | it wont help | |
| 13:56:46 | sean-k-mooney | not unless we move all rescoue off the root RP | |
| 13:57:07 | sean-k-mooney | and have each service start there own subtreed form a common shared root rp | |
| 13:57:13 | gibi | consumer type is like, instance, migration, reservation, etc. What we have here is provider type it is provided (managed by) nova, cyborg, neutron... | |
| 13:57:28 | sean-k-mooney | yep ^ | |
| 13:57:47 | gibi | so I don't think consumer_type helps here | |
| 13:57:51 | bauzas | gibi: only because we need to ask placement to only give us a subset | |
| 13:58:08 | bauzas | for cyborg-only reasons | |
| 13:58:15 | sean-k-mooney | not just for cyborg | |
| 13:58:19 | gibi | bauzas: but we only need to ask for a subset if that subset is different from the other subset | |
| 13:58:37 | gibi | is the two subsets provide the same capability the why differentiate | |
| 13:58:51 | gibi | s/is/if/ | |
| 13:58:53 | bauzas | sean-k-mooney: at the moment, yes, only because cyborg | |
| 13:59:03 | bauzas | gibi: 100% agreed | |
| 13:59:22 | bauzas | it's a whack-a-mole game | |
| 13:59:25 | gibi | we differentiate not becasue they provide different capabilities but becuase there is different implementation behind them we need to be aware off during plugging | |
| 13:59:32 | sean-k-mooney | the usecase predates it the cybrog one and blocked ohter feature in the past | |
| 13:59:50 | bauzas | gibi: again, 100% agreed on your last sentence | |
| 14:00:01 | sean-k-mooney | i dont like catogoriesing this as a problem cause by cyborg | |
| 14:00:13 | gibi | maybe vgpu is an exception, a historical exception | |
| 14:00:20 | sean-k-mooney | its a nova/placement limmiation taht we need to solve genericly to enable cyborg and other usecases | |
| 14:00:44 | sean-k-mooney | gibi: well cyborg is doing generic pci passthough also | |
| 14:00:44 | bauzas | gibi: other services could propose resources to consume | |
| 14:00:49 | gibi | and all the other similar cases like accelerator_direct and disk_gb are different as there we have real differences to schedule on | |
| 14:01:20 | gibi | and dont need to invent ownership as a differentiatoer | |
| 14:01:33 | dansmith | so the concern is managing the actual RP and available resource for the cyborg things and not the allocations of those things by another source? | |
| 14:01:59 | dansmith | because cyborg reserving some accelerator that is on the compute RP _would_ use a different consumer_type I would think | |
| 14:02:25 | gibi | cyborg does not create consumers nova create the consumer after scheduling | |
| 14:02:34 | gibi | cyborg only creates inventories | |
| 14:02:58 | dansmith | okay I guess this has all fallen out of my head | |
| 14:02:59 | gibi | or we are back to the discussion to split the instance consumer into subconsumers | |
| 14:03:22 | gibi | today we have a single consumer per instance (except during migration) | |
| 14:03:32 | dansmith | I thought cyborg was going to have to do that because of dynamic devices that may or may not exist until they're scheduled | |
| 14:03:48 | dansmith | things it programs to create a new device that wasn't actually part of the schedule | |