| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-26 | |||
| 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 | |
| 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 | |