| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-15 | |||
| 16:11:15 | dansmith | bauzas: explain to me why it makes sense to boot an instance into az foo, land it in az bar, and then resize to foo? | |
| 16:12:01 | bauzas | it's not possible if you specified a AZ | |
| 16:12:06 | bauzas | dansmith: ^ | |
| 16:12:21 | dansmith | bauzas: so the reason to preserve the original request is to know if they didn't request one? | |
| 16:12:28 | bauzas | dansmith: the only case where you can be in foo and then bar is when you did *not* specify an AZ | |
| 16:12:41 | dansmith | right, so, I'm thinking.. | |
| 16:12:48 | dansmith | if I don't ask, I land in bar, | |
| 16:13:00 | dansmith | then I look in metadata, see bar, and boot one in foo to make sure I'm different, | |
| 16:13:15 | dansmith | making the first one resize and leave bar would be kinda bad no? | |
| 16:13:22 | rfolco | cdent, I actually was referring to 444497, if we needed to handle all possible/existing status_codes there. So, for this one you mean 409 test on gabbi ? | |
| 16:13:53 | cdent | yeah, inventory.yaml needs a test of the 409 cases when trying to delete inventories | |
| 16:14:19 | rfolco | cdent, gotcha, sorry for mixing things. | |
| 16:14:50 | cdent | no problem, the process is working. | |
| 16:15:02 | bauzas | dansmith: that's why when you nova show the instance, you're getting the original expressed AZ | |
| 16:15:25 | dansmith | bauzas: show from where, the rest api? | |
| 16:15:28 | bauzas | yeah | |
| 16:16:33 | dansmith | bauzas: okay but metadata will disagree | |
| 16:17:11 | bauzas | I wrote a stupid disclaimer explaining how I think AZs are currently broken in Nova https://docs.openstack.org/developer/nova/aggregates.html#availability-zones-azs | |
| 16:17:41 | dansmith | well, anyway, my point is, if we honor what the instance is currently in, or what was(n't) requested, I think we're fine | |
| 16:18:00 | bauzas | lemme consider that | |
| 16:18:18 | dansmith | I think if I didn't specify anything, then the cloud deciding to keep it in the same az is fine | |
| 16:18:27 | bauzas | as I said, the real nova thing which cares about AZs is the AZfilter | |
| 16:18:36 | bauzas | so, lemme look at the filter code | |
| 16:18:46 | dansmith | right, but presumably it is looking at what is in the reqspec, | |
| 16:18:50 | dansmith | which right now comes from instance.az | |
| 16:18:55 | bauzas | https://github.com/openstack/nova/blob/master/nova/scheduler/filters/availability_zone_filter.py#L47 | |
| 16:19:05 | bauzas | forget the specific line | |
| 16:19:13 | bauzas | it takes what's in the spec | |
| 16:19:19 | dansmith | right | |
| 16:19:34 | bauzas | and compares with if the host is in an aggregate | |
| 16:19:53 | bauzas | if not, it defaults to the conf opt | |
| 16:20:06 | bauzas | so | |
| 16:20:10 | bauzas | there are two things | |
| 16:20:28 | bauzas | which can make you stuck within a specific AZ | |
| 16:20:41 | bauzas | 1/ you specified an AZ in the boot command | |
| 16:20:53 | bauzas | in that case, we don't care whether instance.az is correct or not | |
| 16:21:09 | bauzas | because anyway, there is no way to get out of that AZ | |
| 16:21:19 | bauzas | so, I think it's harmless | |
| 16:21:29 | bauzas | now, I'm considering the other option | |
| 16:21:32 | openstackgerrit | Dan Smith proposed openstack/nova master: Get instance availability_zone without hitting the api db https://review.openstack.org/439754 | |
| 16:21:33 | openstackgerrit | Dan Smith proposed openstack/nova master: Make conductor ask scheduler to limit migrates to same cell https://review.openstack.org/438025 | |
| 16:21:33 | openstackgerrit | Dan Smith proposed openstack/nova master: Set instance.availability_zone whenever we schedule https://review.openstack.org/446053 | |
| 16:21:40 | dansmith | bauzas: ^ | |
| 16:21:52 | bauzas | 2/ you did not specify an AZ but the operator modified default_schedule_zone | |
| 16:22:12 | bauzas | in that case, you're stuck within an AZ | |
| 16:22:27 | mdbooth | dansmith: In functional, _do_post seems to create an instance which has an instance mapping with cell_mapping=None. What does that mean? | |
| 16:22:36 | dansmith | bauzas: sure but the default is to schedule into that az anyway right? | |
| 16:22:44 | bauzas | yeah | |
| 16:23:14 | dansmith | mdbooth: it means the instance is unscheduled | |
| 16:23:30 | mdbooth | So it's not in cell0 | |
| 16:23:35 | mdbooth | It's just not in any cell at all | |
| 16:23:56 | mdbooth | ? | |
| 16:24:08 | dansmith | being in cell0 means you were scheduled there | |
| 16:24:15 | mdbooth | Right, I thought so | |
| 16:24:20 | dansmith | being unscheduled means there is no instance record at all | |
| 16:29:34 | bauzas | dansmith: okay, I'm trying to keep things as simple as I can | |
| 16:30:01 | bauzas | dansmith: I think we're good having instance.az being set in the conductor | |
| 16:30:25 | bauzas | dansmith: but the problem is that we populate the Spec in the migrate method before calling the scheduler | |
| 16:31:15 | dansmith | bauzas: didn't we _just_ discuss why that's okay? | |
| 16:31:22 | dansmith | and the path to get out of that is you finishing your cleanup, if there's some reason for it | |
| 16:31:49 | mriedem | sfinucan: +W on the bottom one, i hit that yesterday | |
| 16:31:50 | mriedem | thanks | |
| 16:32:01 | bauzas | dansmith: well, it would mean that an instance having no AZ would be kept within that AZ | |
| 16:32:16 | dansmith | bauzas: which is by definition the default az anyway | |
| 16:32:32 | sfinucan | mriedem: (y) | |
| 16:32:32 | bauzas | dansmith: well, not exactly | |
| 16:32:59 | bauzas | dansmith: if I have a cloud with 999 nodes not in aggregates and one in one aggregate with metadata AZ foo | |
| 16:33:29 | bauzas | dansmith: then there are chances that instances can be booted on the single host part of foo | |
| 16:33:34 | bauzas | dansmith: which is okaty | |
| 16:34:11 | bauzas | dansmith: but then, a migrate would be only providing this host, compared to previously where it could return other hosts | |
| 16:34:42 | dansmith | bauzas: yeah, but.. again, the fix for that is finishing the reqspec cleanup right? | |
| 16:34:48 | bauzas | yup | |
| 16:35:03 | bauzas | I see your point | |
| 16:36:02 | dansmith | I don't think this is overly harmful if you're going to clean that bit up before the end of pike | |
| 16:39:17 | bauzas | dansmith: anyway, just reviewed your new change, you're updating instance.az after we regenerate the Spec, so it's all good | |
| 16:39:36 | dansmith | bauzas: no because we updated it on boot to the host we got to | |
| 16:39:42 | dansmith | bauzas: so resize will see that az | |
| 16:39:45 | bauzas | correct | |
| 16:39:54 | bauzas | nevermind the previous comment | |
| 16:40:19 | dansmith | bauzas: for this: https://review.openstack.org/#/c/442163/14/nova/availability_zones.py | |
| 16:40:34 | bauzas | yup ? | |
| 16:40:35 | dansmith | bauzas: I think I just want to make sure that the az thing calls the hostapi for listing services, | |
| 16:40:46 | dansmith | and then make sure I cover that method to ensure it iterates cells, okay? | |
| 16:40:49 | bauzas | yeah, like I said, I'm not opposed to merging this | |
| 16:41:26 | bauzas | I was just thinking of our test very not aware of cells | |
| 16:41:45 | bauzas | which could be a problem in the future given it's a DB-backed test case | |
| 16:41:55 | dansmith | I don't think it really needs to be, as long as it's getting the right service list, | |
| 16:42:01 | dansmith | but converting it is going to be somework | |
| 16:42:05 | bauzas | yeah | |
| 16:42:13 | bauzas | I'm turning my vote to +2 | |
| 16:42:33 | bauzas | I'm just reviewing the conductor change | |
| 16:42:52 | dansmith | a functional test might be easier for that anyway, since they already have multiple cells | |
| 16:50:26 | bauzas | dansmith: I agree, most of the AZ unittests could be done in the functional tree even | |
| 16:50:49 | mriedem | dansmith: are we doing a cells pow wow in 10 min? | |
| 16:51:25 | mriedem | i hope so because 3 days in working from home and i'm starting to get lonely | |
| 16:52:01 | dansmith | mriedem: oh yeah | |
| 16:52:10 | bauzas | mriedem: dansmith: I won't be able to attend it | |
| 16:52:18 | dansmith | mriedem: man, you're going to have a hard road ahead then :) | |
| 16:52:20 | dansmith | bauzas: ack | |
| 16:56:40 | dansmith | bauzas: hmm, the notification sample test is failing because I end up with None for my az instead of 'nova' | |