| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-05-04 | |||
| 13:52:11 | bauzas | also the AZ is not a specific DB value | |
| 13:52:11 | bauzas | also the AZ is not a specific DB value | |
| 13:52:27 | bauzas | we persist the whole RequestSpec | |
| 13:52:27 | bauzas | we persist the whole RequestSpec | |
| 13:52:42 | sean-k-mooney | in the api db | |
| 13:52:42 | sean-k-mooney | in the api db | |
| 13:53:13 | bauzas | well, I guess he knows | |
| 13:53:13 | bauzas | well, I guess he knows | |
| 13:53:16 | tobias-urdin | so where could i check if an AZ was selected at creation or not, since instance.availability_zone only reflects the node it's scheduled to and only updated by scheduler after decision | |
| 13:53:16 | tobias-urdin | so where could i check if an AZ was selected at creation or not, since instance.availability_zone only reflects the node it's scheduled to and only updated by scheduler after decision | |
| 13:53:41 | bauzas | yup | |
| 13:53:47 | tobias-urdin | i remember there was a issue a long time ago that horizon for example always explicitly set AZ until that was fixed, but nova/openstack-client(?) cli never passed it (correctly being None) | |
| 13:53:47 | tobias-urdin | i remember there was a issue a long time ago that horizon for example always explicitly set AZ until that was fixed, but nova/openstack-client(?) cli never passed it (correctly being None) | |
| 13:54:15 | bauzas | as sean-k-mooney said, you could add a weigher for looking at the instance AZ value and trying to accept hosts within the same AZ, but I wouldn't be happy to accept it upstream | |
| 13:54:15 | bauzas | as sean-k-mooney said, you could add a weigher for looking at the instance AZ value and trying to accept hosts within the same AZ, but I wouldn't be happy to accept it upstream | |
| 13:54:53 | bauzas | by default, the instance.az value is None | |
| 13:54:53 | bauzas | by default, the instance.az value is None | |
| 13:54:58 | bauzas | until this goes to the host | |
| 13:54:58 | bauzas | until this goes to the host | |
| 13:55:01 | sean-k-mooney | bauzas: no? it would be pretty simple to add upstream but i wouldnt backport it obviously | |
| 13:55:01 | sean-k-mooney | bauzas: no? it would be pretty simple to add upstream but i wouldnt backport it obviously | |
| 13:55:20 | bauzas | sean-k-mooney: no, because the filters/weighers only look at the requestspec | |
| 13:55:20 | bauzas | sean-k-mooney: no, because the filters/weighers only look at the requestspec | |
| 13:55:29 | bauzas | not at the existing instance | |
| 13:55:29 | bauzas | not at the existing instance | |
| 13:55:33 | sean-k-mooney | ah ok | |
| 13:55:43 | sean-k-mooney | dont they have the instance i guess not | |
| 13:55:43 | sean-k-mooney | dont they have the instance i guess not | |
| 13:55:52 | bauzas | no, they don't | |
| 13:55:52 | bauzas | no, they don't | |
| 13:56:01 | sean-k-mooney | ok then ya makes sense | |
| 13:56:01 | bauzas | we pass both the requestspec and the asked host | |
| 13:56:01 | sean-k-mooney | ok then ya makes sense | |
| 13:56:01 | bauzas | we pass both the requestspec and the asked host | |
| 13:56:19 | sean-k-mooney | we shoudl not change the interface | |
| 13:56:19 | sean-k-mooney | we shoudl not change the interface | |
| 13:56:37 | bauzas | of course, a filter could ask for more (like calling the DB) but we stopped to accept this after Liberty IIRC | |
| 13:56:37 | bauzas | of course, a filter could ask for more (like calling the DB) but we stopped to accept this after Liberty IIRC | |
| 13:56:45 | bauzas | as it's a performance issue | |
| 13:56:45 | bauzas | as it's a performance issue | |
| 13:57:04 | sean-k-mooney | well so coudl the weighers but same issue | |
| 13:57:04 | sean-k-mooney | well so coudl the weighers but same issue | |
| 13:57:14 | openstackgerrit | Balazs Gibizer proposed openstack/nova-specs master: QoS minimum guaranteed packet rate https://review.opendev.org/c/openstack/nova-specs/+/785014 | |
| 13:57:33 | sean-k-mooney | the request spec has the instance uuid so you can do the lookups but you dont want to do this per host | |
| 13:57:33 | sean-k-mooney | the request spec has the instance uuid so you can do the lookups but you dont want to do this per host | |
| 13:57:38 | bauzas | instead of having the filters calling the DB, we instead make sure that both HostState and RequestSpec objects provide what we need | |
| 13:57:38 | bauzas | instead of having the filters calling the DB, we instead make sure that both HostState and RequestSpec objects provide what we need | |
| 13:57:55 | sean-k-mooney | yep | |
| 13:58:00 | bauzas | sean-k-mooney: this only has the instance_uuid for the first instance created with the same RequestSpec :) | |
| 13:58:00 | bauzas | sean-k-mooney: this only has the instance_uuid for the first instance created with the same RequestSpec :) | |
| 13:58:27 | bauzas | sean-k-mooney: I don't remember whether we change this when you create more than one instance at the same time | |
| 13:58:27 | bauzas | sean-k-mooney: I don't remember whether we change this when you create more than one instance at the same time | |
| 13:58:39 | bauzas | but that's a bug if no | |
| 13:58:39 | bauzas | but that's a bug if no | |
| 13:58:43 | tobias-urdin | i would really hurt adding something custom for such a corner case, but i guess i'll see what i can do | |
| 13:58:43 | tobias-urdin | i would really hurt adding something custom for such a corner case, but i guess i'll see what i can do | |
| 14:00:08 | tobias-urdin | but it's a bit messy since i can't force a resize to a specific node either there is no (native) way of disallowing it so scheduling will always be "wrong" | |
| 14:00:08 | tobias-urdin | but it's a bit messy since i can't force a resize to a specific node either there is no (native) way of disallowing it so scheduling will always be "wrong" | |
| 14:00:11 | bauzas | tobias-urdin: honestly, this is not a bug, right? | |
| 14:00:11 | bauzas | tobias-urdin: honestly, this is not a bug, right? | |
| 14:00:33 | bauzas | if the customer doesn't ask for a specific AZ, why should we only accept hosts within the same AZ ? | |
| 14:00:33 | bauzas | if the customer doesn't ask for a specific AZ, why should we only accept hosts within the same AZ ? | |
| 14:01:06 | bauzas | tobias-urdin: what you *could* tho is to provide a default AZ for instances | |
| 14:01:06 | tobias-urdin | because [cinder]/cross_az_attach=false and all instances is bfv :) | |
| 14:01:06 | bauzas | tobias-urdin: what you *could* tho is to provide a default AZ for instances | |
| 14:01:06 | tobias-urdin | because [cinder]/cross_az_attach=false and all instances is bfv :) | |
| 14:01:24 | bauzas | that's a config option | |
| 14:01:24 | bauzas | that's a config option | |
| 14:01:32 | tobias-urdin | so i guess somewhat of a bug but more i've built myself into a corner here | |
| 14:01:32 | tobias-urdin | so i guess somewhat of a bug but more i've built myself into a corner here | |
| 14:02:03 | bauzas | tobias-urdin: the problem is that cinder provided AZs too that are different from Nova and operators thought that we discussed in between Cinder and us :) | |
| 14:02:03 | bauzas | tobias-urdin: the problem is that cinder provided AZs too that are different from Nova and operators thought that we discussed in between Cinder and us :) | |
| 14:02:48 | bauzas | tobias-urdin: I could also say "please cross-attach AZs" | |
| 14:02:48 | bauzas | tobias-urdin: I could also say "please cross-attach AZs" | |
| 14:02:59 | bauzas | again, this is not a Nova bug | |
| 14:02:59 | bauzas | again, this is not a Nova bug | |
| 14:03:13 | bauzas | if Cinder wants to support Nova AZs, I understand this... | |
| 14:03:13 | bauzas | if Cinder wants to support Nova AZs, I understand this... | |
| 14:03:41 | bauzas | but if there are bugs with a cinder option, why Nova should fix it ? | |
| 14:03:41 | bauzas | but if there are bugs with a cinder option, why Nova should fix it ? | |
| 14:05:04 | tobias-urdin | it's a nova option, the problem is we don't have the same cinder storage backends in both AZs so we can't let nova create volumes in another AZ | |
| 14:05:04 | tobias-urdin | it's a nova option, the problem is we don't have the same cinder storage backends in both AZs so we can't let nova create volumes in another AZ | |
| 14:05:08 | tobias-urdin | (nova and cinder AZ are named the same) | |
| 14:05:08 | tobias-urdin | (nova and cinder AZ are named the same) | |
| 14:05:09 | bauzas | tobias-urdin: here, the thing is that you don't want to look at Nova AZs when resizing, but rather to Cinder AZs, right ? | |
| 14:05:09 | bauzas | tobias-urdin: here, the thing is that you don't want to look at Nova AZs when resizing, but rather to Cinder AZs, right ? | |
| 14:05:51 | tobias-urdin | hence can't let resize of server1 in az1 place server1 instance in az2 because cinder storage is not there | |
| 14:05:51 | tobias-urdin | hence can't let resize of server1 in az1 place server1 instance in az2 because cinder storage is not there | |
| 14:06:00 | bauzas | the problem is "I have a Cinder volume in a specific AZ, could you please, Nova, only give me a host that is within the same Cinder AZ" | |
| 14:06:00 | bauzas | the problem is "I have a Cinder volume in a specific AZ, could you please, Nova, only give me a host that is within the same Cinder AZ" | |
| 14:06:16 | bauzas | see the concern ? | |
| 14:06:16 | bauzas | see the concern ? | |
| 14:06:47 | bauzas | that's like "I have apples and bananas, I want to have the same banana than the appleé" | |
| 14:06:47 | bauzas | that's like "I have apples and bananas, I want to have the same banana than the appleé" | |
| 14:06:57 | bauzas | but Cinder and Nova AZs can be different | |
| 14:06:57 | bauzas | but Cinder and Nova AZs can be different | |
| 14:07:09 | bauzas | that's just the cinder config option that makes them related | |
| 14:07:09 | bauzas | that's just the cinder config option that makes them related | |
| 14:07:48 | bauzas | so, if we really want to restrict hosts that are in some AZs, that because they have volumes in the AZ | |
| 14:07:48 | bauzas | so, if we really want to restrict hosts that are in some AZs, that because they have volumes in the AZ | |