Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-10-26
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 melwitt k
21:28:21 mriedem dansmith: btw, i've been thinking,
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
22:28:00 melwitt I dunno, in the ceph case the high perf value is writeback, not writethrough
22:30:58 openstackgerrit Matt Riedemann proposed openstack/nova master: libvirt: Don't disregard cache mode for instance boot disks https://review.openstack.org/514339
22:31:49 mriedem done, approved
22:31:54 mriedem melwitt: want to start the backport party?
22:32:02 mriedem then dansmith and i can +W those
22:32:40 melwitt mriedem: yep, on it
22:32:45 mriedem cool, thanks
22:35:32 openstackgerrit melanie witt proposed openstack/nova stable/pike: libvirt: Don't disregard cache mode for instance boot disks https://review.openstack.org/515538
22:41:09 openstackgerrit Matt Riedemann proposed openstack/nova master: Cleanup build_request_spec https://review.openstack.org/515539
22:41:13 melwitt mriedem: are we supposed to leave multiple cherry-pick comments in the commit message? I can't remember
22:41:28 mriedem melwitt: not a big deal
22:41:31 melwitt like if I cherry picked from pike to ocata. okay
22:41:44 mriedem if you are then just leave them in there
22:41:58 melwitt ack
22:42:45 tonyb melwitt: It makes things slightly easier but really it only helps if your first cherry-pick had fixups that you don't want to do a second time.
22:43:03 tonyb melwitt: my tools work with either scenario
22:43:24 mriedem heh, tony's special stable tools
22:43:27 melwitt okay, cool. I started doing it this way after I think dansmith pointed out maybe less likely to hit conflicts this way
22:43:45 tonyb melwitt: cool
22:43:56 tonyb mriedem: FWIW I
22:44:07 openstackgerrit melanie witt proposed openstack/nova stable/ocata: libvirt: Don't disregard cache mode for instance boot disks https://review.openstack.org/515540
22:44:24 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Add microversion to allow setting flavor description https://review.openstack.org/515213
22:44:41 tonyb 'll probably wait for your +2 and the +2W them even thought they haven't actually landed on "upper" branches
22:44:52 tonyb mriedem: they're "magic tools" not special ;P
22:45:25 mriedem oh sorry
22:45:31 mriedem so like rabbits in hats
22:45:36 mriedem coins behind ears
22:45:38 mriedem shitty magic
22:45:55 mriedem ha, sorry tony :)
22:46:13 tonyb mriedem: I'll cope
22:46:32 mriedem i'm not sure what tooling you have which is scraping commit messages for (cherry picked from) messages
22:47:05 tonyb mriedem: one of my magic tools: http://eavesdrop.openstack.org/irclogs/%23openstack-requirements/%23openstack-requirements.2017-10-26.log.html#t2017-10-26T07:02:00
22:48:05 tonyb mriedem: I have a git plugin call diff-backport that grabs the review and the sha for the cherrypick and compares them so can see where they diverge
22:48:25 tonyb mriedem: makes it quick to see conflicts that havn't been called out
22:49:22 tonyb mriedem: It also verifies that the cherry-picked commit has merged
22:49:51 mriedem it's like the swiss army knife of stable review tools
22:50:03 tonyb mriedem: I *should* teach it to look for ^.*Bug: (\d+)$ and open that in a browser

Earlier   Later