| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-26 | |||
| 20:16:48 | mriedem | since that's what it's for | |
| 20:17:09 | openstackgerrit | Ed Leafe proposed openstack/nova master: Add Selection objects https://review.openstack.org/499239 | |
| 20:17:10 | openstackgerrit | Ed Leafe proposed openstack/nova master: Change RPC for select_destinations() https://review.openstack.org/510159 | |
| 20:17:10 | openstackgerrit | Ed Leafe proposed openstack/nova master: Return Selection objects from the scheduler driver https://review.openstack.org/495854 | |
| 20:17:10 | edleafe | ok, here it comes... | |
| 20:17:11 | openstackgerrit | Ed Leafe proposed openstack/nova master: Make conductor pass and use host_lists https://review.openstack.org/511358 | |
| 20:17:11 | openstackgerrit | Ed Leafe proposed openstack/nova master: Move the claim_resources method to scheduler utils https://review.openstack.org/511357 | |
| 20:19:53 | mriedem | lgtm | |
| 20:20:22 | openstackgerrit | Merged openstack/nova master: conf: Move additional nova-net opts to 'network' https://review.openstack.org/499168 | |
| 20:43:01 | mriedem | bauzas: interested about your thoughts on this when you're up https://bugs.launchpad.net/nova/+bug/1727855 | |
| 20:43:02 | openstack | Launchpad bug 1727855 in OpenStack Compute (nova) "conductor rebuild_instance does not properly handle image_ref if request_spec is not provided" [Low,Triaged] | |
| 20:58:41 | dansmith | mriedem: jaypipes I was hoping we could avoid merging that object until we had all the patches above it settled, | |
| 20:58:49 | dansmith | since we've changed it like a hundred times already | |
| 20:59:38 | mriedem | oh i see | |
| 20:59:40 | jaypipes | dansmith: it's dependent on mriedem's https://review.openstack.org/#/c/513931 anyway. | |
| 20:59:40 | mriedem | yeah that's fair | |
| 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 | again | |
| 21:19:23 | mriedem | it's mfing ceph | |
| 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 | 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 | |