| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-06-22 | |||
| 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 | |
| 17:16:48 | bauzas | which can be solved with custom RCs | |
| 17:16:55 | sean-k-mooney | unless tehy break one fo the rule we have about palcment useage | |
| 17:17:19 | sean-k-mooney | bauzas: it can but it does not have to be | |
| 17:17:40 | bauzas | sean-k-mooney: the other possibility implies a huge change for existing deployments, right? | |
| 17:17:47 | sean-k-mooney | no | |
| 17:17:50 | sean-k-mooney | not really | |
| 17:18:08 | sean-k-mooney | just that we would add a trait to all nova rps | |
| 17:18:17 | sean-k-mooney | and we would automatically add it with a prefilter | |
| 17:18:28 | bauzas | yup, I got this, this is a technical answer | |
| 17:18:53 | bauzas | which prevents us to discuss about alternatives | |
| 17:19:06 | sean-k-mooney | we can discuss alternitves | |
| 17:19:18 | bauzas | and the one I'm proposing (again, for the non-mixed case) doesn't imply upgrade impacts | |
| 17:19:19 | sean-k-mooney | but we have discsuted this for 2+ cycle now | |
| 17:19:43 | sean-k-mooney | correct but it means we dotn need os-resouce classes | |
| 17:19:54 | sean-k-mooney | since resouce classes will have to be different per service | |
| 17:20:06 | sean-k-mooney | so its not free | |
| 17:20:51 | sean-k-mooney | bauzas: if we ant differnt service to use diffeernt resouces classes for the same resouce class we can do that | |
| 17:20:54 | bauzas | the whole situation is that we need some scheduling query for telling "yo' I really want cyborg" | |
| 17:20:59 | sean-k-mooney | but its restricting the usfulness of placment | |
| 17:21:18 | sean-k-mooney | or i really want nova but yes | |
| 17:21:59 | sean-k-mooney | which is why the ownwer trait was proposed so we could make a qualitave statmetn about the resouce provier | |
| 17:22:03 | bauzas | nope, in general, you don't need to tell placement "give me nova stuff" | |
| 17:22:28 | bauzas | because if you ask for nova resouces, you get nova stuff | |
| 17:22:36 | sean-k-mooney | you may not | |
| 17:22:50 | bauzas | agreed | |
| 17:22:52 | sean-k-mooney | zun could create RPs with cpu ram and disk | |
| 17:23:00 | bauzas | if cinder was using placement for their own volumes | |
| 17:23:15 | bauzas | you could ask placement for things that nova doesn't knoxw | |
| 17:23:22 | sean-k-mooney | yes | |
| 17:23:34 | bauzas | zun is a good example | |
| 17:23:39 | sean-k-mooney | we have demonstarted that with provider.yaml also | |
| 17:24:22 | sean-k-mooney | bauzas: i think you jsut made an argument indirecly that i might be able to get behind | |
| 17:24:58 | sean-k-mooney | i never want people ot user resouce_# syntax with traits_# sysntax in teh falvor directly | |
| 17:25:24 | sean-k-mooney | e.g. i dont want people to have to use the placmenet group sysntax in flavors | |
| 17:25:54 | sean-k-mooney | so if we are getttign resouce owned by differetn service i dont want them to have to specify traits in request groups in the flavor | |
| 17:26:09 | bauzas | that's reasonable | |
| 17:26:33 | sean-k-mooney | with different resouce_class we dont have to do this | |
| 17:26:47 | sean-k-mooney | along as we dont share resouce classes or do it in a managed way | |
| 17:27:30 | sean-k-mooney | e.g. cindr can use the disk_GB resouce class as long as it does so useing sharing aggreates and does nto create RPs or inventorees under the compute | |
| 17:28:07 | sean-k-mooney | cyborg could use vgpu rc in the same way but only if its not under the compute RP | |
| 17:28:46 | sean-k-mooney | well hum no i need to take a break and think about this with a clear head | |
| 17:28:59 | bauzas | me too | |
| 17:29:09 | bauzas | my hardstop was a softstop | |
| 17:29:21 | bauzas | but my wife should kill me if I'm still writing in 2 mins | |
| 17:29:33 | bauzas | (me joking tbc) | |
| 17:29:57 | sean-k-mooney | i think im going to finsih here also :) | |
| #openstack-nova - 2021-06-23 | |||
| 08:05:01 | lyarwood | morning \o | |
| 08:59:48 | gibi | \o | |
| 09:15:13 | frickler | lyarwood: https://bugs.launchpad.net/nova/+bug/1452641 just came up in #openstack-dev , are you still planning to proceed with https://review.opendev.org/c/openstack/nova/+/579004/ ? (changing ceph mon addresses) | |
| 09:18:14 | lyarwood | frickler: yeah but not as part of that change anymore, I'm writing up a spec at the moment to provide a set of nova-manage commands to allow operators to do refresh this for SHUTOFF instances | |
| 09:18:48 | lyarwood | frickler: the alternative is for users to shelve and unshelve the instances | |
| 09:20:30 | frickler | lyarwood: well from an operator perspective it would be great to have a solution that it transparent to the users and allows them to keep instances running, but I admit that that may not be achievable | |
| 09:21:20 | lyarwood | yeah that's pretty hard if impossible | |
| 09:22:24 | bauzas | will be back around 1130UTC | |
| 09:57:50 | opendevreview | Lee Yarwood proposed openstack/nova master: zuul: Add CentOS 8 stream integrated compute tempest job to gate https://review.opendev.org/c/openstack/nova/+/797616 | |
| 11:58:26 | sean-k-mooney | frickler: the best way to do that might just be to alwasy put the ceph monds behind haproxy or a keepalived vrrp vip | |
| 11:58:42 | sean-k-mooney | frickler: e.g. do not have the actul mon ips present | |
| 11:58:57 | sean-k-mooney | have a sperate one that you can move there instead | |
| 11:59:46 | gibi | sean-k-mooney, bauzas: I've left my view about vgpu in https://review.opendev.org/c/openstack/nova-specs/+/780452 | |
| 12:00:17 | bauzas | gibi: ack | |
| 12:01:36 | sean-k-mooney | "Does OWNER_CYBORG trait on an RP means that _every_ RC on that RP is managed by Cyborg?" so yes traits apply to all invetories in a RP | |
| 12:01:46 | sean-k-mooney | that is why traits are on the RP not the inventory | |
| 12:02:12 | bauzas | gibi: so your comment would be about providing only traits for Cyborg VGPUs ? I'm OK if so | |
| 12:02:37 | sean-k-mooney | bauzas: we woudl have to use a forbiden trait on nova if we only do if for cyborg | |