| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-15 | |||
| 15:43:56 | johnthetubaguy | heh, you should ask my wife, she is really picky about queues | |
| 15:45:01 | cdent | my recollection is that the use of "up" there is incorrect and would require a forfeit of some kind. Either running around the quad naked or having to get the next two rounds in, depending on your class. | |
| 15:46:31 | dansmith | bauzas: https://github.com/openstack/nova/blob/master/nova/conductor/tasks/migrate.py#L49-L55 | |
| 15:46:39 | dansmith | bauzas: that ignores the stored az I think :) | |
| 15:46:47 | bauzas | FWIW, using "queue" in French has a terrible meaning | |
| 15:47:32 | bauzas | dansmith: yet another reason to fix that then | |
| 15:47:41 | dansmith | yeah | |
| 15:47:52 | bauzas | those AZ issues are so fun | |
| 15:48:31 | bauzas | dansmith: FWIW, the only nova thing which cares about AZs is just the AZ filter | |
| 15:48:53 | bauzas | if you don't use it, that's just a nice but useless metadata | |
| 15:48:53 | openstack | Launchpad bug 1672624 in OpenStack Compute (nova) "Ceph volumes attached to local deleted instance could not be correctly handled" [Undecided,New] | |
| 15:48:53 | mdbooth | lyarwood johnthetubaguy: re https://bugs.launchpad.net/nova/+bug/1672624 if this were BZ I'd close it NOTABUG. | |
| 15:49:34 | mdbooth | But not because it's the operator's fault, just because it's an ephemeral fault outside Nova's control which will eventually resolve itself automatically. | |
| 15:50:02 | bauzas | dansmith: oh wait | |
| 15:50:20 | bauzas | dansmith: we need to keep the original AZ | |
| 15:50:23 | bauzas | for the Spec object | |
| 15:50:40 | bauzas | dansmith: ie. not having the Spec.az mentioning the "real" AZ | |
| 15:51:24 | dansmith | I'm not changing that | |
| 15:51:39 | bauzas | dansmith: but if you boot an instance, it will change instance.az | |
| 15:51:54 | dansmith | and when you finish the cleanup of the spec object usage, you'll get the original az at that point | |
| 15:52:35 | bauzas | yeah, we need to lookup the spec | |
| 15:52:45 | bauzas | not hydrating from the instance | |
| 15:52:55 | dansmith | bauzas: which is the cleanup step, no? | |
| 15:52:58 | dansmith | the TODO(bauzas) | |
| 15:53:03 | bauzas | yup | |
| 16:06:12 | openstackgerrit | Stephen Finucane proposed openstack/nova master: trivial: Remove \r\n line endings from JSON sample https://review.openstack.org/446040 | |
| 16:06:13 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Duplicate JSON line ending check to pep8 https://review.openstack.org/446041 | |
| 16:07:48 | cdent | rfolco: I don't think I'm understanding your question on the DELETE stuff: "Question: Do you think we need a test for 404 and another one for nop (where microversion matches) ?" | |
| 16:09:14 | sfinucan | Could I get someone to look at the above ^ Not possible to build docs locally while things remain this way | |
| 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: Set instance.availability_zone whenever we schedule https://review.openstack.org/446053 | |
| 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: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 | bauzas | dansmith: well, not exactly | |
| 16:32:32 | sfinucan | mriedem: (y) | |
| 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? | |