| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-23 | |||
| 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 | |
| 14:05:25 | sean-k-mooney | dansmith: cyborg may have to update the RPs in some cases but we are modelign programabel devices as programable not programed | |
| 14:05:34 | dansmith | okay | |
| 14:05:50 | sean-k-mooney | for the cae wehre the admin will use cyborg directly to prgram it out of band that device would be consomed by cyborg | |
| 14:06:03 | sean-k-mooney | but the resouce provided form ti woudl be consuemd by nova still | |
| 14:06:32 | dansmith | ah, so cyborg consumes the programmable device itself, creates a new resource for the programmed thing, which nova is the consumer of, right? | |
| 14:06:48 | sean-k-mooney | yes in that case | |
| 14:06:53 | dansmith | yeah, okay | |
| 14:07:00 | sean-k-mooney | where the consumer of the programabel device is not a vm | |
| 14:07:06 | dansmith | yeah | |
| 14:07:17 | sean-k-mooney | e.g. where you have a many vm to 1 device toplogy | |
| 14:07:36 | sean-k-mooney | thats the theory at least | |
| 14:07:46 | sean-k-mooney | not sure they have actully implemente any dirver that does this yet | |
| 14:07:55 | dansmith | I guess that makes the concern over who is managing what less clear to me | |
| 14:08:08 | dansmith | which I think was what started this | |
| 14:08:35 | dansmith | this: [06: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 | |
| 14:09:52 | sean-k-mooney | we currently have 4 possibel ideas fo how to do ^ but no concreate propasl and we have not fully tought though all the implcaitons | |
| 14:10:17 | sean-k-mooney | cyborg being the first to need this was trying to propas a way in teh vgpu spec | |
| 14:10:56 | sean-k-mooney | using the ownwer_trits approch but bauzas has conserns over that as does gibi | |
| 14:11:11 | sean-k-mooney | but really this is a sperate problem form cybrog vgpu supprot | |
| 14:11:19 | bauzas | my main concern is that we need to add traits for nova hosts | |
| 14:11:42 | sean-k-mooney | yes but they are not really nova hosts | |
| 14:11:59 | bauzas | non cyborg managed hosts, if you prefer | |
| 14:12:10 | bauzas | or libvirt-managed hosts | |
| 14:12:18 | sean-k-mooney | we are supper bias but i have agrued since before nested resouce providers that nova shoudl not own the root rp | |
| 14:12:38 | sean-k-mooney | well it was one of my argument for intoducing them | |
| 14:12:55 | sean-k-mooney | the "compute" host is really a shared thing | |
| 14:13:05 | sean-k-mooney | to which multiple serivce may create resouces | |
| 14:14:07 | sean-k-mooney | being totally frank im worried that we will not come to a desicion on this this cycle and cyborg will have to with a third time to make progress | |
| 14:16:03 | sean-k-mooney | i have personaly see this type of discussion take litrally 2-3 year to progress and i think that is harmful to the openstack comunity as a whole. i also dont want to rush it as its hard to pivort after its released | |
| 14:17:32 | bauzas | we provided alternatives | |
| 14:17:58 | sean-k-mooney | yes but we dont agree on any of them | |
| 14:19:42 | sean-k-mooney | i hate to say this but i think we need a spec for this or atleast an etherpad and some midcycle like real time design session on this | |