Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-03-17
09:46:27 bauzas Sophie is turning 40 like me, so I need to help her to not crying :p
09:46:48 lyarwood ^_^
09:47:15 gibi :)
09:48:17 kashyap bauzas: It's like fine wine :)
09:50:57 lyarwood gibi: https://review.opendev.org/c/openstack/nova/+/780333/ - I'm going to hold off on this until stephenfin has sobered up and is back online. I missed that sean had wanted to keep 403 tbh so I think stephenfin just needs to confirm why he changed to 409.
09:54:05 gibi lyarwood: ack, I also would like to consult stephenfin and maybe even with gmann about that return code
09:54:35 gibi lyarwood: we really should approve that patch latest Friday
09:58:10 lyarwood ack
10:51:09 elod lyarwood: I've backported (clean cherry pick o:)) your patch to pike as well: https://review.opendev.org/c/openstack/nova/+/780852
10:51:48 elod could you please have a look? o:)
10:52:16 elod (this is to unblock stable/pike)
10:54:20 Luzi kashyap, i addressed your points https://review.opendev.org/c/openstack/nova/+/781030
11:09:13 mgoddard lyarwood: https://review.opendev.org/c/openstack/nova/+/781079
11:09:48 mgoddard lyarwood: I noticed you assigned https://bugs.launchpad.net/nova/+bug/1917498 to yourself, thought I'd propose my patch before you start working on it
11:09:50 openstack Launchpad bug 1917498 in OpenStack Compute (nova) "Cold migration/resize failure with encrypted volumes can leave instance in error and volumes attaching" [Medium,Triaged] - Assigned to Lee Yarwood (lyarwood)
11:27:59 kashyap Luzi: Looks good; thanks!
12:03:28 lyarwood mgoddard: ah awesome thanks! I'll look in a min
12:09:37 lyarwood mgoddard: so the check LGTM *but* this on the compute itself after we cast (and return 202) from the API
12:09:56 lyarwood mgoddard: AFAICT we should be able to check this before we cast over in the compute API using the bdms
12:10:37 lyarwood mgoddard: its just better UX IMHO, instead of getting a 202 back the caller gets an instant failure
12:11:04 mgoddard lyarwood: agreed, that would be better. Is there precedent for accessing barbican from the API?
12:13:45 lyarwood mgoddard: https://github.com/openstack/nova/blob/2dc26edfc52c791e760f8a7320fdc8be3061d1fe/nova/compute/api.py#L1877-L1889 - yeah looks like it's used with the current ephemeral encryption implementation to create a secret during instance creation
12:14:45 lyarwood that isn't widely used but I think it's still valid for the API to have access to the key manager if configured
12:14:59 lyarwood I *think* c-api also does this ahead of c-vol creating an encrypted volume FWIW
12:18:44 mgoddard lyarwood: right, I think c-api creates the secret
13:32:38 fungi Luzi: gibi: kashyap: when i looked yesterday, it appeared that option was first added in ocata (nova 15.0.0), obviously not a lot of point in backporting to branches that old but you can pretty well backport as far as you want to go
13:33:18 fungi the change to implement it merged in january 2017
13:33:41 kashyap fungi: Yep; indeed it was done during Ocata. Perhaps we can settle on backporting it to the oldest supported stable
13:35:21 fungi that would be consistent with our usual approach to security support for openstack, yeah
13:36:50 gibi fungi: ack
14:54:57 openstackgerrit Nicolas Parquet proposed openstack/nova master: Allow @ and dot (.) characters in keypair name https://review.opendev.org/c/openstack/nova/+/781076
15:09:32 melwitt thanks for the review lyarwood :) elod, in case you missed my ping from yesterday: https://review.opendev.org/c/openstack/nova/+/780991
15:17:31 lyarwood anytime
15:18:43 lyarwood melwitt: https://review.opendev.org/c/openstack/nova/+/757098 & https://review.opendev.org/c/openstack/nova/+/758733 could use stable core reviews if you have time in return :)
15:19:06 melwitt lyarwood: sure thing
15:19:59 lyarwood thanks
15:30:05 gmann gibi: on https://bugs.launchpad.net/nova/+bug/1918945
15:30:06 openstack Launchpad bug 1918945 in OpenStack Compute (nova) "Nova API fails with 500s when called with non-project-scoped keystone tokens" [Undecided,New]
15:31:24 gmann gibi: yes this is not regression, it is as per keystone current design for system scope. we will discuss about that more before and then in PTG. i have added this in etherpad L220 https://etherpad.opendev.org/p/nova-xena-ptg
15:32:27 gmann gibi: may be we should add this as cross project topic with keystone. lbragstad dansmith ?
15:32:57 gmann gibi: lyarwood ack 780333, I will check after my breakfast
15:33:08 dansmith it's fodder for the conversation about system scope for sure
15:33:23 dansmith figured that one that lbragstad has the etherpad for is probably cross-project already
15:33:28 elod melwitt: sorry, i did miss it somehow :S ...but now it's +2+W'd
15:33:45 lbragstad i haven't created any etherpads, yet
15:34:02 lbragstad just the one for summarizing the issue
15:34:16 lbragstad but i didn't target it to be a topic for the PTG officially or anything
15:35:11 melwitt elod: thanks! question for you, how did you figure out that stable/pike was failing for lack of https://review.opendev.org/c/openstack/nova/+/780852 ? just curious bc I can't figure it out. the error I see in nova-live-migration there is "Error EINVAL: bad entity name" and I was curious how you knew what was happening
15:35:20 dansmith lbragstad: https://etherpad.opendev.org/p/nova-xena-ptg L220, I thought that was you but I guess it was sean
15:35:54 lbragstad oh - cool
15:36:34 lbragstad fwiw - i tried summarizing everything in a ml post and i sent it to the operator list
15:36:54 lbragstad i'd like to know if they have any opinions on how this should work
15:36:55 lbragstad http://lists.openstack.org/pipermail/openstack-discuss/2021-March/021131.html
15:38:03 dansmith yeah, I have that marked, but haven't seen any replies yet
15:38:12 elod melwitt: well, I just saw, that it is ceph related, and since we just pinned ceph in newer stable branches I gave it a try
15:38:33 melwitt elod: ahh :) ok cool
15:44:58 gmann dansmith: lbragstad I added it in nova L220 but we can move to cross project section
15:45:10 dansmith ack
15:49:16 gmann dansmith: gibi lbragstad done, moved to L47 - https://etherpad.opendev.org/p/nova-xena-ptg
15:49:17 elod melwitt: and this failure (without the pin) also suggests that we are using ceph octopus in stable/pike (which is now pinned to nautilus in queens and newer): https://zuul.opendev.org/t/openstack/build/ea688ac7f8044e70b1503a517fc36db3/log/job-output.txt#4278
15:50:04 melwitt elod: ohh good spot, thank you
15:55:36 elod melwitt: thank you too for the +2 :)
15:57:42 melwitt elod: np, thank you for fixing it!
15:57:52 gibi gmann, dansmith, lbragstad: ack, thanks. I will check with the keystone team about a timeslot for that cross project discussion
15:59:01 melwitt elod: btw, I opened the result on the pinned ceph version patch for nova-grenade-live-migration and see it's failing with "ERROR: This script does not work on Python 2.7 The minimum supported Python version is 3.6. Please use https://bootstrap.pypa.io/pip/2.7/get-pip.py instead." https://zuul.opendev.org/t/openstack/build/6583ef90f2954a57934781e31d17c68d/log/logs/grenade.sh.txt#2656 do you recall a fix for that going around in the
15:59:01 melwitt past? I can't find
15:59:50 gibi gmann: thanks for confirming that it is not a regression
16:01:04 ignaziocassano Hello All, please anyone can help me with live migrations on queens? Only for some vm live migration does not work. When the vm tries to start on destination host, in instance log I read: 2021-03-15T14:16:12.593707Z qemu-kvm: Failed to load virtio/extra_state:extra_state
16:02:44 ignaziocassano If I hard reset the vm it starts and then I do not got any live migration errors anymore
16:03:57 elod melwitt: hmmm, that failure is related to this: https://review.opendev.org/q/topic:%22get-pip-py27%22
16:04:07 elod melwitt: i'll try to fix it
16:04:59 melwitt elod: oh, derp, how did I miss that in my gerrit search 😆 yeah, I thought it sounded familiar like something that got fixed recently. I'll lookout for your upcoming patch :)
16:05:45 ignaziocassano I wrote an email to openstack-discuss two days ago but I have not received any suggestion yet. Not found any bug related to to this issue
16:06:18 elod melwitt: correction: I won't be able to :/ as that is because it's ocata, and ocata cannot be fixed if I remember correctly... some catch 22...
16:07:28 lyarwood time to nuke the grenade job on pike then I guess?
16:07:53 melwitt elod: you mean pike? it's on pike but it's non-voting, perhaps for similar reasons
16:08:11 elod melwitt: stestr and other contradicting requirements :S (this was my trial: https://review.opendev.org/777614 )
16:08:29 elod melwitt: no, ocata, as grenade on pike starts with ocata install
16:09:34 melwitt elod: oh sorry 😓 I didn't know that. ok, good to know
16:09:42 elod lyarwood: yes, actually, I was thinking on that, too (I hoped I could fix it somehow, but 1. seems not really possible; 2. had another priority all the time... o:))
16:10:30 melwitt yeah, agreed if it can't be fixed then we can save CI resources
16:11:40 elod melwitt: sure. actually not so many patches arrive to pike, but still, it would save some resource :)
16:12:00 melwitt elod: oh, heh true
16:45:02 kukacz hi, is instance rebuild with volume backed instance and selecting same image supposed to actually rebuild the volume to state of the image?
16:47:09 lyarwood kukacz: https://docs.openstack.org/api-ref/compute/?expanded=rebuild-server-rebuild-action-detail & https://bugs.launchpad.net/nova/+bug/1482040
16:47:11 openstack Launchpad bug 1482040 in OpenStack Compute (nova) pike "rebuild volume-backed instance with image does not replace image in root disk" [Medium,Confirmed]
16:47:26 lyarwood kukacz: it's a known limitation that the volume isn't rebuilt using the new image
16:47:42 lyarwood kukacz: iirc we had a spec agreed to look at correcting this but the changes never landed
16:48:27 lyarwood https://specs.openstack.org/openstack/nova-specs/specs/train/approved/volume-backed-server-rebuild.html
16:53:49 lyarwood melwitt: https://review.opendev.org/c/openstack/nova/+/765769 https://review.opendev.org/c/openstack/nova/+/773443 https://review.opendev.org/c/openstack/nova/+/757306 - would you mind also hitting these? Apologies but my backlog is getting way to big now so I need to start pinging people for reviews.
16:53:50 kukacz lyarwood: clear, thanks!
16:54:22 kukacz somehow I thought that this was working when using identical image
16:54:28 kukacz my bad
17:23:13 openstackgerrit Elod Illes proposed openstack/nova stable/pike: [stable-only] Move grenade jobs to experimental https://review.opendev.org/c/openstack/nova/+/781134
17:33:54 gibi did we fixed some pure PCI passthrough evacuate issue since victoria? I cannot reproduce this on master https://bugs.launchpad.net/nova/+bug/1910663
17:33:55 openstack Launchpad bug 1910663 in OpenStack Compute (nova) "pci device duplicate attach after intance evacuated" [Undecided,New]
17:34:38 tosky time to abandon stable/ocata for real?
17:34:51 tosky (looking at that change above ^^)
18:00:58 openstackgerrit Lee Yarwood proposed openstack/nova master: block_device: Use initialize APIs to refresh when reported as idempotent https://review.opendev.org/c/openstack/nova/+/720769
18:01:00 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Reject requests to commit active snapshot of an inactive instance https://review.opendev.org/c/openstack/nova/+/781138

Earlier   Later