Earlier  
Posted Nick Remark
#openstack-nova - 2021-06-22
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
17:14:44 sean-k-mooney supprot cybrog via the resouce: sysntax is totallyout of scope
17:14:47 bauzas sean-k-mooney: I understand and I don't wanna change this
17:15:01 bauzas ok, ok,
17:15:27 bauzas so a flavor is set with a device profile that's turned into a resources query by a prefilter, right?
17:15:49 sean-k-mooney yes
17:15:52 bauzas in this case, there is ZERO possibility to mix resources
17:16:01 bauzas whatever the resource is
17:16:01 sean-k-mooney well not refilter i thik we have explict logic for cyborg
17:16:15 sean-k-mooney today correct
17:16:26 bauzas so the mixed case is impossible today
17:16:30 sean-k-mooney yes
17:16:42 bauzas so, we're discussing about non-mixed resources

Earlier   Later