| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-22 | |||
| 16:53:13 | sean-k-mooney | bauzas: we can talk tabout it tomorrow then but tl;dr; today no too openstack service can use the same RC class and no two openstack service can share the same RP | |
| 16:53:14 | bauzas | I could even show source code | |
| 16:53:35 | sean-k-mooney | bauzas: the ownwer triat was a way to allow reuse of stanard RCs across services | |
| 16:53:43 | bauzas | sean-k-mooney: based on your first assumption, that means cyborg can't provide VGPU resources ? | |
| 16:53:59 | bauzas | sean-k-mooney: gosh, this sounds hacky | |
| 16:54:05 | sean-k-mooney | correct which is why the ownwer trait was intoduced in the spec | |
| 16:54:21 | gmann | sean-k-mooney: Mitaka was last with legacy v2 code and since newton we started single code path for v2 and v2.1 which has these schema validation | |
| 16:54:36 | sean-k-mooney | without an owner of the resouce provider in some form resouce classes cant be shared | |
| 16:54:51 | bauzas | sean-k-mooney: honestly, I'd prefer us to have a way to know about which service owns a RP with by default be 'nova' | |
| 16:55:06 | bauzas | meaning another attribute of a RP | |
| 16:55:10 | sean-k-mooney | bauzas: well that is exactly what the ownwer traits were ment to be | |
| 16:55:26 | sean-k-mooney | bauzas: since peole did not want a dedicated value on the RP | |
| 16:55:29 | bauzas | the owner trait is just a hack because we wanna make it round | |
| 16:55:49 | sean-k-mooney | bauzas: we proposed added ownwer before and peopel objected | |
| 16:55:58 | bauzas | sean-k-mooney: then I don't guess why we need to explicitely mark a nova trait | |
| 16:56:05 | sean-k-mooney | we can certenly do that again but the default shoudl nto be nova | |
| 16:56:15 | gmann | sean-k-mooney: stephenfin ohk its modified code he mentioned in github discussion so upstream code is all good | |
| 16:56:19 | bauzas | sean-k-mooneythe default should what ? | |
| 16:56:37 | sean-k-mooney | bauzas: empty | |
| 16:56:51 | sean-k-mooney | bauzas: placment should not prefer nova over other services | |
| 16:56:51 | bauzas | empty meaning ? | |
| 16:57:20 | sean-k-mooney | meaning unowned | |
| 16:57:29 | bauzas | this is wrong | |
| 16:57:33 | sean-k-mooney | bascaly we ould need a reshape | |
| 16:57:35 | bauzas | any RP is owned by something | |
| 16:57:42 | sean-k-mooney | wel just update | |
| 16:57:48 | sean-k-mooney | to populated it for nova RPs | |
| 16:58:11 | sean-k-mooney | gmann: thanks ill feed that back downstream unless you commented on ghitbub already? | |
| 16:58:33 | bauzas | sean-k-mooney: I need to hardstop but let's continue the convo with gibi later tomorrow | |
| 16:58:34 | gmann | sean-k-mooney: doing on github | |
| 16:58:57 | sean-k-mooney | bauzas: ack o/ | |
| 16:59:03 | sean-k-mooney | gmann: thanks | |
| 16:59:23 | bauzas | sean-k-mooney: I guess I'm afraid by all the implications of tagging our RPs explicitely | |
| 16:59:48 | sean-k-mooney | bauzas: whcih is why we need to discuss in a spec :) | |
| 16:59:53 | bauzas | and I just wanna be sure this is the only possibility | |
| 17:00:21 | bauzas | sean-k-mooney: think about something until tomorrow | |
| 17:01:34 | bauzas | sean-k-mooney: would it be a problem if nova would create RPs with VGPUs in it, while cyborg creates RPs with VGPU in them too, and eventually the allocation would go straight to the nova-compute service holding the allocated RP | |
| 17:01:57 | bauzas | I just feel the nova-compute service could know which RPs is owned by who | |
| 17:03:12 | bauzas | and defer to cyborg-agent binding if so | |
| 17:03:42 | bauzas | or just call libvirt if the allocated RP was owned by nova | |
| 17:04:12 | opendevreview | Stephen Finucane proposed openstack/nova master: scheduler: Remove 'USES_ALLOCATION_CANDIDATES' https://review.opendev.org/c/openstack/nova/+/773640 | |
| 17:04:12 | opendevreview | Stephen Finucane proposed openstack/nova master: scheduler: Remove 'hosts_up' https://review.opendev.org/c/openstack/nova/+/773641 | |
| 17:04:13 | opendevreview | Stephen Finucane proposed openstack/nova master: trivial: Remove FakeScheduler (for realz) https://review.opendev.org/c/openstack/nova/+/773642 | |
| 17:04:13 | opendevreview | Stephen Finucane proposed openstack/nova master: scheduler: Merge 'FilterScheduler' into base class https://review.opendev.org/c/openstack/nova/+/773643 | |
| 17:04:14 | opendevreview | Stephen Finucane proposed openstack/nova master: docs: Drop references to non-filter scheduler drivers https://review.opendev.org/c/openstack/nova/+/773645 | |
| 17:04:14 | opendevreview | Stephen Finucane proposed openstack/nova master: scheduler: Merge driver into manager https://review.opendev.org/c/openstack/nova/+/773644 | |
| 17:04:15 | opendevreview | Stephen Finucane proposed openstack/nova master: tests: Merge 'test_utils', 'test_scheduler_utils' https://review.opendev.org/c/openstack/nova/+/773646 | |
| 17:04:16 | opendevreview | Stephen Finucane proposed openstack/nova master: conf: Remove deprecated aliases https://review.opendev.org/c/openstack/nova/+/773647 | |
| 17:04:16 | opendevreview | Stephen Finucane proposed openstack/nova master: scheduler: 'USES_ALLOCATION_CANDIDATES' removal cleanup https://review.opendev.org/c/openstack/nova/+/797513 | |
| 17:04:20 | bauzas | sean-k-mooney: this isn't a scheduling decision until you wanna explicitely shard your resources between nova and cyborg (the non-mixed case) | |
| 17:04:40 | bauzas | and for the non-mixed case, we can have different RCs | |
| 17:04:54 | bauzas | instead of a owner trait | |
| 17:05:30 | sean-k-mooney | bauzas: if the request is in the flavor and ti does not come form a device profile then nova shoudl ensure it does not come form an nova created RP | |
| 17:06:18 | sean-k-mooney | the instresting part is if you have resouces:vgpu=1 | |
| 17:06:26 | bauzas | the mixed case | |
| 17:06:27 | sean-k-mooney | which today can only come form nova | |
| 17:06:38 | bauzas | the non-mixed case can be solved with custom RCs | |
| 17:06:57 | sean-k-mooney | and the question then is what hsoudl the bhavior be in the absense of a trait | |
| 17:07:09 | sean-k-mooney | anyway let talk tommorow | |
| 17:07:13 | bauzas | for the mixed case, you can admit that it's OK for a spawn to go to the nova-compute | |
| 17:07:27 | bauzas | and then the nova-compute can either call cyborg-agent to bind | |
| 17:07:33 | bauzas | or, call libvirt to just spawn | |
| 17:07:34 | sean-k-mooney | no that is not ok | |
| 17:07:48 | sean-k-mooney | well maybe | |
| 17:07:55 | sean-k-mooney | but it would be rather complicated | |
| 17:08:06 | sean-k-mooney | ill think about it tonight | |
| 17:08:23 | bauzas | we already get allocations before we call libvirt | |
| 17:08:30 | sean-k-mooney | but it would require change not currently in the spec | |
| 17:08:40 | bauzas | so we already know the allocated RPs | |
| 17:09:01 | sean-k-mooney | bauzas: correct but we will need the condurtor to determin if the rp in the allocation is owned by nova or cyborg | |
| 17:09:07 | bauzas | it's just the nova-compute service which doesn't care and directly passes the allocations as arguments | |
| 17:09:14 | sean-k-mooney | and then have it start the bidning before we call the compute node | |
| 17:09:14 | opendevreview | Merged openstack/nova master: Fix max cpu topologies with numa affinity https://review.opendev.org/c/openstack/nova/+/769614 | |
| 17:09:31 | sean-k-mooney | sicne we do the arq binding in the conductor | |
| 17:09:34 | bauzas | sean-k-mooney: that's not the workflow I see in https://review.opendev.org/c/openstack/nova-specs/+/780452/8/specs/xena/approved/support-vGPU-nova-cyborg-interaction.rst#132 | |
| 17:09:42 | sean-k-mooney | and without a device procfile we will not know how to create teh arq | |
| 17:09:44 | bauzas | holy shit | |
| 17:09:57 | bauzas | 'nova's is both the conductor and the compute service | |
| 17:09:59 | sean-k-mooney | so we cant make that work without changing the cybrog api | |
| 17:10:03 | bauzas | in the workflow diagram | |
| 17:10:23 | bauzas | well, we get allocations in the conductor, right? | |
| 17:10:39 | bauzas | in order to know which compute services to call, right? | |
| 17:10:41 | sean-k-mooney | yes and we create and bind arqs in the conductor too | |
| 17:10:57 | bauzas | ok, so it's just an extra bit | |
| 17:10:59 | sean-k-mooney | but to create an arq we need a device profile | |
| 17:11:34 | sean-k-mooney | so if we have resouce:vgpu in the flavor it cant be used to create a cybrog ARQ today as we dont have a device profile | |
| 17:11:38 | bauzas | sure, I see it in the diagram | |
| 17:12:05 | bauzas | we create a device profile before we call scheduling, right? | |
| 17:12:12 | sean-k-mooney | so right now a refilter can eailar determin if the vgpu request is from nvoa or cyborg | |
| 17:12:29 | sean-k-mooney | bauzas: yes its a resouce in the cyborg api | |
| 17:12:32 | bauzas | because we never mix | |
| 17:12:49 | sean-k-mooney | so the admihn create a device profile and then creates a flavor that refrence s it | |
| 17:12:59 | sean-k-mooney | bauzas: a device profile is like a pci aliasa | |
| 17:13:03 | bauzas | yup, I got it | |
| 17:13:19 | sean-k-mooney | your are 13 mins passed your hard stop :) | |
| 17:13:41 | bauzas | but it's premature I think to get a device profile based on an assumption that a flavor asked for a vgpu | |
| 17:14:04 | sean-k-mooney | bauzas: that not how that works | |
| 17:14:09 | bauzas | you should get the device profile only if the allocated resource is owned by cyborg | |
| 17:14:15 | bauzas | sean-k-mooney: I know | |
| 17:14:28 | sean-k-mooney | right now the only way to request cybrog resoruce is via a device profile | |