Earlier  
Posted Nick Remark
#openstack-nova - 2017-01-30
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 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

Earlier   Later