Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-03-26
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 sean-k-mooney so ya it makes sense even if its not the safest default
12:14:30 gibi kashyap: ack. thanks for bringing in the experts on that
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 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:35 sean-k-mooney i think our default should basically be the same as host model is on x86
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
12:22:28 sean-k-mooney useing max will have an upgrade impact as we will not be able to live migrate safely form a newer host to an older one
12:22:35 sean-k-mooney use host with kvm will allow that
12:22:43 kashyap sean-k-mooney: Hang on; I just asked Peter from QEMU again.
12:22:56 kashyap So, yes: 'max' is same as 'host' on KVM. Always
12:23:12 sean-k-mooney ok if that is the case im fine with it :)
12:23:15 kashyap Okido
12:23:23 kashyap gibi: Please go ahead with the patch. --^
12:23:25 sean-k-mooney ill go +1 it now
12:23:30 kashyap Thx!
12:23:53 gibi thanks, I will look in a minute
12:24:08 kashyap No worries; just wanted to say that the loose end (discussion) is tied :)
12:24:20 gibi kashyap: thanks, it helps :)
12:24:32 kashyap later == April 01 (yes, really; not a joke ;))
12:25:50 gibi kashyap: have a nice time off
12:40:02 hrw thanks
13:22:02 openstackgerrit Merged openstack/nova master: libvirt: Use domain capabilities to get supported device models https://review.opendev.org/666915
13:26:49 openstackgerrit Kevin Zhao proposed openstack/nova master: fix scsi disk unit number of the attaching volume when cdrom bus is scsi https://review.opendev.org/712607
13:41:16 dansmith gibi: yeah, I really just don't like PATCH in general. We don't have it anywhere else in here, and I'm missing the thing that makes it so hard to use PUT that it's worth using PATCH here
13:41:51 dansmith gibi: I wasn't in the discussion where that was decided, which is fine, so until I'm convinced I'm -1 on it, but that doesn't mean you have to stop just for me if you (all) really think it's the only way
13:41:54 gibi dansmith: PUT is not use to update the fields of an existing volume connection but to replace the existing volume connection
13:42:35 dansmith gibi: you don't mean PUT in general, I assume
13:42:46 gibi dansmith: nope. I mean https://docs.openstack.org/api-ref/compute/#update-a-volume-attachment
13:42:55 gibi this is an unfortunate use of PUT ^^
13:43:44 gibi as it replaces an object not updating the field of an object
13:43:49 dansmith right, so if I put the attachment with the same fields but with delete_on_terminate set differently, then it's easy to determine that it's not new yeah?
13:45:01 gibi but then the PUT with the same volume_id needs to be end user facing, while when the volume_id is new it needs to be admin only
13:45:34 dansmith right, so admin can update volume_id, but users can only update delete_on_termination
13:45:39 dansmith seems pretty straightforward to me
13:46:55 openstackgerrit Kevin Zhao proposed openstack/nova master: fix scsi disk unit number of the attaching volume when cdrom bus is scsi https://review.opendev.org/712607
13:48:35 gibi dansmith: your argument feels convinving to me but also in the past the discussion in the spec and on the nova meeting convinved me to use the PATCH approach so I now go to the confused state
13:49:21 johnthetubaguy FWIW, consistency with other Nova APIs seems like a big win, i.e. use PUT
13:49:39 dansmith gibi: okay, it seems like we still need to be able to do a policy check on the body of the thing, even if it''s a PATCH, so I can't imagine why we can't do that for PUT as well
13:49:46 dansmith johnthetubaguy: ++ for sure
13:56:24 gibi I'm sad that this discussion happens so late. From reading back I see that another concern was to mix two slightly unrelated API swap, and update into the same PUT method
13:57:09 dansmith from the api client's perspective it's the same operation isn't it?

Earlier   Later