| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-05-04 | |||
| 06:48:16 | openstackgerrit | Wenping Song proposed openstack/nova-specs master: Trival change:Correct the link url https://review.opendev.org/c/openstack/nova-specs/+/789485 | |
| 08:02:06 | openstackgerrit | Tobias Urdin proposed openstack/nova master: Stop leaking ceph df cmd in RBD utils https://review.opendev.org/c/openstack/nova/+/789374 | |
| 13:39:38 | tobias-urdin | is there any way to ensure a resize of a instance doesn't get scheduled to another AZ? | |
| 13:39:38 | tobias-urdin | is there any way to ensure a resize of a instance doesn't get scheduled to another AZ? | |
| 13:39:57 | tobias-urdin | since the availability_zone property in the RequestSpec is None the AvailabilityZoneFilter will always pass through compute nodes | |
| 13:39:57 | tobias-urdin | since the availability_zone property in the RequestSpec is None the AvailabilityZoneFilter will always pass through compute nodes | |
| 13:40:12 | tobias-urdin | from all AZs and there is not really a way to make it honor the instances.availability_zone it already exists in | |
| 13:40:12 | tobias-urdin | from all AZs and there is not really a way to make it honor the instances.availability_zone it already exists in | |
| 13:41:14 | tobias-urdin | a real corner case im in here, since the instance is bfv (booted from a volume) and [cinder]/cross_az_attach is false I need nova resizes | |
| 13:41:14 | tobias-urdin | a real corner case im in here, since the instance is bfv (booted from a volume) and [cinder]/cross_az_attach is false I need nova resizes | |
| 13:41:19 | tobias-urdin | to honor not pushing them to another AZ | |
| 13:41:19 | tobias-urdin | to honor not pushing them to another AZ | |
| 13:42:38 | sean-k-mooney | tobias-urdin: by default it will stay in the same az i belive | |
| 13:42:38 | sean-k-mooney | tobias-urdin: by default it will stay in the same az i belive | |
| 13:43:22 | sean-k-mooney | if you set an az orginally then we will stay in the same az | |
| 13:43:22 | sean-k-mooney | if you set an az orginally then we will stay in the same az | |
| 13:43:37 | sean-k-mooney | if you did not specify one then yes i guess it could cross az | |
| 13:43:37 | sean-k-mooney | if you did not specify one then yes i guess it could cross az | |
| 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 | |