Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-12-08
13:22:52 kashyap That's a YubiKey :)
13:22:58 pslestang ;-)
13:23:10 gryf that's looks definitely like a sort of pass ;P
13:23:25 kashyap pslestang: There's a setting to actually make YubiKey to _not_ send the key press automatically
13:23:45 kashyap Lemme post my notes. I have a Nano
13:25:23 pslestang kashyap: I do not have a press button, my yubikey is near the enter key and when I touch the edge of the enter key ccccccdlucfhekeerjhdnrejghllkrdvdnjnjnijknbt
13:25:44 pslestang you see waht I mean
13:25:58 gryf pslestang, just change usb port :)
13:26:05 pslestang already done
13:26:09 gryf :D
13:27:11 kashyap pslestang: What I'm saying is that once you touch it, it automatically sends return keypress. That way you can still touch it while you're active on this channel, and it won't post it here
13:27:24 kashyap See what I mean?
13:27:30 kashyap pslestang: This one - https://kashyapc.fedorapeople.org/YubiKey-Nano-Config-for-Return-Key.html
13:30:31 pslestang kashyap: thx for sharing this, it will definitely be part of my setup
13:31:09 kashyap When I said "That way ..." above, I meant to say _once_ you use the above config. :)
13:33:49 pslestang kashyap: just applied, works great, thx!
13:34:05 kashyap Cool.
13:40:07 kashyap pslestang: (I had broken formatting in the above page; fixed it now. I see that you were able to see through it)
13:43:49 pslestang kashyap: yep I automatically 's/ /</br>/' whith my eyes in the corresponding lines :)
14:29:59 gsantos Hello, folks. I'm the owner of https://review.opendev.org/c/openstack/nova/+/815373 , which was just merged, and I was wondering if a backport of this fix to the previous branches would be feasible. I'm looking at Ussuri, specifically.
14:31:12 lyarwood gsantos: I would think so but it's conditional on the version of libvirt used right?
14:37:40 gsantos Yes, that is a concern. It needs at least libvirt v4.3.0, and the minimum libvirt version for Ussuri seems to be 4.0.0
14:40:07 lyarwood gsantos: kk that's easy enough to handle in the backport however
14:46:38 gsantos Great! So, in order to do that, do I cherry pick (and resolve conflicts for) this commit to the xena, wallaby, victoria and ussuri branches?
14:52:30 lyarwood gsantos: Correct, https://docs.openstack.org/project-team-guide/stable-branches.html#processes
14:52:50 lyarwood gsantos: and add in the libvirt version check once our MIN_LIBVIRT_VERSION dips below 3.2.0
14:52:55 lyarwood sorry 4.3.0
14:57:32 opendevreview Alexey Stupnikov proposed openstack/nova master: Test aborting queued live migration https://review.opendev.org/c/openstack/nova/+/776250
15:06:00 opendevreview mitya-eremeev-2 proposed openstack/nova master: Delete bogus attachments. https://review.opendev.org/c/openstack/nova/+/820935
15:12:47 opendevreview mitya-eremeev-2 proposed openstack/nova master: Delete bogus attachments. https://review.opendev.org/c/openstack/nova/+/820935
15:15:52 EugenMayer when getting `--os-compute-api-version 2.26 or greater is required to support the --not-tag option` while using xena, is that expected?
15:20:42 EugenMayer interestingly, that is only the case for the openstack cli, using nova list --not-tags works without issues
15:21:17 opendevreview Merged openstack/nova-specs master: Allow project admin to list hypervisors https://review.opendev.org/c/openstack/nova-specs/+/793011
15:33:47 gsantos lyarwood: I will try to make these cherry-picks today. Thank you!
15:39:40 sean-k-mooney lyarwood: if you have time can you look at https://review.opendev.org/c/openstack/nova/+/820531 i think the patch looks ok but it would be good to have your input. its pretty small
15:59:09 lyarwood sean-k-mooney: yeah that doesn't look correct
15:59:17 lyarwood I'll write up some notes after some downstream calls
16:00:35 sean-k-mooney ack
16:08:26 opendevreview Merged openstack/nova master: Reattach mdevs to guest on resume https://review.opendev.org/c/openstack/nova/+/815373
16:54:22 EugenMayer Trying to us `--not-tags` with the openstack cli - tells me that my API version '--os-compute-api-version 2.26 or greater is required to support the --not-tag option' - is this expected with xena? seems like https://docs.openstack.org/releasenotes/nova/en_GB/xena.html tells me, that xena has v2.90. - any hints?
16:56:43 melwitt EugenMayer: it is expected, you have to pass --os-compute-api-version 2.26 with the command else by default OSC uses the oldest available microversion 2.1. it does not default to latest microversion
17:03:40 EugenMayer ah ! thank you sir!
19:54:21 eandersson Anyone know if the bug with orphaned neutron ports when deleting a VM on a offline compute fixed in newer versions of OpenStack? Also not super sure if it is a Neutron or Nova bug :p
20:55:18 opendevreview Gustavo Santos proposed openstack/nova stable/xena: Reattach mdevs to guest on resume https://review.opendev.org/c/openstack/nova/+/821126
#openstack-nova - 2021-12-09
08:02:40 gibi o/ morning nova
08:03:08 gibi sean-k-mooney, bauzas, gmann: yesterday I forgot to read back on the instance_action proposal from Tuesday. Now I did
08:03:37 gibi my view is that we can and therefore should decouple the API behavior from the DB representation
08:04:15 gibi so if we agree that we change the deletion of instance_action in the DB that should not impact how our API behaves
08:05:04 gibi so assuming we agree to make the instance action DB table rows soft deleted when the instance is soft deleted, we should change our query in the API to read soft deleted instance actions too
08:05:39 gibi and then we are done. OVH gets the DB consistency they need, and nova keeps all the external behavior unchanged
08:05:42 gibi win - win
08:17:40 pslestan1 hello!
08:19:49 pslestan1 gibi: agree with that and seems aligned with what sean-k-mooney suggested
08:20:17 gibi pslestan1: o/
08:20:25 bauzas gibi: yup, but we discussed about the default for the new microversion
08:20:39 gibi does anybody requested an API change on nova? :)
08:21:16 bauzas gibi: your thought was what I said first
08:21:25 gibi or rephrahsing that, why we want to change API behavior?
08:21:28 bauzas gibi: I don't wanna change the API
08:21:42 gibi cool, then we are on the same page
08:22:17 pslestan1 gibi: about DB consistency I guess that it's more a community oriented choice than OVH only, I mean this is a good thing to get a consistency for everybody not only OVH
08:23:01 gibi pslestan1: sure, sorry for pin it up on OVH, just needed a name for the set of people who need this change
08:23:25 pslestan1 gibi: don't worry
08:23:28 gibi :)
09:57:00 sean-k-mooney gibi: yep i was orginaly suggesting that if we were ever going to change the api behaivor it made sense to cahnge it now but it looks like we dont want to expose this at the api at all
09:57:24 sean-k-mooney gibi: chanig the api behavior would be just to have partity with the servers endpoint
09:57:25 gibi I don't need the API behavior to change
09:57:46 gibi I think it make sense that the history of a VM overlives the VM itself
09:58:03 gibi outlive :D
09:58:08 sean-k-mooney for server list you need to pass --deleted to see the soft deleted ones
09:58:14 sean-k-mooney you dont have to do that for show
09:58:25 sean-k-mooney as far asim aware jsut the list endpoint
09:59:02 sean-k-mooney anyway its fine do we still need a spec if we are not changing the api now
09:59:49 sean-k-mooney we will start soft deleting them in the db but we will change the api to ignore the deleted column
10:00:21 sean-k-mooney so the behavior is the same.
10:00:33 gibi do we need to add a data migration to fill the deleted column of existing actions?
10:00:53 gibi maybe based on the the fact if the instance is deleted or not yet
10:03:27 sean-k-mooney i dont think we do
10:03:37 sean-k-mooney we can just remvoe the deleted column form the query
10:03:57 gibi OK, then I think we don't need a spec, but I let bauzas to decide with his PTL hat
10:03:58 sean-k-mooney we can have an optional nova-manage command to fill it in
10:04:13 sean-k-mooney but i dont think it should be required
10:05:04 bauzas gibi: my first comment was to say : OK for a specless BP *but* not for the last phrase
10:06:03 bauzas https://meetings.opendev.org/meetings/nova/2021/nova.2021-12-07-16.00.log.html#l-203
10:07:17 gibi <bauzas> "We should also implement the possibility to retrieve deleted instance actions as we do for instances." seems like an API change, right?
10:07:27 gibi but there our answer is to keep the API as is
10:07:43 gibi that fullfills this requirement without any API behavior change
10:07:59 gibi as the API always returns both deleted and not delete actions :)
10:08:25 gibi if the requirement is to retrive deleted instance actions _only_
10:08:29 gibi then there is an API change
10:10:40 sean-k-mooney gibi: ya i dont think there really is a usecase fo deleted _only_
10:11:04 sean-k-mooney so i think we are ok to not change the db
10:11:07 sean-k-mooney *api
10:11:27 gibi yepp, I'm on that side yesa
10:11:43 sean-k-mooney so the cahnge is really to two things
10:12:03 sean-k-mooney the server delete sql query/funciton will need to soft delete the instance actions
10:12:23 sean-k-mooney and the instance actions quies will need to ignore the deleted field
10:12:29 sean-k-mooney and that shoudl be sufficnet
10:12:46 pslestang bauzas: I can change the BP to remove the possibility to retrieve deleted instance action as the solution proposed does not need such feature
10:12:57 sean-k-mooney oh and server restore shoudl also restore the instance_actions

Earlier   Later