| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-05-04 | |||
| 13:43:54 | sean-k-mooney | we could adress this with an az weigher i guess | |
| 13:43:54 | sean-k-mooney | we could adress this with an az weigher i guess | |
| 13:44:11 | sean-k-mooney | prioritiseing the same az if in the candiate set | |
| 13:44:11 | sean-k-mooney | prioritiseing the same az if in the candiate set | |
| 13:48:27 | bauzas | tobias-urdin: if you created an instance without asking for a specific AZ, then the scheduler will support *all* the AZs | |
| 13:48:27 | bauzas | tobias-urdin: if you created an instance without asking for a specific AZ, then the scheduler will support *all* the AZs | |
| 13:49:16 | sean-k-mooney | bauzas: ya i think what tobias-urdin was hoping for was a way to populate the requst spec after the fact with the AZ the vm landed in | |
| 13:49:16 | sean-k-mooney | bauzas: ya i think what tobias-urdin was hoping for was a way to populate the requst spec after the fact with the AZ the vm landed in | |
| 13:49:18 | tobias-urdin | hm ok, what attribute determines that in the database? | |
| 13:49:18 | bauzas | tobias-urdin: but if you provide a specific AZ when you create the instance, then the instance will only be moving to the hosts in the same AZ | |
| 13:49:18 | tobias-urdin | hm ok, what attribute determines that in the database? | |
| 13:49:18 | bauzas | tobias-urdin: but if you provide a specific AZ when you create the instance, then the instance will only be moving to the hosts in the same AZ | |
| 13:49:23 | sean-k-mooney | so that future moves would be in the same az | |
| 13:49:23 | sean-k-mooney | so that future moves would be in the same az | |
| 13:49:33 | bauzas | tobias-urdin: don't modify the DB | |
| 13:49:33 | bauzas | tobias-urdin: don't modify the DB | |
| 13:50:07 | bauzas | because you would change the behaviour | |
| 13:50:07 | bauzas | because you would change the behaviour | |
| 13:50:40 | tobias-urdin | yes, but I want to understand what is selected | |
| 13:50:40 | tobias-urdin | yes, but I want to understand what is selected | |
| 13:50:59 | sean-k-mooney | its the value in the request spec that is used | |
| 13:50:59 | sean-k-mooney | its the value in the request spec that is used | |
| 13:51:07 | sean-k-mooney | for schudling | |
| 13:51:07 | sean-k-mooney | for schudling | |
| 13:51:09 | bauzas | tobias-urdin: the filter looks at the instance RequestSpec value | |
| 13:51:09 | bauzas | tobias-urdin: the filter looks at the instance RequestSpec value | |
| 13:51:15 | sean-k-mooney | but its stored in sojme other places too | |
| 13:51:15 | sean-k-mooney | but its stored in sojme other places too | |
| 13:51:21 | bauzas | exactly | |
| 13:51:21 | bauzas | exactly | |
| 13:51:48 | sean-k-mooney | for exampel we add the AZ to the neutron port in the device_owner filed i belive | |
| 13:51:48 | sean-k-mooney | for exampel we add the AZ to the neutron port in the device_owner filed i belive | |
| 13:52:03 | sean-k-mooney | its proably in the cinder attaments somewhere | |
| 13:52:03 | sean-k-mooney | its proably in the cinder attaments somewhere | |
| 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 :) | |