| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-07-26 | |||
| 20:50:40 | dansmith | oh, | |
| 20:50:45 | dansmith | the logic is reversed | |
| 20:51:52 | sdague | dansmith: oh, ok, that's hopeful | |
| 20:51:59 | sdague | so it just needs to be the other way around? | |
| 20:52:03 | dansmith | yeah | |
| 20:52:04 | dansmith | pushed a change and rechecked | |
| 20:52:05 | dansmith | yeah | |
| 20:52:12 | dansmith | because I was still in inverted flag mode in my brain head | |
| 20:52:15 | dansmith | jlvillal: ^ | |
| 20:52:23 | jlvillal | dansmith: Thanks! | |
| 20:53:24 | mriedem | sdague: shouldn't we see https://review.openstack.org/#/c/487458/ pass before approving the devstack change? | |
| 20:53:27 | sdague | dansmith: ok, I pre +Aed your new change. I'm going to be dropping off shortly for the day | |
| 20:54:03 | dansmith | okay | |
| 20:54:04 | sdague | mriedem: maybe, the question is whether anyone will be around to do that. | |
| 20:54:12 | mriedem | i guess we can proxy to mtreinish | |
| 20:54:20 | sdague | so, I can do this thing, and assuming life is good, it goes in. | |
| 20:54:28 | mriedem | yeah otherwise we'll bug mtreinish | |
| 20:54:31 | sdague | if things suck, just hit the rebase button | |
| 20:54:36 | sdague | to prevent it from landing | |
| 20:54:42 | dansmith | sdague: you can throw one of us on devstack core and pinky swear not to do anything else | |
| 20:55:02 | sdague | if anyone else wants to be devstack core, I'll sign you right up :) | |
| 20:55:07 | dansmith | haha | |
| 20:55:11 | mriedem | not it | |
| 20:55:15 | sdague | honestly mriedem if you want that bit you can have it | |
| 20:55:22 | sdague | you poke enough there | |
| 20:55:23 | dansmith | sounds less glamorous when you put it that way | |
| 20:55:26 | jlvillal | +1 for more devstack cores :) | |
| 20:58:28 | mriedem | here is the bug for the 500 on n-cpu startup with ironic https://bugs.launchpad.net/nova/+bug/1706772 | |
| 20:58:29 | openstack | Launchpad bug 1706772 in OpenStack Compute (nova) "InternalServerError: Internal Server Error (HTTP 500) in n-cpu logs on startup with Ironic driver" [High,Confirmed] | |
| 21:03:50 | openstackgerrit | Jay Pipes proposed openstack/nova master: claim resources in placement API during schedule() https://review.openstack.org/483566 | |
| 21:03:50 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: account for move operations in claim https://review.openstack.org/487589 | |
| 21:04:06 | jaypipes | dansmith, bauzas, mriedem: ^^ | |
| 21:05:04 | mriedem | looking | |
| 21:08:43 | mtreinish | mriedem: you need me to review something? | |
| 21:08:45 | melwitt | mriedem: do we not need a spec for adding new policy rules? I would have thought we do https://review.openstack.org/#/c/449288 | |
| 21:09:08 | mtreinish | I was just sitting in a corner inhaling lead fumes, but I can take a break from that | |
| 21:09:20 | melwitt | lol | |
| 21:09:20 | mriedem | mtreinish: not yet | |
| 21:10:06 | jaypipes | mtreinish: nice. :) | |
| 21:10:09 | mriedem | melwitt: it's not an api change so i don't think a spec is neeed | |
| 21:10:10 | mriedem | *needed | |
| 21:10:21 | mriedem | melwitt: plus i think we did one or more of these same granularity policy things in ocata, | |
| 21:10:32 | melwitt | mriedem: okay, cool. thanks, I learned a thing | |
| 21:10:34 | mriedem | the key is it must be backward compatible with an existing policy json i think | |
| 21:10:54 | mriedem | so an operator would need to opt into the more granular rules | |
| 21:11:19 | melwitt | right. I think they are taking care of that in the patch | |
| 21:11:23 | melwitt | cool | |
| 21:15:06 | openstackgerrit | melanie witt proposed openstack/nova master: deprecate ``wsgi_log_format`` config variable https://review.openstack.org/486623 | |
| 21:24:33 | bauzas | jaypipes: just a question about https://review.openstack.org/#/c/487589/1/nova/scheduler/client/report.py | |
| 21:25:15 | bauzas | jaypipes: when we self-heal by the RT, we remove allocations that are not related to the existing instances, right? | |
| 21:25:34 | mriedem | jaypipes: issues in https://review.openstack.org/#/c/487589 | |
| 21:27:39 | dansmith | bauzas: that's what I said in my comment | |
| 21:27:48 | jaypipes | bauzas: when the move_claim() completes on the destination host, it will overwrite the allocations to only be the ones on the destination host, yes. I think that's what you're asking? | |
| 21:27:58 | jaypipes | mriedem: blasted? | |
| 21:28:10 | dansmith | jaypipes: no | |
| 21:28:26 | dansmith | jaypipes: he's asking about regular RT healing on the source node while the migration is going on, erasing the double claim | |
| 21:28:57 | bauzas | dansmith: my question is about if either the source or the target RT removes the allocations for the moving instance given the instance.host is not related to it | |
| 21:29:00 | dansmith | jaypipes: which was in my comment about the plan.. we need to make sure we don't heal over that | |
| 21:29:10 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Set Adapter interface defaults in conf https://review.openstack.org/487581 | |
| 21:29:14 | dansmith | bauzas: instance.host will be related to the source until it completes | |
| 21:29:21 | dansmith | bauzas: and it would remove the double claim once it runs | |
| 21:29:28 | bauzas | dansmith: that's my question | |
| 21:29:33 | dansmith | right | |
| 21:29:56 | mriedem | jaypipes: with questions | |
| 21:30:05 | bauzas | dansmith: because if instance.host is set to the source host, wouldn't the target RT removing the allocations for the target host ? | |
| 21:30:18 | dansmith | again, yes | |
| 21:31:16 | edleafe | mriedem: regarding https://bugs.launchpad.net/nova/+bug/1706772 - if we catch that and move on, the flavors will never migrate. What's the alternative? | |
| 21:31:17 | openstack | Launchpad bug 1706772 in OpenStack Compute (nova) "InternalServerError: Internal Server Error (HTTP 500) in n-cpu logs on startup with Ironic driver" [High,Confirmed] | |
| 21:31:21 | jaypipes | dansmith: do you want me to put something in the RT's update_available_resource() method that basically says "oh, this is migrating? fuck it, don't touch placement"? | |
| 21:31:32 | dansmith | jaypipes: we have to do something yeah | |
| 21:31:45 | mriedem | i had a comment in the patch related to this: "when the move_claim() completes on the destination host, it will overwrite the allocations to only be the ones on the destination host, yes. " | |
| 21:31:49 | bauzas | dansmith: sorry, I misunderstood your comment, I thought you were saying it wasn't a problem | |
| 21:31:51 | jaypipes | dansmith: we already jump through a shit-ton of hoops for move operations in the RT... | |
| 21:31:54 | jaypipes | what's one more... | |
| 21:32:04 | dansmith | jaypipes: well, it's either correct or it's not... | |
| 21:32:13 | mriedem | is PUT /allocations/<intsance uuid> completely overwriting the allocations for that instance? | |
| 21:32:21 | dansmith | mriedem: yes | |
| 21:32:23 | bauzas | mriedem: that is correct AFAIK | |
| 21:32:24 | jaypipes | dansmith: no, for move operations the definition of "correct" is fuzzy. | |
| 21:32:34 | dansmith | jaypipes: I disagree :) | |
| 21:33:18 | mriedem | ah i see | |
| 21:35:44 | mriedem | so this works the same if you're doing a resize and revert back to the source host i think | |
| 21:36:17 | jaypipes | I'm wondering if instances that are migrating are in RT.tracked_instances... | |
| 21:36:22 | jaypipes | if they aren't, we're good. | |
| 21:36:42 | dansmith | jaypipes: well, the existing RT stuff is not even correct, as you know | |
| 21:36:49 | bauzas | jaypipes: well, I don't think so | |
| 21:37:07 | bauzas | jaypipes: IIRC, tracked_instances is for existing instances | |
| 21:37:13 | dansmith | jaypipes: if you have the instance, you should be able to check instance.migration_context to know if it's moving | |
| 21:37:15 | bauzas | not for migrating ones | |
| 21:37:23 | jaypipes | ok, guys, I think we're good... | |
| 21:37:25 | dansmith | bauzas: for migrating ones on the source they should be there right? | |
| 21:37:26 | jaypipes | lemme explain. | |
| 21:37:27 | jaypipes | pls. | |
| 21:37:51 | bauzas | dansmith: for the source RT, yeah they should be there AFAIK | |
| 21:38:01 | dansmith | bauzas: right, destination node does not matter | |
| 21:38:05 | jaypipes | so, in update_available_resource(), we call _update_usage_from_instance(). this is the "auto-heal" thing. | |
| 21:38:13 | bauzas | correct | |
| 21:38:35 | jaypipes | within that method, we only delete the allocation if the instance is in DELETED or SHELVE_OFFLOADED state | |
| 21:38:40 | bauzas | the problem is how we could possibly have duplicate allocations for both target and source if source just removes the target allocations ? | |
| 21:38:47 | jaypipes | otherwise we don't touch the allocations. | |