Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-26
20:58:49 dansmith since we've changed it like a hundred times already
20:59:38 mriedem oh i see
20:59:40 mriedem yeah that's fair
20:59:40 jaypipes dansmith: it's dependent on mriedem's https://review.openstack.org/#/c/513931 anyway.
20:59:58 mriedem mine is actually fixing a perf thing, but yeah
21:00:05 mriedem jaypipes: maybe we convert to +1s
21:00:09 dansmith jaypipes: sure but that one is easy to merge ahead of all the rest
21:00:20 jaypipes dansmith: I removed the +W
21:00:33 mriedem changed to +1
21:00:37 dansmith jaypipes: thanks
21:00:40 mriedem maybe we need to put a -2 pin in there?
21:00:47 mriedem there are other cores that aren't privy to this convo
21:01:04 dansmith that's fine
21:01:13 mriedem shit meeting itme
21:10:47 openstackgerrit Jay Pipes proposed openstack/nova master: rp: Remove RP.get_traits() method https://review.openstack.org/509027
21:11:03 openstackgerrit Jay Pipes proposed openstack/nova master: rp: move RP._set_traits() to module scope https://review.openstack.org/509028
21:11:12 openstackgerrit Jay Pipes proposed openstack/nova master: rp: remove _HasAResourceProvider mixin https://review.openstack.org/509036
21:11:20 openstackgerrit Jay Pipes proposed openstack/nova master: rp: break functions out of _set_traits() https://review.openstack.org/509908
21:18:44 melwitt does anyone happen to know what's going bonkers in the legacy-grenade-dsvm-neutron-multinode-live-migration job failing what seems like all the time? http://logs.openstack.org/31/513931/3/check/legacy-grenade-dsvm-neutron-multinode-live-migration/a5f4740/logs/testr_results.html.gz
21:18:54 mriedem melwitt: yes
21:19:20 mriedem https://review.openstack.org/#/c/508271/
21:19:23 mriedem it's mfing ceph
21:19:23 mriedem again
21:19:28 mriedem + superconductor
21:19:46 mriedem i pleaded for help in last week's meeting but to no avail
21:19:56 mriedem sdague is probably able to sort that one out easily
21:19:58 mriedem if i say his name enough
21:20:00 mriedem sdague:
21:20:34 melwitt oh :( I'll try to look at it too. I didn't notice it in the meeting notes (my fault)
21:20:51 mriedem we need to be able to source the local.conf
21:20:56 mriedem created via grenade
21:21:01 mriedem to know if we're doing superconductor or not
21:21:41 melwitt oh, hrm
21:21:42 mriedem this might just be easier to do: if [ -f /etc/nova/nova-cpu.conf ]; then
21:21:46 mriedem hacky but it would work
21:21:57 mriedem if ^ then superconductor, else singleconductor
21:22:27 melwitt do we not already have some kind of logic about superconductor vs singleconductor? I mean, how is the decision made in the first place
21:22:35 melwitt just "if grenade, then"?
21:22:47 mriedem grenade forces singleconductor mode
21:23:00 mriedem the CELLSV2_SETUP flag goes into local.conf
21:23:05 mriedem which is what i'm trying to source here
21:23:09 mriedem but don't have permission apparently
21:23:11 melwitt okay. so things downstream of that need to be able to determine what mode it's in
21:23:15 mriedem yup
21:23:49 mriedem i think when this post_test_hook runs, all we have for variables is what devstack-gate gives us
21:23:58 mriedem which is why $GRENADE_OLD_BRANCH works
21:27:03 melwitt I wonder if we could check for the presence of the n-super-cond service? or is that not a thing hooks can do
21:27:24 mriedem it's running on the dest node so i think that's possible
21:27:30 mriedem can try that quick
21:27:32 melwitt is_service_enabled n-super-cond
21:27:36 mriedem yeah
21:28:07 mriedem let me wrap up what i'm currently fixing
21:28:21 mriedem dansmith: btw, i've been thinking,
21:28:21 melwitt k
21:28:40 mriedem it would be really nice if we had an online_data_migration that found all of your old instances that don't have request_specs,
21:28:56 openstackgerrit Eric Fried proposed openstack/nova master: Parse granular resources/traits from extra_specs https://review.openstack.org/515151
21:28:59 mriedem built a request spec for them - like we do EVERYWHERE in the api and conductor, and then we just burned all of that backward compat code out in a later release
21:29:03 openstackgerrit Eric Fried proposed openstack/nova master: Granularize resources_from_{flavor|request_spec} https://review.openstack.org/515223
21:29:07 dansmith I thought we did?
21:29:29 mriedem migrate_instances_add_request_spec
21:29:30 mriedem heh
21:29:52 mriedem shit yup we sure do
21:30:04 mriedem doesn't have the original filter properties in it, but...
21:30:19 mriedem ok so migrate_instances_add_request_spec was added in newton,
21:30:39 mriedem does that mean that soon once newton eol, we can drop that online data migration and say, that's it
21:30:42 mriedem we drop the old compat code
21:31:06 mriedem i mean, if you skip this and go from mitaka to queens, it's your fault
21:31:33 dansmith normally we'd have a blocker migration, but yeah I think it's prolly safe at this point
21:31:49 mriedem blocker migration would be tricky,
21:32:02 mriedem since reqspecs are in the api db
21:32:18 mriedem i guess the blocker could be in the api db migratoin scripts, lookup the instances in the instance_mappings table and compare those to the reqspecs table?
21:32:59 dansmith we've done that haven't we? regardless, prolly not worth it at this point
21:46:24 mriedem we have quite a few online data migrations from newton actually
21:46:45 mriedem 6
21:47:23 openstackgerrit Matt Riedemann proposed openstack/nova master: Pass the correct image to build_request_spec in conductor.rebuild_instance https://review.openstack.org/515530
21:49:30 openstackgerrit Matt Riedemann proposed openstack/nova master: Pass the correct image to build_request_spec in conductor.rebuild_instance https://review.openstack.org/515530
21:53:43 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix live migration grenade ceph setup https://review.openstack.org/508271
21:53:44 mriedem melwitt: ^
21:54:37 melwitt I shall stalk it on zuul status
22:15:57 mriedem melwitt: i have a question in the commit message here https://review.openstack.org/#/c/514339/
22:16:06 mriedem don't know what "Wrongly set the cache mode for Ceph storage backend to be 'none', while it should be set to 'writeback' to extract optimal performance." is referring to
22:16:17 mriedem the libvirt volume net driver doesn't set driver_cache in conf at all
22:16:44 mriedem maybe that's some rhosp special sauce ?!
22:16:53 melwitt mriedem: that's not really relevant I don't think. I was hesitant to change/remove too much from a commit message I didn't write, but kashyap is away at kvm forum
22:17:27 melwitt I think the thing that's wrong that's happening is libvirt driver isn't honoring the nova.conf setting for disk_cachemodes and there's nothing automatic about ceph there
22:18:35 mriedem hmm, maybe it comes from the rbd image backend via image properties or something, idk
22:18:46 melwitt just depends on how the nova.conf is deployed, I'm guessing our deployment tooling sets nova.conf that way for ceph or something
22:18:49 mriedem but it's confusing in the commit message b/c there is no code in nova that defaults the cache_mode for rbd disks to writethrough
22:19:21 melwitt yeah, I was torn about whether to hack up the commit message because I agree it's confusing
22:19:50 mriedem ok i'd -1
22:21:44 mriedem i'll just mod the commit inline and +W
22:22:58 openstackgerrit Matt Riedemann proposed openstack/nova master: libvirt: Don't disregard cache mode for instance boot disks https://review.openstack.org/514339
22:23:13 melwitt mriedem: okay. to your question about the disk_cachemodes, yes, the _set_cache_mode function takes the setting from the CONF.libvirt.disk_cachemodes and applies it
22:23:19 mriedem yup
22:23:49 melwitt k, thanks for updating the commit message
22:24:01 mriedem oh wait maybe it's this _supports_direct_io method
22:24:05 mriedem def disk_cachemode(self):
22:24:29 mriedem which sends the cache mode into the rbd imagebackend
22:24:33 mriedem maybe that's what he meant
22:27:03 mriedem yeah so maybe that's what it was

Earlier   Later