| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-23 | |||
| 13:37:43 | bauzas | you're asking placement to give you apples | |
| 13:38:04 | bauzas | it's not nova's fault that you ask for apples coming specially from Tesco | |
| 13:38:07 | sean-k-mooney | for example we could list all the device-profile that request the vgpu resouce and select one | |
| 13:38:18 | sean-k-mooney | and use that to create teh arq | |
| 13:38:35 | sean-k-mooney | ah but that is not what we asked for | |
| 13:38:42 | sean-k-mooney | we assed for resouce:vgpu=1 | |
| 13:38:47 | sean-k-mooney | with no other qulifyer | |
| 13:39:01 | bauzas | ok, back to the original thoughts (that's already 2 hours we're tangling the problem) | |
| 13:39:07 | bauzas | we progressed | |
| 13:39:07 | sean-k-mooney | the current propsal uses ownwer traits and a prefilter to make that owrk | |
| 13:39:32 | bauzas | we know we wanna express 'placement, give me apples that come from tesco and not from carrefour" | |
| 13:39:53 | sean-k-mooney | transparent ot the user or admin by adding a required trati for nova or forbidnint trait for cyborg in the resouce:vgpu case | |
| 13:40:06 | bauzas | sean-k-mooney: in this case, I'd prefer the forbidden trait way | |
| 13:40:22 | sean-k-mooney | we can do that but it makes nova special | |
| 13:40:23 | bauzas | "placement, give me apples from Tesco" in the cyborg case | |
| 13:40:41 | bauzas | "placement, give me apples not coming from Tesco as I know you got some of them" | |
| 13:40:57 | bauzas | sean-k-mooney: only if cyborg is configured on this cloud | |
| 13:41:05 | bauzas | this is the "as I know" | |
| 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 | |