| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-01 | |||
| 01:17:25 | gmann | lbragstad: i think ~18 policy are left | |
| 01:17:34 | lbragstad | total?! | |
| 01:17:45 | gmann | counting :) | |
| 01:18:06 | lbragstad | wow - nice work, gmann | |
| 01:18:31 | gmann | lbragstad: around 50 | |
| 01:18:50 | brinzhang_ | dansmith, gmann: this looks so strange, is it? | |
| 01:19:33 | gmann | lbragstad: let me propose warning thing in this week and you can check if that make sense especially from other project point of view | |
| 01:20:10 | lbragstad | gmann ok - do we want to think about a different way for people to opt into the new concept, though? | |
| 01:20:49 | gmann | lbragstad: did not get ? | |
| 01:21:50 | lbragstad | today, if i upgrade to Ussuri and nova has all these new defaults, i need to override all of them to opt into the new way of doing things | |
| 01:21:57 | gmann | brinzhang_: you mean we are going to 403 late if non-admin try to update_swap ? | |
| 01:22:30 | lbragstad | gmann do we want to make that easier by not having operators write policies into a file | |
| 01:22:37 | brinzhang_ | gmann: 403? | |
| 01:22:50 | lbragstad | but still allow them to opt into the new system | |
| 01:23:12 | lbragstad | like what dansmith and melwitt were saying earlier | |
| 01:23:32 | gmann | lbragstad: ohk. they do not need to write policy. if they enable scope and add new defaults in their system then they adopt the new policy | |
| 01:23:55 | gmann | or you are saying new things only and no old things supported ? | |
| 01:24:37 | lbragstad | let's say i want to adopt this right away and i don't want policies OR'd | |
| 01:24:53 | gmann | brinzhang_: i mean policy unauthorize error for non-admin doing update + swap. | |
| 01:25:08 | lbragstad | that requires me (as the operator) to go and update my nova policy file to override all the policies with their new defaults, right? | |
| 01:25:09 | brinzhang_ | gmann: yes | |
| 01:25:36 | gmann | yeah if they want to stop old tokens/role then yes they need to override | |
| 01:25:40 | brinzhang_ | gmann: maybe we should move L494 to L497, what do you think? | |
| 01:25:49 | gmann | but in nova case it is easy as we are controlling those via common base rules | |
| 01:26:46 | gmann | lbragstad: we are testing that simulation also- basically operator needs to do this - https://github.com/openstack/nova/blob/c31de903dd73de1c0a41bcfe4c867daa6eb10f85/nova/tests/unit/policies/base.py#L103 | |
| 01:28:03 | gmann | brinzhang_: we cannot do that becasue swap operation is async and might not be completed before we update deleet flag. | |
| 01:28:40 | gmann | brinzhang_: we can move the both policy checks in starting. i mean check id !=volume_id then check swap policy also. | |
| 01:30:22 | lbragstad | gmann i wonder if we could come up with a way to opt in without having to write to the policy file (after reading the scrollback, i can see how that might be misleading to operators if we've told them not to do that in the past) | |
| 01:30:24 | gmann | brinzhang_: anyways that part we can do in https://review.opendev.org/#/c/711194/10 | |
| 01:31:42 | gmann | lbragstad: i see your point. how about doing it via enforce_scope ? if it is true along with scope enable we remove the ORing old rules ? | |
| 01:32:10 | lbragstad | gmann yeah - i think that would work | |
| 01:32:34 | gmann | basically enforce_scope flag is new policy though we kept new defaults roles separate but still someone want to adopt both at same time | |
| 01:33:15 | brinzhang_ | gmann: I have an doubt, if the swaped volume is a new volume, maybe we will get bdm raised exception.VolumeBDMNotFound, that we dont do _update_volume_regular(), and cannot completed the swap operation, right? | |
| 01:33:22 | lbragstad | we originally intended that to be an all-or-nothing option | |
| 01:33:36 | gmann | lbragstad: for existing project who have already exposed reno or doc which is keystone only :). does that flag scope change is bad for user ? | |
| 01:33:54 | lbragstad | so - operators would only set it once they 1.) updated their policies (which might not be needed anymore) and 2.) audited their users to make sure the ones that need system scope have it | |
| 01:34:07 | gmann | yeah. | |
| 01:34:32 | lbragstad | gmann i need to think through it a bit more | |
| 01:35:37 | lbragstad | i doubt anyone is running enforce_scope in production, yet? | |
| 01:36:59 | gmann | ok, in that way it make sense to make it all-or-nothing. | |
| 01:38:19 | gmann | because new flag controlling scope and defaults roles separately does not make sense. | |
| 01:38:40 | lbragstad | yeah - you mean using the old policies and setting enforce scope to True? | |
| 01:38:41 | gmann | and overahead for us also to maintain the old deprecated things | |
| 01:38:59 | gmann | yeah. | |
| 01:39:12 | lbragstad | i agree - but i'm not an operator :) | |
| 01:39:30 | gmann | :) me too, johnthetubaguy can answer this better | |
| 01:41:02 | gmann | that is how we did the tests for new system. scope + new rules - https://github.com/openstack/nova/blob/c31de903dd73de1c0a41bcfe4c867daa6eb10f85/nova/tests/unit/policies/test_deferred_delete.py#L121 | |
| 01:42:22 | gmann | that was what johnthetubaguy idea to see how operator will use the new policy but he can tell if any operator want to do scope + old rule | |
| 01:42:36 | lbragstad | gmann ah - yeah, we took a similar approach | |
| 01:42:39 | lbragstad | in keystone | |
| 01:42:58 | gmann | nice | |
| 01:43:01 | lbragstad | using a config option would make that easier though | |
| 01:43:06 | lbragstad | and cleaner | |
| 01:48:59 | gmann | brinzhang_: so swap-only is all ok. and if anyone requesting update + swap and update fail (say VolumeBDMNotFound) then it is ok to fail before doing swap. I mean request is for two operations so we either do both with success otherwise fail and failing before swap is good. | |
| 01:49:26 | gmann | otherwise we end up doing multi-success things which is bad | |
| 01:51:16 | brinzhang_ | gmann: I know, but there is an issue, when microversion >=2.85, if the volumeId != id in the request body, I think this will greatly affect the functional requirements of the swap volume. | |
| 01:52:20 | brinzhang_ | if this is only a policy check issue, it is easy to resolve, but it is not | |
| 01:53:43 | gmann | brinzhang_: ohk, you mean user do not have swap-only options with >2.85 ? | |
| 01:54:36 | brinzhang_ | gmann: I will leave comments of this concern, wait for gibi, and dansmith with together consider of that. | |
| 01:55:09 | gmann | brinzhang_: i think we are ok here as swap_volume also does get bdm - https://github.com/openstack/nova/blob/c31de903dd73de1c0a41bcfe4c867daa6eb10f85/nova/compute/api.py#L4777 | |
| 01:55:20 | brinzhang_ | gmann: no, I mean, if the user want to do swap volume | |
| 01:55:21 | gmann | so there is extra things before swap | |
| 01:56:06 | brinzhang_ | gmann, can you refer you link to https://opendev.org/openstack/nova/src/branch/master/nova/compute/api.py? | |
| 01:56:20 | brinzhang_ | github is so slowly for me | |
| 01:56:49 | gmann | brinzhang_: _update_volume_regular does not do any extra things what swap_volume does | |
| 01:57:36 | gmann | brinzhang_: https://opendev.org/openstack/nova/src/commit/c31de903dd73de1c0a41bcfe4c867daa6eb10f85/nova/compute/api.py#L4777 | |
| 01:57:45 | brinzhang_ | gmann: my concern is bdm = objects.BlockDeviceMapping.get_by_volume_and_instance(context, volume_id, instance.uuid), I am afarid this code failed | |
| 01:58:11 | gmann | brinzhang_: but that is what swap_volume also does. above link | |
| 02:02:51 | brinzhang_ | gmann: the old volume's bdm, will be copied to the new volume's bdm? | |
| 02:07:15 | brinzhang_ | gmann: do you think we can get this exception? https://opendev.org/openstack/nova/src/branch/master/nova/objects/block_device.py#L281 | |
| 02:09:55 | gmann | brinzhang_: it can but it can be raised from swap_volume also so updating failing on this first for update+swap request is ok. | |
| 02:10:07 | gmann | because there also we get old volume bdsm | |
| 02:10:09 | gmann | bdm | |
| 02:12:55 | brinzhang_ | if microversion > 2.85 to do update+swap for a new volume (instance_uuid is None, not attached to the instance), the bdm will be always failed, right? | |
| 02:13:14 | brinzhang_ | because we do update firstly | |
| 02:14:12 | gmann | brinzhang_: yeah and swap also fail for the same. | |
| 02:14:39 | brinzhang_ | so for microversion > 2.85, this feature is invalid, I think | |
| 02:33:52 | gmann | brinzhang_: on swap, bdm will be updated with new volume id. | |
| 02:34:21 | gmann | >2.85 either we fail during update or during swap is same thing. | |
| 02:36:58 | brinzhang_ | gmann: if we swap firstly, then update, maybe we can reduce the failed scenario, but looks also not very good for the user when microversion >= 2.85 | |
| 02:39:12 | openstackgerrit | Merged openstack/nova master: Introduce scope_types in os-hypervisors https://review.opendev.org/715036 | |
| 02:39:19 | gmann | brinzhang_: that is problem what gibi commented.swap is rpc async call | |
| 02:39:57 | gmann | https://review.opendev.org/#/c/693828/22/nova/api/openstack/compute/volumes.py@481 | |
| 02:40:28 | brinzhang_ | yeah, I know this, I looked at they are talked records | |
| 02:44:17 | brinzhang_ | gibi: We considered swap rpc asynchronously, but we lost the high availability of the interface. Do you have any suggestions? | |
| 02:46:07 | brinzhang_ | gmann: I left comment with talked by us in the latest patch, I think dansmith and gibi can read that when they are wake up. and you can also reply someting in line. | |
| 03:13:34 | openstackgerrit | Luyao Zhong proposed openstack/nova master: partial support for live migration with specific resources https://review.opendev.org/715362 | |
| 03:13:34 | openstackgerrit | Luyao Zhong proposed openstack/nova master: support live migration with vpmem https://review.opendev.org/687856 | |
| 03:27:03 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in migrate server https://review.opendev.org/716130 | |
| 03:39:29 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add new default roles in migrate server policies https://review.opendev.org/716132 | |
| 03:40:45 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Pass the actual target in migrate server policy https://review.opendev.org/716134 | |
| 03:46:55 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: Add release notes for Cyborg-Nova integration. https://review.opendev.org/716185 | |
| 03:46:55 | openstackgerrit | Sundar Nadathur proposed openstack/nova master: Delete ARQs by UUID if Cyborg ARQ bind fails. https://review.opendev.org/716186 | |
| 03:57:31 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Pass the actual target in migrate server policy https://review.opendev.org/716134 | |
| 04:06:01 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Pass the actual target in unlock override policy https://review.opendev.org/716428 | |
| 04:06:59 | alex_xu | stephenfin: after reading the ffu discussion recently, I'm thinking maybe we can't remove this code https://review.opendev.org/#/c/714699/5 | |
| 04:17:35 | openstackgerrit | Brin Zhang proposed openstack/nova master: Allow PUT volume attachments API to modify delete_on_termination https://review.opendev.org/693828 | |
| 04:53:37 | openstackgerrit | Brin Zhang proposed openstack/nova master: Separate update and swap volume policies https://review.opendev.org/711194 | |
| 05:03:57 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add test coverage of existing remote console policies https://review.opendev.org/716482 | |
| 05:10:07 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in remote consoles policy https://review.opendev.org/716483 | |