| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-30 | |||
| 18:29:06 | mriedem | i'm confusing things. the n-2 question was really about an assumption made in that code that if we land this ocata patch, it means nothing is running n-2 mitaka code, which i'm saying we can't assume, and can figure out using service versions | |
| 18:29:29 | openstackgerrit | Chris Dent proposed openstack/nova: Add placement request id to log when GET aggregates https://review.openstack.org/426874 | |
| 18:30:06 | dansmith | okay | |
| 18:40:41 | mriedem | pkoniszewski: ignore the earlier ping about https://bugs.launchpad.net/nova/+bug/1658877 - you didn't report that | |
| 18:40:41 | openstack | Launchpad bug 1658877 in OpenStack Compute (nova) "live migration failed with XenServer as hypervisor" [High,In progress] - Assigned to Bob Ball (bob-ball) | |
| 18:40:44 | edleafe | jaypipes: reviewing now | |
| 18:40:52 | mriedem | BobBall: on ^ it's not a specific nova change that regressed this right? | |
| 18:41:04 | mriedem | BobBall: it's just that nova doesn't support xenserver 7? | |
| 18:41:33 | mriedem | i'm not sure what "1) the change in network name" means | |
| 18:52:46 | mriedem | diana_clarke: suggestion on wording in https://review.openstack.org/#/c/422171/ | |
| 18:53:13 | diana_clarke | mriedem: looking. I'm over here struggling with english wording too. | |
| 18:58:18 | diana_clarke | mriedem: oh that... yeah. I remember trying to come up with something better but was really mostly just concerned with not lying about return values. | |
| 19:08:54 | openstackgerrit | Dan Smith proposed openstack/nova: Allow scheduler to run cell host discovery periodically https://review.openstack.org/426826 | |
| 19:10:14 | zer0c00l | The _heal_instance_info_cache is just going to heal the first instance on the list, https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L5881 | |
| 19:10:23 | zer0c00l | Is that the right behaviour of this method? | |
| 19:11:02 | zer0c00l | It loops through instance_uuids, picks up the healable instance and breaks out of that loop | |
| 19:11:29 | zer0c00l | which means only first healable instance will get its info cache refreshed | |
| 19:11:41 | zer0c00l | Am i missing something? | |
| 19:12:18 | dansmith | zer0c00l: the next time it runs it uses the list it made, until the list is empty, then gets a new list | |
| 19:12:21 | dansmith | i.e. one heal per cycle | |
| 19:12:54 | zer0c00l | dansmith: i see, so one heal per cycle is by design | |
| 19:13:00 | dansmith | yes | |
| 19:13:26 | zer0c00l | dansmith: we have the interval set to 1800 in our production, so for us it takes forever | |
| 19:13:38 | zer0c00l | i guess i will have to reduce that number to something sane | |
| 19:13:40 | mriedem | zer0c00l: so change your interval | |
| 19:13:43 | zer0c00l | yes | |
| 19:13:45 | zer0c00l | thanks | |
| 19:13:47 | dansmith | zer0c00l: the healing really shouldn't need to happen anyway, but yeah | |
| 19:13:48 | mriedem | default is 60 seocnds | |
| 19:13:51 | dansmith | it's supposed to be slow | |
| 19:13:52 | mriedem | *seconds | |
| 19:14:03 | zer0c00l | okay | |
| 19:14:05 | mriedem | oh wait maybe it's different for that one | |
| 19:14:39 | mriedem | i guess it's 60 http://docs.openstack.org/newton/config-reference/compute/config-options.html | |
| 19:18:05 | mriedem | artom: the fact that the DeviceTaggingTest test in tempest is setup with a max of 2.latest is really confusing | |
| 19:18:09 | mriedem | in that it still works | |
| 19:19:41 | artom | mriedem, indeed... | |
| 19:20:04 | artom | I can only assume Tempest doesn't use the max microversion when actually sending the request | |
| 19:20:18 | artom | (But does use to check what tests to run) | |
| 19:20:42 | mriedem | yeah it uses 2.32 http://logs.openstack.org/51/421251/13/check/gate-tempest-dsvm-neutron-full-ssh/60bb925/logs/tempest.txt.gz#_2017-01-30_15_19_16_672 | |
| 19:21:50 | mriedem | in newton, max_microversion is capped for compute to 2.38 http://logs.openstack.org/51/421251/13/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial-newton/7071652/logs/tempest_conf.txt.gz | |
| 19:22:40 | mriedem | but it still looks like tempest just uses the min | |
| 19:22:48 | mriedem | e.g. 2.37 here http://logs.openstack.org/51/421251/13/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial-newton/7071652/logs/tempest.txt.gz#_2017-01-30_15_29_23_670 | |
| 19:23:25 | artom | That can be something we propose to Tempest - to use the max instead of the min | |
| 19:26:02 | openstackgerrit | Dan Smith proposed openstack/nova: Allow scheduler to run cell host discovery periodically https://review.openstack.org/426826 | |
| 19:27:47 | mriedem | "which re-adds the tag in all the right places." heh | |
| 19:27:57 | mriedem | that makes me think dirty thoughts for some reason | |
| 19:28:45 | artom | mriedem, gooood...? | |
| 19:29:38 | artom | At least I didn't word it about reinserting the missing (dict) member | |
| 19:29:40 | mriedem | actually it makes me think of this https://www.youtube.com/watch?v=FAyDmJvjxbg | |
| 19:30:05 | mriedem | is there anyway we can talk about a bag of dicts? | |
| 19:30:08 | openstackgerrit | Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 map_cell_and_hosts https://review.openstack.org/421420 | |
| 19:30:08 | openstackgerrit | Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 verify_instance https://review.openstack.org/421436 | |
| 19:30:09 | openstackgerrit | Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 delete_cell https://review.openstack.org/421459 | |
| 19:30:09 | openstackgerrit | Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 discover_hosts https://review.openstack.org/421442 | |
| 19:30:10 | openstackgerrit | Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 list_cells https://review.openstack.org/421458 | |
| 19:30:10 | openstackgerrit | Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 create_cell https://review.openstack.org/421444 | |
| 19:30:59 | artom | We could conceivable describe the request body as a bad of dicts | |
| 19:42:13 | mriedem | ooo i see abug | |
| 19:46:38 | mriedem | artom: comments in https://review.openstack.org/#/c/424759/ | |
| 19:46:58 | mriedem | artom: the -1 is for https://review.openstack.org/#/c/424759/9/nova/api/openstack/compute/schemas/servers.py@31 for sure | |
| 19:47:41 | artom | mriedem, "If we need further clarification we have this I guess..." oy with the sarcasm ;) | |
| 19:47:51 | mriedem | well, | |
| 19:47:57 | mriedem | not trying to be sarcastic, | |
| 19:48:00 | mriedem | if you look at the api-ref | |
| 19:48:06 | artom | Heh, you are right though | |
| 19:48:24 | mriedem | look at the description for networks.tag here http://developer.openstack.org/api-ref/compute/?expanded=create-server-detail#id7 | |
| 19:48:30 | artom | I think I was trying to be generic, because... reasons, I guess? | |
| 19:48:34 | mriedem | and block_device_mapping_v2.tag | |
| 19:48:53 | mriedem | generic is fine, and what you have in the api-ref is good | |
| 19:49:01 | mriedem | i'm on the fence about over documenting this to death | |
| 19:49:56 | artom | Surely more docs is better? | |
| 19:50:03 | mriedem | probably | |
| 19:50:25 | mriedem | you might want to make those specific parameter types then though | |
| 19:50:41 | artom | What would we gain by mentioning it less? Someone's bound to run into this, we might as well make the explanation of wtf happened as accessible as possible | |
| 19:50:52 | mriedem | so for device_network_tag you just make the comment about 2.32-2.36, and for device_bdm_tag you make the comment about 2.32 | |
| 19:51:12 | mriedem | know what i mean? | |
| 19:51:24 | artom | Aha, and then set the correct min and max version on each | |
| 19:51:27 | mriedem | yeah | |
| 19:51:28 | artom | Yep, I agree | |
| 19:51:31 | mriedem | since device_tag is used for both right now | |
| 19:51:39 | artom | Well | |
| 19:51:46 | artom | min, max, and min again | |
| 19:51:51 | artom | If I can manage that | |
| 19:52:02 | mriedem | fwiw i don't know if the sphinx plugin supports a max_version | |
| 19:52:19 | mriedem | sdague: do you know if there is a max_version for https://review.openstack.org/#/c/424759/9/api-ref/source/parameters.yaml@1506 ? | |
| 19:52:29 | mriedem | oh there is | |
| 19:52:29 | mriedem | nvm | |
| 19:52:45 | mriedem | artom: i don't think you can do min and max and then min again | |
| 19:53:04 | mriedem | so probably just min-version: 2.32, and then notes in the description about the snafu between 2.32 and 2.42 | |
| 19:54:09 | artom | mriedem, maybe if I split it again into nic_tag_2.32-2.37 and another one... | |
| 19:54:14 | artom | Worth it? | |
| 19:54:26 | mriedem | then we have the same parameter listed in the table twice | |
| 19:54:33 | artom | Or will it just be more confusing then writing it in English words | |
| 19:54:39 | artom | *than | |
| 19:54:48 | mriedem | i think english be gooder | |
| 19:55:01 | mriedem | sorry, *me think* | |
| 20:04:10 | artom | The schema deepcopy thing is a minefield :( | |
| 20:04:31 | artom | You caught the network uuid checking, presumably because you wrote 2.37 yourself | |
| 20:04:49 | mriedem | artom: exactly | |