| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-14 | |||
| 15:17:45 | BobBall | melwitt: Bah :D I knew you were going to say that :D I'll do it now so it doesn't have to wait for tomorrow with PRC's timezone. | |
| 15:18:05 | melwitt | I'm too predictable | |
| 15:18:47 | kashyap | Unrelated: Does anyone here use "lp-tools" to file Launchpad bugs via command-line? | |
| 15:18:59 | kashyap | (Launch, manage, query, etc.) | |
| 15:19:22 | kashyap | Which reminds me ... some projects have moved to Storyboard. One day, probably Nova will too | |
| 15:19:38 | melwitt | but yeah, I'd like to get the driver fixed ASAP and not have to wait behind the feature work that's in-progress | |
| 15:21:43 | BobBall | melwitt: We were hoping that patch for the feature was literally about to get merged once the tests all pass :) | |
| 15:22:06 | mriedem | vdrok: so we used to use this utility method to call mkfs.vfat https://review.openstack.org/#/c/527510/3/nova/utils.py | |
| 15:22:41 | mriedem | i don't see anything checking to see if the path exists first or creates the path first | |
| 15:23:16 | mriedem | reading https://linux.die.net/man/8/mkfs.vfat i'm not sure if -C should be specified or not | |
| 15:24:15 | mriedem | http://manpages.ubuntu.com/manpages/xenial/man8/mkfs.vfat.8.html | |
| 15:25:38 | mriedem | unless it's complaining that /opt/stack/data/nova/instances/51858976-6a84-467a-895b-39a22b43b27f/ doesn't exist, but i'm pretty sure it does at this point | |
| 15:25:51 | mriedem | or mkfs.vfat doesn't exist | |
| 15:26:31 | mriedem | trying something | |
| 15:26:57 | vdrok | yeah I see 'unable to open <path>' when specifying non-existing path | |
| 15:28:05 | vdrok | I was testing this on pike when privsep stuff did not exist | |
| 15:28:07 | mriedem | i figured it was because we don't install dosfstools in devstack | |
| 15:33:20 | openstackgerrit | Matt Riedemann proposed openstack/nova master: DNM: test raw image live migration with vfat config drive https://review.openstack.org/567860 | |
| 15:35:07 | openstackgerrit | Bob Ball proposed openstack/nova master: XenAPI: define a new image handler to use vdi streaming https://review.openstack.org/486475 | |
| 15:35:08 | openstackgerrit | Bob Ball proposed openstack/nova master: XenAPI: Pass expected return codes to resize2fs https://review.openstack.org/568318 | |
| 15:37:03 | melwitt | BobBall: I just looked at the processutils code and it defaults check_exit_code=[0]. I wonder if we should just do that in nova/privsep/fs.py instead of making callers pass [0] if they need the default. seems like we could hit this again easily with people thinking they could pass None if they don't care to check the exit codes more specifically | |
| 15:39:19 | BobBall | melwitt: resize2fs takes a check_exit_code - we could indeed put the default there, or decide not to pass it on if None was provided? Or perhaps default to True? | |
| 15:39:45 | BobBall | (IMO check_exit_code=True makes more sense than check_exit_code=[0] | |
| 15:39:48 | melwitt | BobBall: hang on, sorry | |
| 15:41:35 | melwitt | I'm seeing there's a default check_exit_code=False in resize2fs in nova/virt/disk/api.py and I wonder why the code wasn't written to call that instead of calling the privsep module methods directly | |
| 15:43:11 | BobBall | melwitt: I believe because we don't want to run the e2fsck twice? | |
| 15:43:34 | melwitt | BobBall: yeah, and it can't accept the flags kwarg | |
| 15:43:48 | BobBall | Ah - yes. I hadn't spotted that bit :) | |
| 15:44:46 | BobBall | The second call could more easily use the general resize2fs although that would run an unwanted e2fsck again | |
| 15:44:59 | BobBall | and on large disks that can take 10s of minutes... | |
| 15:45:12 | melwitt | no, it's okay, I'm just now realizing that virt/api.py method is for ... someone else apparently | |
| 15:51:55 | BobBall | Joyfulness... | |
| 15:52:26 | melwitt | yeah :| | |
| 15:52:56 | BobBall | How about we just pass check_exit_code=True then? A good enough improvement over check_exit_code=[0]? | |
| 15:52:58 | cfriesen | so we just hit https://bugs.launchpad.net/nova/+bug/1659062 in production, and it left the instance in a state where "reset-state" and "rebuild" didn't work to recover it. | |
| 15:52:59 | openstack | Launchpad bug 1659062 in OpenStack Compute (nova) "Failed evacuations leave neutron ports on destination host" [Wishlist,Opinion] | |
| 15:53:47 | cfriesen | anyone have any ideas on the best way to handle this? fixups in init_instance() on the source? | |
| 15:54:12 | melwitt | BobBall: we could. I was just looking at the old pre-privsep code and it used to be that you could omit check_exit_code and get the default and I think that would make things easier for people, but that can be a separate improvement | |
| 15:55:12 | BobBall | melwitt: I'm happy to make the default for fs.resize2fs be check_exit_code=True and remove it from the XenAPI code if that's the preferred fix. | |
| 15:56:25 | BobBall | melwitt: As it's currently non-optional, all callers must be passing a value therefore having the default set to True won't hurt anyone | |
| 15:58:30 | melwitt | BobBall: yeah, that's true. others might disagree and think the current way of "everybody has to pass it" is better, so I'm thinking not to add any potential debate to your fix | |
| 15:59:29 | BobBall | melwitt: OK - so do you now think we should leave the fix as-is for now? (i.e. passing [0]?) | |
| 15:59:58 | melwitt | yeah, I think that's fine | |
| 16:02:27 | BobBall | +1 | |
| 16:04:47 | melwitt | mriedem: simple fix for xenapi driver regression https://review.openstack.org/568318 tldr: resize broke from the privsep changes but tempest didn't catch it because tempest tests resize with a 0 disk flavor => other 0 disk flavor and xenapi driver skips disk resize in that case | |
| 16:09:47 | mriedem | done | |
| 16:10:47 | melwitt | thanks | |
| 16:14:57 | openstackgerrit | Eric Fried proposed openstack/nova master: Granular requests to get_allocation_candidates https://review.openstack.org/515811 | |
| 16:27:14 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Implement granular policy rules for placement https://review.openstack.org/524425 | |
| 16:27:15 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add granular policy rules for /resource_classes* https://review.openstack.org/565578 | |
| 16:38:12 | mriedem | vdrok: it was the missing dosfstools | |
| 16:38:14 | mriedem | http://logs.openstack.org/60/567860/7/check/nova-live-migration/09d27ca/ passes now | |
| 16:42:14 | mriedem | lyarwood: ^ so you can ignore my earlier ping, +2 on your fix again | |
| 16:47:11 | openstackgerrit | Matt Riedemann proposed openstack/nova master: add lower-constraints job https://review.openstack.org/555961 | |
| 17:07:04 | openstackgerrit | Sylvain Bauza proposed openstack/nova-specs master: Proposes Multiple GPU types https://review.openstack.org/557065 | |
| 17:07:43 | bauzas | jaypipes: dansmith: you reviewed https://review.openstack.org/557065 here is a new revision, but I also provided an implementation change with https://review.openstack.org/#/c/564214/ | |
| 17:07:52 | bauzas | jaypipes: dansmith: do we really need a spec for that ? | |
| 17:08:16 | bauzas | for sure, it's a new conf opt, but no upgrade change | |
| 17:08:47 | dansmith | bauzas: you're asking if you need a spec that you have a spec for? | |
| 17:09:14 | dansmith | seems like a reasonable thing to have a spec for, imho | |
| 17:09:52 | bauzas | dansmith: I meant that given we already discussed alot about the possibilities, now we have the implementation change, looks like it's just an implementation point | |
| 17:09:59 | bauzas | but anyway | |
| 17:10:03 | bauzas | the spec is there for folks | |
| 17:10:15 | bauzas | tbh, the most important for me is https://review.openstack.org/#/c/564214/ | |
| 17:25:25 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Wait for network-vif-plugged before starting live migration https://review.openstack.org/558001 | |
| 17:25:26 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add check if neutron "binding-extended" extension is available https://review.openstack.org/523548 | |
| 17:25:27 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add "bind_ports_to_host" neutron API method https://review.openstack.org/523604 | |
| 17:25:28 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add "delete_port_binding" network API method https://review.openstack.org/552170 | |
| 17:25:29 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add "activate_port_binding" neutron API method https://review.openstack.org/555947 | |
| 17:25:30 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Delete port bindings in setup_networks_on_host if teardown=True https://review.openstack.org/556333 | |
| 17:25:31 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Implement migrate_instance_start method for neutron https://review.openstack.org/556334 | |
| 17:25:32 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add VIFMigrateData object for live migration https://review.openstack.org/515423 | |
| 17:25:33 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add VIFMigrateData.get_dest_vif https://review.openstack.org/566931 | |
| 17:25:34 | openstackgerrit | Matt Riedemann proposed openstack/nova master: libvirt: factor out pre_live_migration plug_vifs call https://review.openstack.org/566932 | |
| 17:25:35 | openstackgerrit | Matt Riedemann proposed openstack/nova master: libvirt: use dest host port bindings during pre_live_migration https://review.openstack.org/566933 | |
| 17:25:36 | openstackgerrit | Matt Riedemann proposed openstack/nova master: libvirt: use dest host vif migrate details for live migration https://review.openstack.org/551370 | |
| 17:25:37 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Annotate flows and handle PortBindingDeletionFailed in ComputeManager https://review.openstack.org/551371 | |
| 17:25:38 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Port binding based on events during live migration https://review.openstack.org/434870 | |
| 17:25:39 | openstackgerrit | Matt Riedemann proposed openstack/nova master: conductor: use port binding extended API in during live migrate https://review.openstack.org/522537 | |
| 17:30:19 | mnaser | can i please get eyes on https://review.openstack.org/#/c/566425 ? | |
| 17:39:51 | openstackgerrit | Dan Smith proposed openstack/nova master: Honor availability_zone hint via placement https://review.openstack.org/546282 | |
| 17:42:49 | mnaser | dansmith, efried, mriedem: thank you, also i like how dansmith and mriedem came up to the same exact thoguht process | |
| 17:43:32 | dansmith | heh | |
| 17:43:43 | mriedem | we finish each other's | |
| 17:44:01 | dansmith | sentences. | |
| 17:44:25 | efried | you guys are gross | |
| 17:44:32 | dansmith | hah | |
| 17:44:56 | dansmith | we're both planning to get pre-summit haircuts on wednesday | |
| 17:45:18 | mriedem | mine is tomorrow | |
| 17:45:22 | dansmith | aww | |
| 17:54:04 | mnaser | i cant be the only one who constantly types 'reno add', get an error then 'reno new' | |
| 17:58:42 | mriedem | tox -e venv -- reno new <slug> | |
| 18:01:44 | mriedem | dansmith: https://review.openstack.org/#/c/567899/ fixes a regression that was backported through to ocata so we should probably get that fix in and backported, | |
| 18:01:55 | mriedem | i had a recreate with our live migration job and the patch on top shows this fixes it | |
| 18:04:16 | zcorneli | dansmith: For file backed memory, any new thoughts on how to handle the old->new migration issue? | |
| 18:07:11 | openstackgerrit | Merged openstack/nova master: Suppress UUID warning in map_instance unit tests https://review.openstack.org/568263 | |
| 18:07:58 | openstackgerrit | Mohammed Naser proposed openstack/nova master: Added ability to configure default architecture for ImagePropertiesFilter https://review.openstack.org/566425 | |
| 18:08:23 | dansmith | mriedem: ack | |
| 18:08:48 | dansmith | zcorneli: remind me, the new xml is calculated on the sending node, to be used by the destination node right? | |
| 18:09:12 | zcorneli | dansmith: That's what I've seen, and how the code seems to expect it. | |