| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-30 | |||
| 18:24:47 | dansmith | mriedem: using it to tell that you're adding a mitaka compute to an ocata-only deployment isn't easy | |
| 18:25:19 | mriedem | adding? | |
| 18:25:44 | dansmith | checks in ocata to see if there are mitaka-level services could be done, but with a static version that would have to be updated over time | |
| 18:25:59 | dansmith | I haven't looked at the actual patch, I'm just commenting on using it to detect N-2 | |
| 18:27:39 | mriedem | ok my point was, at the time that 2c389ccc8c266175a71a29358bec7fe219e64fe0 (the newton change referenced in the commit message) was merged, the service version was 11. so in the ocata change that depends on that newton change, i'd think you could only do the ocata thing if the minimum nova-compute service version in the deployment was > 11 | |
| 18:28:06 | dansmith | sure, that's not N-2 though right? | |
| 18:28:10 | dansmith | that's what service_version is for | |
| 18:28:16 | mriedem | right | |
| 18:28:25 | openstackgerrit | Dan Smith proposed openstack/nova: Allow scheduler to run cell host discovery periodically https://review.openstack.org/426826 | |
| 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 | 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:41 | mriedem | pkoniszewski: ignore the earlier ping about https://bugs.launchpad.net/nova/+bug/1658877 - you didn't report that | |
| 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 verify_instance https://review.openstack.org/421436 | |
| 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:09 | openstackgerrit | Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 discover_hosts https://review.openstack.org/421442 | |
| 19:30:09 | openstackgerrit | Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 delete_cell https://review.openstack.org/421459 | |
| 19:30:10 | openstackgerrit | Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 create_cell https://review.openstack.org/421444 | |
| 19:30:10 | openstackgerrit | Diana Clarke proposed openstack/nova: nova-manage docs: cell_v2 list_cells https://review.openstack.org/421458 | |
| 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 | nvm | |
| 19:52:29 | mriedem | oh there is | |
| 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... | |