| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-23 | |||
| 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 | |
| 14:20:04 | sean-k-mooney | this is exactly the type of thing we woule have worked though in the ptg | |
| 14:20:42 | sean-k-mooney | with a whiteboard and all the stake holders (where possible) in the same room | |
| 14:21:16 | bauzas | I can't disagree | |
| 14:21:24 | dansmith | we've also had plenty of those in the past which didn't yield much progress.. specifically about cyborg :) | |