Posted	Nick	Remark
#openstack-nova - 2020-04-07
16:48:12	stephenfin	True. The client doesn't have to match the server 100% though. We could limit the user client side, even if it's currently a free-for-all server side
16:48:39	gibi	true
16:49:02	stephenfin	I just think allowing '--config-drive foo' is daft, since no ones going to use it, and '--config-drive [True|False]' is worse than '--[no-]config-drive'
16:49:54	gibi	I have to finish for today and we have like 2 days to land the client patches. I can look at it tomorrow again
16:50:20	stephenfin	Yeah, me too. The dog's not going to walk itself :)
16:50:23	gibi	I free I buring time on this that would be better burnt on review
16:50:30	gibi	I feel
16:50:40	gibi	but meh.
16:50:42	gibi	see you tomorrow
16:50:48	stephenfin	o/
17:01:47	stephenfin	gmann: Am I correct here? https://review.opendev.org/#/c/709955/3/nova/api/openstack/compute/volumes.py@401
17:09:57	gmann	stephenfin: yeah. scope_type are not override-able so passing instance project_id is no use there
17:10:15	stephenfin	Sweet. Thanks, gmann
17:10:45	gmann	stephenfin: for few server actions like migration, we default them to SYSTEM_ADMIN and passing the project_id also by keeping scope_type as ['system', 'project'] so that operator can give access to project scope role also if they want
17:11:09	gmann	but when scope_type itself is 'system' only then no use of project_id
17:37:41	gmann	dansmith: what you think on this. checking 'update' policy always and then swap if request is swap - https://review.opendev.org/#/c/711194/14/nova/api/openstack/compute/volumes.py@478
17:38:24	openstackgerrit	Merged openstack/nova master: Introduce scope_types in os-flavor-manage https://review.opendev.org/714818
17:40:42	openstackgerrit	Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing server topology policies https://review.opendev.org/717524
17:45:57	dansmith	gmann: that's an option too yeah. I guess the reason that seems less good is that, unless we check, in order to swap you have to have both permissions.. we might as well make one the superset and not require you to have both explicitly
17:46:06	openstackgerrit	Merged openstack/nova master: Add new default roles in os-flavor_manage policies https://review.opendev.org/714819
17:48:11	gmann	dansmith: yeah, i am thinking doing PUT is always need 'update' policy permission like we do in unlock. first unlock policy permission and then additional unlock_override permission.
17:49:08	dansmith	okay, seems *more* confusing to me, but consistency is good, so if theres already precedent that's fine
17:50:01	gmann	or if we think the use case of override i mentioned is not valid/make sense then we can keep the same way it is currently
17:50:20	dansmith	gmann: does that mean we require update auth for <2.85 as well? meaning I can just put the update policy check always (i.e. remove it from under the else)?
17:50:50	gmann	because it is swap operation so i am not sure interpreting it more user side cases is required or not
17:51:21	gmann	dansmith: ah no, after >2.85 only and before it is always swap-only policy
17:51:43	dansmith	why/
17:52:18	gmann	because we are changing default means new policy itself for new operation which is allowed after 2.85
17:52:26	dansmith	won't the user, who doesn't know anything about policy, wonder why they can do swap with 2.1, but cannot do swap with 2.85, because the admin has not given them update perms yet?
17:52:43	gmann	if we keep default same as old 'update' policy then it is ok
17:53:47	dansmith	.../
17:53:49	gmann	dansmith: without overeride policy they get permission automatically but if overriding the swap policy then even no-deprecation is issue
17:54:06	dansmith	I don't understand what you're saying
17:54:45	dansmith	if the policy defaults are kept, then if I roll out ussuri, users who should have swap permissions will lose that ability with microversion 2.85 until I grant them update permission
17:55:05	dansmith	but they would continue to be able to do it with 2.1
17:55:16	dansmith	however, with what I have, they will see no change in behavior
17:55:43	gmann	with defaults they are always have update permission as it is subset of swap default.
17:55:59	gmann	with defaults, there is no issue on your proposal
17:56:37	gmann	i am thinking if uses has override the old swap policy and want to do the same for new update policy
17:57:07	gmann	if we consider either case default or override - swap is always supeset then it is ok
17:58:28	gmann	but yes, we can not handle all cases in this case
17:59:56	gmann	dansmith: i think it is ok with your approach and we update policy doc that for swap + update we only check swap policy which is expected to be superset of 'update'
18:00:25	dansmith	okay
18:00:36	dansmith	will you comment on the patch about that?
18:00:45	gmann	doing,
18:00:53	openstackgerrit	Merged openstack/nova master: Pass the actual target in os-flavor-manage policy https://review.opendev.org/714822
18:01:04	dansmith	thanks
18:10:26	gmann	dansmith: done. added comment on tests cases, few are not needed and does not test much
18:32:26	openstackgerrit	Merged openstack/nova master: Fix resume server policy to be admin_or_owner https://review.opendev.org/717561
18:32:34	openstackgerrit	Merged openstack/nova master: Add test coverage of existing suspend server policies https://review.opendev.org/717554
18:32:42	openstackgerrit	Merged openstack/nova master: Introduce scope_types in suspend server https://review.opendev.org/717582
18:32:50	openstackgerrit	Merged openstack/nova master: Add new default roles in suspend server policies https://review.opendev.org/717583
18:32:57	openstackgerrit	Merged openstack/nova master: Introduce scope_types in limits policy https://review.opendev.org/715680
18:33:05	openstackgerrit	Merged openstack/nova master: Add new default roles in limits policies https://review.opendev.org/715760
18:33:11	openstackgerrit	Merged openstack/nova master: Add test coverage of existing server group policies https://review.opendev.org/717173
18:39:57	openstackgerrit	Ghanshyam Mann proposed openstack/nova master: DNM testing enforce new defaults flag https://review.opendev.org/717945
18:40:11	openstackgerrit	Ghanshyam Mann proposed openstack/nova master: DNM testing enforce new defaults flag https://review.opendev.org/717945
18:52:38	openstackgerrit	Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing server topology policies https://review.opendev.org/717524
18:53:05	openstackgerrit	Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in server topology https://review.opendev.org/717584
18:53:19	openstackgerrit	Ghanshyam Mann proposed openstack/nova master: Add new default roles in server topology policies https://review.opendev.org/717585
19:03:53	openstackgerrit	Merged openstack/nova master: Introduce scope_types in server group policy https://review.opendev.org/717174
19:04:00	openstackgerrit	Merged openstack/nova stable/queens: Functional test for UnexpectedDeletingTaskStateError https://review.opendev.org/715405
19:29:23	openstackgerrit	Merged openstack/nova stable/queens: Unplug VIFs as part of cleanup of networks https://review.opendev.org/715406
19:40:16	openstackgerrit	Ghanshyam Mann proposed openstack/nova master: Add new default roles in server topology policies https://review.opendev.org/717585
19:43:20	melwitt	gmann: hey, what were you meaning here? https://review.opendev.org/#/c/716809/1/tempest/scenario/test_server_advanced_ops.py are you saying that the test involves passing a specific network during server create? and that getting the 409 multiple networks error means somehow the list_networks is returning None?
19:43:56	melwitt	oops, I should have written that in -qa
19:45:15	gmann	melwitt: yeah. that is one possibility otherwise scenario base tests always send the network in create request
19:45:47	gmann	it was API tests where we reply on tenants network created during setup of credential.
19:45:59	gmann	s/reply/rely
19:46:12	melwitt	ok
20:32:03	openstackgerrit	Ghanshyam Mann proposed openstack/nova master: DNM testing enforce new defaults flag https://review.opendev.org/717945
20:40:34	openstackgerrit	Ghanshyam Mann proposed openstack/nova master: Add new default roles in server group policies https://review.opendev.org/717175
20:50:45	openstackgerrit	Sylvain Bauza proposed openstack/nova master: Provide the parent pGPU when creating a new vGPU https://review.opendev.org/715489
20:50:45	openstackgerrit	Sylvain Bauza proposed openstack/nova master: Support different vGPU types per pGPU https://review.opendev.org/715490
20:50:46	openstackgerrit	Sylvain Bauza proposed openstack/nova master: (WIP) Functional test with pGPUs https://review.opendev.org/717975
22:09:00	openstackgerrit	sean mooney proposed openstack/nova master: cyborg evacuate support https://review.opendev.org/715326
23:01:09	openstackgerrit	Sylvain Bauza proposed openstack/nova master: (WIP) Functional test with pGPUs https://review.opendev.org/717975
23:10:48	openstackgerrit	Sylvain Bauza proposed openstack/nova master: WIP: Functional test with pGPUs https://review.opendev.org/717975
#openstack-nova - 2020-04-08
00:49:38	openstackgerrit	Arthur Dayne proposed openstack/nova master: libvirt:driver:Disallow AIO=native when 'O_DIRECT' is not available https://review.opendev.org/682772
00:57:30	openstackgerrit	Ghanshyam Mann proposed openstack/nova master: Pass the actual target in server group policy https://review.opendev.org/717176
01:28:33	brinzhang_	gmann:https://review.opendev.org/#/c/711194 this patch, I understand damsmith's approach is ok for you, right?
01:29:23	brinzhang_	gmann: https://review.opendev.org/#/c/711194/14/nova/tests/unit/policies/test_volumes.py@224 this case I should move to class VolumeAttachScopeTypePolicyTest ?
01:30:26	gmann	brinzhang_: yes, with mentioning the same in policy description doc
01:30:52	gmann	brinzhang_: VolumeAttachScopeTypePolicyTest should run all tests in is its parent class
01:31:14	gmann	you can update in same class which should run in scope test class also
01:32:50	brinzhang_	gmann: you mean, keep that case in parent class and copy it to the class VolumeAttachScopeTypePolicyTest?
01:33:23	gmann	brinzhang_: no, i mean only update the tests with comments not the location of tests
01:36:41	brinzhang_	gmann: add "new 'update' policy about 'for swap + update' request (which is possible only >2.85) only <swap policy> is checked. We expect <swap policy> to be always superset of this policy permission." to comment this test?
01:38:35	gmann	brinzhang_: that is to update in 'update' policy doc
01:38:44	gmann	policy descritpnio
01:45:22	brinzhang_	gmann: two things, 1) add above description to https://review.opendev.org/#/c/711194/14/nova/policies/volumes_attachments.py@71 and 2):I should add comments on the test case, such as: """ to be always superset of update API policy permission"""
01:51:24	gmann	brinzhang_: only doc is fine. tests case is ok with verification only
02:03:46	openstackgerrit	Huaqiang Wang proposed openstack/nova master: Introduce 'pcpuset' field for InstanceNUMACell https://review.opendev.org/714658
02:03:47	openstackgerrit	Huaqiang Wang proposed openstack/nova master: Introduce the 'CPUAllocationPolicy.MIXED' enum https://review.opendev.org/716267
02:03:47	openstackgerrit	Huaqiang Wang proposed openstack/nova master: hardware: Add support for 'hw:cpu_dedicated_mask' extra spec https://review.opendev.org/714706
02:03:48	openstackgerrit	Huaqiang Wang proposed openstack/nova master: computer: validate cpu pinning configuration for mixed instance https://review.opendev.org/716268
02:03:48	openstackgerrit	Huaqiang Wang proposed openstack/nova master: Calculate the pinned and unpinned CPU usage for mixed instance https://review.opendev.org/716269
02:03:49	openstackgerrit	Huaqiang Wang proposed openstack/nova master: mark mixed policy as ready, bump compute service version https://review.opendev.org/716270
02:03:49	openstackgerrit	Huaqiang Wang proposed openstack/nova master: Setup 'mixed' instance through 'PCPU' and 'VCPU' resource https://review.opendev.org/713355
02:03:50	openstackgerrit	Huaqiang Wang proposed openstack/nova master: metadata: export the vCPU IDs that are pinning on the host CPUs https://review.opendev.org/688936

Earlier   Later