| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-05-04 | |||
| 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 | |
| 14:08:21 | bauzas | honestly, instead of having different AZs between nova and cinder, the cinder-scheduler should look at Nova AZs | |
| 14:08:21 | bauzas | honestly, instead of having different AZs between nova and cinder, the cinder-scheduler should look at Nova AZs | |
| 14:08:34 | bauzas | (hint : placement can help) | |
| 14:08:34 | bauzas | (hint : placement can help) | |
| 14:09:47 | tobias-urdin | yeah - as I said, it's a messy case. Since spawning new ones works fine because nova when creating volumes will honor cross_az_attach https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L53 | |
| 14:09:47 | tobias-urdin | yeah - as I said, it's a messy case. Since spawning new ones works fine because nova when creating volumes will honor cross_az_attach https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L53 | |
| 14:10:16 | tobias-urdin | it just don't care on resize and can select compute node in az2 that cannot access storage in az1 for example | |
| 14:10:16 | tobias-urdin | it just don't care on resize and can select compute node in az2 that cannot access storage in az1 for example | |
| 14:12:40 | tobias-urdin | consider this 1) you have a cloud with one az, nothing much to care about you spawn a instance requestspec gets availability_zone=None you are happy 2) you add a availability zone for nova and cinder same name, you set nova.conf cross_az_attach=false because compute nodes in az1 is not addressed on storage network for az2 | |
| 14:12:40 | tobias-urdin | consider this 1) you have a cloud with one az, nothing much to care about you spawn a instance requestspec gets availability_zone=None you are happy 2) you add a availability zone for nova and cinder same name, you set nova.conf cross_az_attach=false because compute nodes in az1 is not addressed on storage network for az2 | |
| 14:13:14 | tobias-urdin | now you try to resize a instance created before that has requestspec availability_zone=None it will still try to select a compute node in az2 since it doesn't care about not attaching across AZs | |
| 14:13:14 | tobias-urdin | now you try to resize a instance created before that has requestspec availability_zone=None it will still try to select a compute node in az2 since it doesn't care about not attaching across AZs | |
| 14:13:54 | tobias-urdin | my only point, it only cares about handling that volume connection upon creation, everything else is just not implemented, nothing more so i'll dig a see what i can figure out :) | |
| 14:13:54 | tobias-urdin | my only point, it only cares about handling that volume connection upon creation, everything else is just not implemented, nothing more so i'll dig a see what i can figure out :) | |
| 14:16:52 | bauzas | tobias-urdin: again, I understand your problem, as I said, I'm not happy that cinder provided this option without thinking about move operations | |
| 14:16:52 | bauzas | tobias-urdin: again, I understand your problem, as I said, I'm not happy that cinder provided this option without thinking about move operations | |
| 14:17:10 | tobias-urdin | agree | |
| 14:17:10 | tobias-urdin | agree | |
| 14:17:27 | tobias-urdin | thanks for clearing things up, was a little bit confused but i understand the issues atleast | |
| 14:17:27 | tobias-urdin | thanks for clearing things up, was a little bit confused but i understand the issues atleast | |
| 14:17:43 | bauzas | fixing this would need us to discuss between nova and cinder to see what to do | |
| 14:17:43 | bauzas | fixing this would need us to discuss between nova and cinder to see what to do | |
| 14:18:15 | bauzas | but I wouldn't be happy with only nova fixing this because of cinder | |
| 14:18:15 | bauzas | but I wouldn't be happy with only nova fixing this because of cinder | |
| 14:18:44 | bauzas | and now we have placement, maybe we should discuss how to provide a query that would ask for this | |
| 14:18:44 | bauzas | and now we have placement, maybe we should discuss how to provide a query that would ask for this | |
| 14:19:11 | bauzas | that's a huge feature and this shouldn't be backported | |
| 14:19:11 | bauzas | that's a huge feature and this shouldn't be backported | |
| 14:19:33 | bauzas | for example, I could imagine some way to map between Nova and Cinder AZs | |
| 14:19:33 | bauzas | for example, I could imagine some way to map between Nova and Cinder AZs | |
| 14:19:44 | bauzas | one Nova AZ could map to say 3 Cinder AZs | |
| 14:19:44 | bauzas | one Nova AZ could map to say 3 Cinder AZs | |
| 14:20:10 | bauzas | and then you could write a query saying "I want my instance to use Cinder AZs" | |
| 14:20:10 | bauzas | and then you could write a query saying "I want my instance to use Cinder AZs" | |
| 14:20:34 | bauzas | if so, when resizing, we could continue to look at placement for knowing the existing AZ | |
| 14:20:34 | bauzas | if so, when resizing, we could continue to look at placement for knowing the existing AZ | |
| 14:20:39 | bauzas | AZs even | |
| 14:20:39 | bauzas | AZs even | |
| 14:22:36 | sean-k-mooney | bauzas: im not sure that is true | |
| 14:22:36 | sean-k-mooney | bauzas: im not sure that is true | |
| 14:22:54 | sean-k-mooney | i dont think one nova AZ can map to multiplle cinder AZs | |
| 14:22:54 | sean-k-mooney | i dont think one nova AZ can map to multiplle cinder AZs | |
| 14:23:15 | sean-k-mooney | i think all our assumtion for schduling is tthat there is a 1:1 mapping | |
| 14:23:15 | sean-k-mooney | i think all our assumtion for schduling is tthat there is a 1:1 mapping | |