Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-03-26
00:09:28 brinzhang_ dansmith: I dont know what you would want to say, you mean we should use update method instead of patch method? We were disscussed in irc meetting, at the beginning I wanted to use `PUT /servers/{server_id}/os-volume_attachments/{volume_id}` to implement this feature, but more people dont agree.
00:09:35 brinzhang_ dansmith: Firstly, we need admin_or_owner role to execute this, but the PUT swap volume API default role is administrative.
00:09:44 brinzhang_ dansmith: Secondly, we should make the `volumeId` to optional in the request body, that change is to big, and many limits and changes will be add this PUT swap volume API.
00:09:48 brinzhang_ dansmith: From talked in the irc meetting before freeze blueprint for Ussuri, we reached a letter of agreement and adopted the alternative scheme[1] of seen-k-mooney to achieve this function.
00:09:54 brinzhang_ [1] https://review.opendev.org/#/c/580336/32/specs/ussuri/approved/destroy-instance-with-datavolume.rst@51
00:10:50 brinzhang_ dansmith: I know you didn't participate in the irc discussion at the time, but I don't understand why we can't use the PATCH API?
00:56:37 alex_xu sean-k-mooney: I guess we are missing a patch for evacuate
01:44:04 brinzhang_ alex_xu, sean-k-mooney: I think in the libvirt we are lost the accel_info after evacuate, https://review.opendev.org/#/c/631245/62/nova/virt/libvirt/driver.py@5781
01:45:32 brinzhang_ alex_xu, sean-k-mooney: when we have an evecuate a server, maybe we need try to get the accelerators info for by instance.uuid, rirht?
03:15:29 sean-k-mooney alex_xu: we are not planning to have all ops supported initally so evac can be added later if we block it in the final patch
03:15:44 sean-k-mooney but it would be good to add it sooner rather then later
06:08:56 openstackgerrit Luyao Zhong proposed openstack/nova master: support live migration with vpmems https://review.opendev.org/687856
06:08:57 openstackgerrit Luyao Zhong proposed openstack/nova master: Track orphan instances and error migrations in resource tracker https://review.opendev.org/714653
08:01:28 gibi good morning nova
08:03:48 brinzhang_ gibi: good morning ^^
08:05:18 gibi o/
08:05:29 brinzhang_ gibi: pls add this PATCH API for implement bp/destroy-instance-with-datavolume to today's agenda, I replied dansmith's comments inline, and above in irc
08:06:17 gibi brinzhang_: OK. Will you be able to participate or I could you update me shortly what the disagreemen is about?
08:06:33 gibi s/I//
08:06:39 brinzhang_ gibi: he seems dont want I use PATCH API to do this, but I dont want to have a change.
08:07:27 brinzhang_ gibi: it's too later for mee, I am not able to participate
08:07:59 gibi brinzhang_: OK thanks. I will raise it to find a way forward
08:09:06 brinzhang_ I think this PATCH reched in the irc meeting, without good reason, I hope it will not stop it from moving forward.
08:10:09 brinzhang_ gibi: you can see the irc log above, at 8:09:27-8:10:50
08:10:10 gibi I have to, and I will, read back on the disagreement
08:10:21 brinzhang_ gibi: thanks ^^
08:13:29 brinzhang_ gibi: for bp/action-event-fault-details https://review.opendev.org/#/c/694430/, gmann agreed to add the new policy, but he want we limit it in 4xx error code, I think we also need expose 500 (novalid host exception) to the non-admin if we changed the default policy
08:13:54 brinzhang_ gibi: you can review https://review.opendev.org/#/c/694430/, thanks
08:19:01 gibi brinzhang_: I will
09:56:45 gibi gmann, brinzhang_: responeded in https://review.opendev.org/#/c/694430/
10:14:32 brinzhang_ gibi: thanks, the new policy mainly facilitates us to expose the 'details' information to non-admin. We can change it by modifying the default policy check_str. This has been agreed with gmann. Last night at 15:00 UTC in openstac-nova channel discussion .
10:14:44 openstackgerrit Marcin Juszkiewicz proposed openstack/nova master: Add default cpu model for AArch64 https://review.opendev.org/709494
10:15:23 hrw kashyap: took your comments and applied
10:15:42 kashyap hrw: Hiya; will look
10:15:46 kashyap Thanks!
10:16:10 gibi brinzhang_: yeah I'd like to have the new policy to control the exposure of the 'details' field
10:16:26 brinzhang_ if we re-using the BASE_POLICY_NAME% 'events' policy, we will difficult to distinguish whether 'traceback' or 'details' expose to non-admin
10:16:35 brinzhang_ gibi: yeah, thanks
10:17:11 brinzhang_ gibi: now gmann want we shuold just catch 4xx error to populate the 'details'
10:18:09 brinzhang_ gibi: But I think we also need 500 error, that the non-admin can have a try as soon as possible
10:18:18 luyao stephenfin: Hi, I have addressed alex_xu's comments. :) https://review.opendev.org/#/c/687856
10:18:47 gibi yeah, I want to expose information, including NoValidHost, but I don't want to collect every possible error to whitelist them.
10:18:59 brinzhang_ as you said in commnets, information leakage is inevitable. Since the administrator chooses to modify the default policy, he will accept the change.
10:19:09 gibi brinzhang_: exactly
10:19:50 brinzhang_ gibi: yeah, we are same, wait for gmann check, he has -1 on the patch
10:20:02 hrw kashyap: turns out that we need that patch to get kolla-ansible CI running ;(
10:22:53 nightmare_unreal hey how can i create fake cells and create instance in them for functional test. I am looking at nova/tests/functional/test_nova_manage.py
10:24:28 luyao lyarwood: about vpmem cleanup during live migration, we can check migration_context but not adding a new flag to migrate_data obj, you can look at https://review.opendev.org/#/c/687856/20/nova/compute/manager.py@8197
10:24:58 kashyap hrw: "That patch" is the above default CPU model thing?
10:26:24 kashyap hrw: Looks good to me; FWIW; once Zuul blesses it, then it can go through
10:27:49 gibi brinzhang_: responed in the PATCH API discussion in the review and added the topic for the nova meeting accordingly
10:28:01 hrw kashyap: yep
10:28:23 hrw kashyap: or I am going to lose my sanity (as usual when touching nova/libvirt/qemu at once)
10:28:47 brinzhang_ gibi: thanks, I will see after dinner ^^
10:29:12 gibi brinzhang_: ack, have a nice dinner
10:29:47 nightmare_unreal nvm found it
10:49:46 openstackgerrit Merged openstack/nova master: Add Cyborg device profile groups to request spec. https://review.opendev.org/631243
11:11:29 openstackgerrit jayaditya gupta proposed openstack/nova master: Support for nova-manage placement heal_allocations --cell https://review.opendev.org/714459
11:33:47 openstackgerrit Lee Yarwood proposed openstack/nova master: workarounds: Add option to disable native LUKSv1 decryption by QEMU https://review.opendev.org/708030
11:33:48 openstackgerrit Lee Yarwood proposed openstack/nova master: workarounds: Connect RBD volumes to the compute host as block devices https://review.opendev.org/708029
11:47:47 lyarwood stephenfin: https://review.opendev.org/#/c/714956/ - would you mind hitting this?
11:47:56 stephenfin sure
11:48:15 lyarwood luyao: ack sorry swamped with downstream things, I'll get back to that review today
11:49:27 luyao lyarwood: thanks :)
12:07:33 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Break up get_disk_mapping within blockinfo https://review.opendev.org/714962
12:09:06 hrw kashyap: zuul gave +1 for https://review.opendev.org/#/c/709494/ - bumping to +2+w?
12:12:22 kashyap hrw: I am a mere mortal, can't +2 :)
12:12:35 kashyap gibi: ^ Mind having a gander at hrw's completed patch?
12:12:51 gibi kashyap, hrw: sure I will try
12:13:14 kashyap gibi: At its core, it is setting a sensible default CPU model for AArch64 VMs
12:13:35 kashyap gibi: We arrived at the sensible default (CPU model 'max') after consulting the QEMU AArch64 maintainers.
12:14:15 sean-k-mooney kashyap: you could argue that min would be a better sensible default for live migration but max is overall a better default
12:14:30 gibi kashyap: ack. thanks for bringing in the experts on that
12:14:30 sean-k-mooney so ya it makes sense even if its not the safest default
12:14:32 kashyap "min"? There's no such thing as "min"
12:15:01 sean-k-mooney isnt there. there was an alternitive to max we were considering
12:15:19 sean-k-mooney my understanding of max is it will enable all feature that qemu can emulate on the host
12:15:29 sean-k-mooney not just the ones the host has at the hardware level
12:16:05 kashyap You mean, 'host'?
12:16:17 sean-k-mooney perhaps yes
12:16:35 sean-k-mooney i think our default should basically be the same as host model is on x86
12:16:35 kashyap As I noted on the patch, that is still not a good option if you want it to work for _both_ TCG and KVM.
12:16:38 kashyap To quote myself:
12:16:40 kashyap [quote]
12:16:41 kashyap For KVM, we essentially have to go with "give the guest what the host CPU has", which you can express either as "host" or as "max" CPU models, the benefit of the latter ("max") being that it also works with TCG.
12:16:45 kashyap [/quote]
12:17:01 kashyap sean-k-mooney: That's what 'max' is; except that it also does the right thing for TCG
12:17:19 kashyap gibi: Thanks!
12:17:31 kashyap sean-k-mooney: Give your ACK on the change, too, please
12:17:57 sean-k-mooney max will not do the right thing for kvm however right. it will expose more then the host can support in hardware right
12:18:22 sean-k-mooney kashyap: well im not conviced max is the right thing in the kvm case i would prefer to have a different default for both honestly
12:18:33 sean-k-mooney max i think makes sense in the qemu/tcg case
12:18:57 sean-k-mooney unless host and max are always identical in the kvm case i woudl prefer it to be host when virt_type=kvm
12:19:19 kashyap sean-k-mooney: Did you read the above quote?
12:19:26 sean-k-mooney yes
12:20:04 sean-k-mooney is host always identical to max with kvm
12:20:25 kashyap No; 'max' will give you the moving-target "all the stuff we can currently emulate".
12:20:29 sean-k-mooney or if your qemu can emulate feature not present on the host hardware will max result in it doing so even with kvm
12:20:32 kashyap Let's not get worried about theoretical concerns.
12:21:29 sean-k-mooney kashyap: its not a terirectical concern i disagreed with your live migration change and this in my view is one step closer to use not supporting live migration with aarch64 at all

Earlier   Later