| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-23 | |||
| 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 :) | |
| 14:22:05 | sean-k-mooney | ya the dublin seesion in partcalar was less then useful | |
| 14:24:06 | sean-k-mooney | gibi: thanks for trying to help | |
| 14:24:13 | sean-k-mooney | but i feel the same | |
| 14:24:36 | gibi | I summarized my lates view in the spec review but I haven't published it yet. | |
| 14:25:11 | sean-k-mooney | could we just use a custom resouce class for now an punt on this for now | |
| 14:25:22 | gibi | I'm torn between doing the right thing architecturally and supporting a parallel projec to integrate with nova technically | |
| 14:25:56 | sean-k-mooney | i know that would requrie a reshape eventually but at least it would unblcok them | |
| 14:26:11 | gibi | it would unblock them and we will never allocate time to do that reshape later | |
| 14:26:27 | sean-k-mooney | well it would be in cyborg? | |
| 14:26:29 | gibi | as it just a lot of work | |
| 14:26:36 | gibi | for basicly nothing | |
| 14:26:37 | sean-k-mooney | maybe it would be in nova | |
| 14:26:54 | sean-k-mooney | damb cross project reshapes will be a bitch to fiture out forget i said anything | |
| 14:38:54 | bauzas | gibi: thanks | |
| 14:39:09 | elodilles | sean-k-mooney gibi : as we yesterday discussed on the meeting, here is an example of a failure what I saw: test_live_block_migration_with_attached_volume -- https://c5d6a707d1df71acd55f-fbeed0693cac4a6e5441d43111515edc.ssl.cf5.rackcdn.com/787252/4/gate/nova-live-migration/706ec17/testr_results.html | |
| 14:40:17 | gibi | elodilles: looking | |
| 14:40:19 | elodilles | I saw this a couple of times at the failures of this patch: https://review.opendev.org/c/openstack/nova/+/787252 | |
| 14:40:23 | gibi | elodilles: you have a good timing :) | |
| 14:40:25 | elodilles | stable/victoria | |
| 14:40:33 | elodilles | gibi: why? o:) | |
| 14:40:41 | sean-k-mooney | weird | |
| 14:40:49 | sean-k-mooney | both thos test refernce the same volume 7688b3f1-6549-4e0c-a507-9789ddc2eb95 | |
| 14:41:08 | gibi | elodilles: I've just stopped thinking about the above vGPU problem | |
| 14:41:30 | sean-k-mooney | that should not happen right | |
| 14:41:41 | sean-k-mooney | two tests refering to the same volume uuid 7688b3f1-6549-4e0c-a507-9789ddc2eb95 | |
| 14:41:51 | sean-k-mooney | if they run in parally they would conflict | |
| 14:42:00 | gibi | sean-k-mooney: wich two test cases? | |
| 14:42:05 | gibi | sean-k-mooney: I see a testcase and a tear down | |
| 14:42:11 | gibi | of the suite | |
| 14:42:19 | sean-k-mooney | oh ya its the tear down method | |
| 14:42:29 | elodilles | gibi: well I've seen that there was an ongoing discussion so I did not want to interrupt earlier :) | |
| 14:42:29 | sean-k-mooney | ok that make a liit more sense | |
| 14:43:42 | sean-k-mooney | ok so the teardown failed becasue presumable the volume was still attached to the vm | |
| 14:43:54 | sean-k-mooney | it was in state detaching | |
| 14:46:28 | gibi | it is trying to detach in a loop so I guess it is the original detach problem | |