Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-04-07
16:41:09 stephenfin right, but what values will do something meaningful? Do we only ever store a string-ified True/False value in there?
16:41:39 gibi stephenfin: we definitely store "True" and "", but I'm not sure if we store other values
16:42:36 gibi at some point in the past we allowed to store a uuid there
16:42:47 gibi https://bugs.launchpad.net/python-novaclient/+bug/1314395
16:42:49 openstack Launchpad bug 1314395 in python-novaclient "Documentation for config_drive boot parameter is incorrect" [Undecided,Fix released] - Assigned to Jason Dunsmore (jasondunsmore)
16:43:07 gibi so in some crazy old deployment the db could contain a uuid
16:43:24 gibi old, mean existed for a long time but upgraded to new nova code
16:44:56 stephenfin gibi: We haven't let you create such a server in quite some time though https://github.com/openstack/nova/blob/bae8b1306eb/nova/compute/api.py#L532-L545
16:45:11 stephenfin What I'm getting at is that it doesn't seem like there's much point allowing the user to pass through an arbitrary string, since the users that can use it are vanishingly small
16:45:33 stephenfin So I wonder if we should just allow true/false and add a TODO that false doesn't actually work until that bug is fixed?
16:45:59 stephenfin specifically, we should use a '--[no-]config-drive' option pair
16:47:04 gibi the API allows now to send in any string in the query param config_drive, when we fix that we need to bump the API microversion. I guess that will be a good signal to change the client to only allow true/false to be passed
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: Support different vGPU types per pGPU https://review.opendev.org/715490
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: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?

Earlier   Later