| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-09 | |||
| 16:16:28 | mriedem | given we should have fixed those leaks now in pike, if we do hit this, my comment from the change on master probably applies | |
| 16:16:51 | mriedem | i.e. we shouldn't hit this, so if we are leaking, we f'ed up and warning is probably ok | |
| 16:16:56 | dansmith | yes | |
| 16:27:02 | mriedem | artom: ok +2 on queens, +1 on pike | |
| 16:32:00 | artom | mriedem, dansmith, thank you gentlemen | |
| 16:39:01 | openstackgerrit | Dan Smith proposed openstack/nova master: Add CellMapping.get_by_project_id() query method https://review.openstack.org/509002 | |
| 16:39:02 | openstackgerrit | Dan Smith proposed openstack/nova master: Make get_instance_objects_sorted() be smart about cells https://review.openstack.org/509003 | |
| 17:01:29 | mdbooth | mriedem: If you get a sec could you check I haven't misrepresented you in my response to jaypipes here: https://review.openstack.org/#/c/528363/15/nova/virt/block_device.py ? | |
| 17:04:43 | mriedem | replied | |
| 17:05:43 | mriedem | i really need to be reviewing that series given my somewhat grossly intimate relationship with that code now | |
| 17:06:23 | mriedem | which i plan on making my afternoon | |
| 17:08:04 | mriedem | mdbooth: the entire goal of that series is to get a serial value in the non-volume block devices right? since we only have serial == volume id today, so for the non-volumes we'll use the bdm.uuid | |
| 17:08:30 | mriedem | and the 20 patch refactor series is because that's how you roll :) | |
| 17:08:58 | mriedem | no offense, i know this code is horrible | |
| 17:11:14 | melwitt | mriedem: cool, thanks for the etherpad for the stable release needs | |
| 17:14:41 | openstackgerrit | Jay Pipes proposed openstack/nova master: rework how we pass candidate request information https://review.openstack.org/566166 | |
| 17:16:14 | openstackgerrit | Jay Pipes proposed openstack/nova master: rework how we pass candidate request information https://review.openstack.org/566166 | |
| 17:22:01 | openstackgerrit | Merged openstack/nova master: Fix detach_volume calls when rolling back a failed attach https://review.openstack.org/563213 | |
| 17:47:33 | mriedem | dansmith: lyarwood: https://review.openstack.org/#/c/567232/ should be good to go now - change on master just merged | |
| 18:00:02 | jmccarthy | Hmm trying to setup an encrypted volume, anyone know where does it come up with this device name ? /dev/disk/by-id/scsi-360014057e4c08a456174ed99b53aa5d6 (paste.openstack.org/show/720695/) | |
| 18:00:18 | jmccarthy | It all goes wrong after this, and I can't find that device anywhere .. | |
| 18:00:21 | mriedem | jmccarthy: os-brick library | |
| 18:02:35 | jmccarthy | mriedem: Hmm ok and it's making it up ? Should I be able to 'see' it someplace ? | |
| 18:02:55 | mriedem | lyarwood: is your guy for encrypted volume stuff in os-brick | |
| 18:03:25 | jmccarthy | mriedem: kk ! | |
| 18:03:27 | lyarwood | jmccarthy: what are you trying to find, the original volume on the compute host? | |
| 18:04:07 | jmccarthy | lyarwood: I'm just trying to find where it's going wrong, I can attach unencrpyted, but not encrypted volumes paste.openstack.org/show/720695/ | |
| 18:04:27 | jmccarthy | It goes wrong after here - as this device can't be found anywhere ? Or I'm looking in wrong places | |
| 18:05:54 | lyarwood | jmccarthy: paste.openstack.org isn't working for me, can you use https://paste.fedoraproject.org/ | |
| 18:06:56 | jmccarthy | lyarwood: https://paste.fedoraproject.org/paste/nL0L92U4ArsPfyVkgQlX-Q | |
| 18:07:24 | jmccarthy | It's brief .. but in the case where it works, I'm pretty sure I find that device under /dev/disk/by-id on the compute host | |
| 18:07:37 | lyarwood | jmccarthy: yeah that's expected the first time you attach the volume | |
| 18:07:54 | lyarwood | jmccarthy: well, with the older flow where os-brick formats the volume | |
| 18:07:59 | jmccarthy | That's expected to return 1 is it ? | |
| 18:08:23 | jmccarthy | lyarwood: It's expected to return 1 I mean is it ? | |
| 18:08:36 | jmccarthy | lyarwood: Ok let me try and attach it again | |
| 18:08:55 | lyarwood | jmccarthy: yeah I think so, 0 is the device is encrypted already, 1 if it isn't | |
| 18:09:22 | mriedem | mdbooth: https://review.openstack.org/#/c/528362/14/nova/tests/unit/virt/test_block_device.py@283 | |
| 18:09:27 | mriedem | am i missing something? | |
| 18:09:32 | jmccarthy | lyarwood: Ok my bad, I assumed that was the start of where my attach failed | |
| 18:10:01 | jmccarthy | lyarwood: I'll look at logs more, it's going wrong but I'm doing a bad job at figuring why lol | |
| 18:10:35 | lyarwood | jmccarthy: np, it's an odd flow tbh, feel free to throw another pastebin my way if you want a hand :) | |
| 18:11:41 | jmccarthy | lyarwood: Ok thanks ! Will do :) | |
| 18:13:57 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Add missing encryption_secret_uuid tests https://review.openstack.org/540679 | |
| 18:15:27 | jmccarthy | lyarwood: Maybe this is where I'm going wrong ? https://paste.fedoraproject.org/paste/oSRFKMBJiuCEifxfLXUxhg the volume says it's attaching for a short time, and then just goes back to available | |
| 18:16:21 | lyarwood | jhesketh: yeah it's disconnecting after the libvirt failure to attach the disk to the domain | |
| 18:18:48 | lyarwood | jmccarthy: can you pastebin the entire req-138f35c8-ed21-4430-bf68-525574657926 flow ? | |
| 18:19:15 | jmccarthy | lyarwood: Sure - let me get that together | |
| 18:24:31 | jmccarthy | lyarwood: I think this is all of it ? https://paste.fedoraproject.org/paste/6sdkA90XTlkpftZL5j5D~w | |
| 18:28:34 | lyarwood | jmccarthy: odd, which version of Nova is this? | |
| 18:29:04 | jmccarthy | lyarwood: This is a kolla deploy, queens | |
| 18:29:07 | lyarwood | attach device xml: <disk type="block" device="disk"> is wrong | |
| 18:30:04 | jmccarthy | lyarwood: Ok let me check that a bit more - I do have one setup that is working and one that isn't - I just can't see wtf is going on | |
| 18:30:40 | jmccarthy | lyarwood: Great - Ok, I'll go try and see what is the deal with that - thanks ! | |
| 18:32:02 | lyarwood | jmccarthy: can you just double check that line and make sure it wasn't cut off in your terminal etc | |
| 18:32:22 | jmccarthy | lyarwood: One sec | |
| 18:34:16 | jmccarthy | lyarwood: Ok sorry - part of that bit was missed - this ? https://paste.fedoraproject.org/paste/jR3KP6NlhvTjQZrTl~yK~w | |
| 18:34:47 | lyarwood | jmccarthy: yeah that's better | |
| 18:34:53 | lyarwood | jmccarthy: okay so the XML looks good | |
| 18:35:27 | lyarwood | jmccarthy: are you using fixed_key in nova.conf? | |
| 18:36:07 | jmccarthy | lyarwood: Nope - should I be ? I'm going by this here: https://docs.openstack.org/cinder/queens/configuration/block-storage/volume-encryption.html | |
| 18:36:42 | jmccarthy | lyarwood: I'm pretty sure they are both configured the same, but setup1 works and setup2 doesn't - I have the logs I'm just going crosseyed with where it's going wrong | |
| 18:37:05 | lyarwood | jmccarthy: is it the same key in both envs? | |
| 18:37:14 | lyarwood | jmccarthy: and is the key the same in nova.conf and cinder.conf? | |
| 18:37:33 | lyarwood | ah sorry that doc is using barbican | |
| 18:38:11 | jmccarthy | lyarwood: the setups are not connected to each other at all as such, just in the same lab | |
| 18:38:29 | jmccarthy | lyarwood: nothing is shared | |
| 18:38:55 | lyarwood | jmccarthy: kk can you do a cinder show of the volume? | |
| 18:40:07 | jmccarthy | lyarwood: Should be this here: https://paste.fedoraproject.org/paste/SQ5quYSt8wKOV~-eTqLNMA | |
| 18:40:41 | jmccarthy | lyarwood: I have gone through this a few times, I think the logs aligh with where it's at atm | |
| 18:40:56 | jmccarthy | lyarwood: * s/aligh/align | |
| 18:42:54 | jmccarthy | lyarwood: maybe the log I sent earlier doesn't make senses .. it was grepped on req-138f35c8-ed21-4430-bf68-525574657926 | |
| 18:43:04 | openstack | bugzilla.redhat.com bug 1447297 in libvirt "Unable to use LUKS passphrase that is exactly 16 bytes long" [Unspecified,Closed: errata] - Assigned to pkrempa | |
| 18:43:04 | lyarwood | jmccarthy: yeah there's an underlying libvirt issue here with the attach, I'm just trying to rule out some older known issues with passphrase length etc, for example https://bugzilla.redhat.com/show_bug.cgi?id=1447297 | |
| 18:44:22 | lyarwood | jmccarthy: final ask, `openstack volume type show luks` just to confirm the key_size | |
| 18:44:33 | lyarwood | ^ I think that's the correct command at least | |
| 18:45:02 | lyarwood | https://docs.openstack.org/python-openstackclient/pike/cli/command-objects/volume-type.html#volume-type-show yeah it is | |
| 18:45:32 | lyarwood | openstack volume type show --encryption-type luks | |
| 18:47:30 | jmccarthy | lyarwood: https://paste.fedoraproject.org/paste/34qbpIwDx867wt66JCnUlA | |
| 18:48:25 | lyarwood | jmccarthy: yeah 256 should be fine, odd. | |
| 18:48:36 | jmccarthy | lyarwood: I should be lioadm for the scsi_helper I think it is, right ? | |
| 18:48:37 | lyarwood | jmccarthy: is the same version of libvirt installed in both envs? | |
| 18:49:10 | lyarwood | jmccarthy: that really depends on the underlying env but that isn't the issue here | |
| 18:49:29 | lyarwood | jmccarthy: we can see the raw volume, crypsetup is able to format it etc | |
| 18:49:44 | lyarwood | jmccarthy: libvirt just borks when you try to attach it to the instance | |
| 18:50:00 | jmccarthy | lyarwood: I should have maybe mentioned earlier :/ one is tgdadm I think ? vs lioadm | |
| 18:50:47 | jmccarthy | lyarwood: Should be same version, have to confirm | |
| 18:51:02 | lyarwood | jmccarthy: I still can't see how that could cause this failure tbh | |
| 18:52:25 | jmccarthy | lyarwood: virsh --version says 3.9.0 on both | |
| 18:54:00 | jmccarthy | lyarwood: I know ? | |
| 18:54:24 | lyarwood | jmccarthy: kk, I'm out of ideas on the OpenStack / Nova side tbh, do you have libvirtd logs? | |
| 18:54:40 | lyarwood | jmccarthy: I need to drop in 5 btw before my wife kills me | |
| 18:55:10 | jmccarthy | lyarwood: Oh I did earlier lemme check again - they didn't say much - it's all good I'm fading also - I'll step through them tomorrow | |
| 18:56:09 | jmccarthy | lyarwood: Just more of this here `error : qemuMonitorJSONCheckError:389 : internal error: unable to execute QEMU command 'device_add': Property 'virtio-blk-device.drive' can't find value 'drive-virtio-disk1'` | |
| 18:56:31 | jmccarthy | lyarwood: Ok maybe I can get some more debug log out of that | |
| 18:56:55 | jmccarthy | lyarwood: Thanks for the help ! I thought maybe it was something obvious I was just missing, but I guess not | |
| 18:57:36 | lyarwood | jmccarthy: yeah increase the logging there and it might shed some light, iirc I've seen this before when the passphrase wouldn't unlock the volume, I just can't see how that's possible with the current flow tbh. | |
| 18:58:08 | jmccarthy | lyarwood: o/ | |
| 18:58:25 | jmccarthy | lyarwood: \o lol | |
| 18:58:36 | jmccarthy | Zzz | |