| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-03-31 | |||
| 16:21:47 | gibi | if we want that the client GET the current attachment, change a field in it, then PUT it back, then PUT needs to accept the format of the GET response | |
| 16:22:02 | gibi | or did I missunderstood the intention here? | |
| 16:22:21 | dansmith | let me go look for an example of a get | |
| 16:23:09 | dansmith | are you saying because volumeAttachments[] vs volumeAttachment ? | |
| 16:23:59 | dansmith | 2.79 GET of a single attachment looks the same to me, no? | |
| 16:24:45 | gibi | it has id in it | |
| 16:24:49 | dansmith | https://docs.openstack.org/api-ref/compute/?expanded=update-server-detail,list-volume-attachments-for-an-instance-detail,show-a-detail-of-a-volume-attachment-detail#show-a-detail-of-a-volume-attachment | |
| 16:25:01 | tobias-urdin | doing upgrade testing after upgrade nova-compute throws a RuntimeError: maximum recursion depth exceeded while calling a Python object http://paste.openstack.org/show/791412/ | |
| 16:25:18 | gibi | crate only allows volumeId and device | |
| 16:25:21 | gibi | create | |
| 16:25:26 | tobias-urdin | based on traceback i've tried upgrading oslo.db 5.0.2 and oslo.concurrency 3.30.0 (and all other oslo for that matter) but it won't start | |
| 16:25:26 | dansmith | ah, okay gotcha | |
| 16:25:38 | dansmith | I thought you were saying it was structurally quite different or something | |
| 16:25:38 | gibi | you added tag and d-o-t | |
| 16:25:50 | gibi | I meant we have different amout of fields | |
| 16:26:18 | gibi | structure seems to be the same | |
| 16:26:32 | dansmith | okay I guess I missed serverId although I thought I had it in there | |
| 16:26:36 | gibi | just GET returns extra fields which PUT does not allow | |
| 16:26:47 | dansmith | yep, I see now | |
| 16:27:03 | gibi | serverId and id (which is the attachment id based on the doc) | |
| 16:31:51 | gmann | dansmith: gibi : should we allow tag update also in this - https://review.opendev.org/#/c/693828/21/nova/api/openstack/compute/volumes.py@475 | |
| 16:32:46 | dansmith | gmann: sorry I should have said something, but I looked into it and it requires an rpc call to update that, so I think we should punt | |
| 16:33:51 | gmann | dansmith: ohk. it's not our DB only things. got it. | |
| 16:33:56 | dansmith | yeah | |
| 16:35:50 | tobias-urdin | anybody has an idea what could be causing the traceback? :) http://paste.openstack.org/show/791412/ | |
| 17:07:22 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Use unittest.mock instead of third party mock https://review.opendev.org/714676 | |
| 17:07:22 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Remove future imports https://review.opendev.org/714675 | |
| 17:26:39 | openstackgerrit | Merged openstack/os-vif master: Update hacking for Python3 https://review.opendev.org/715651 | |
| 17:44:30 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Introduce scope_types in lock server policy https://review.opendev.org/716114 | |
| 17:47:25 | sean-k-mooney | stephenfin: didnt efried already sumbit a patch for https://review.opendev.org/#/c/714676/ | |
| 17:47:38 | sean-k-mooney | did he abandon it? | |
| 17:49:11 | sean-k-mooney | stephenfin: https://review.opendev.org/#/c/708262/ | |
| 17:54:01 | sean-k-mooney | stephenfin: it looks like you have fixed import ordering and some other minor thinks so i guess your patch is more complete but you should probably cherry-pick the hacking change ontop of your patch | |
| 18:00:14 | openstackgerrit | Dan Smith proposed openstack/nova master: Allow PUT volume attachments API to modify delete_on_termination https://review.opendev.org/693828 | |
| 18:01:01 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Add new default roles in lock server policies https://review.opendev.org/716122 | |
| 18:33:18 | efried | stephenfin, sean-k-mooney: feel free to take over or abandon mine as needed. | |
| 18:33:44 | efried | but yeah, the hacking change should be included in the series. | |
| 19:01:11 | openstackgerrit | Corey Bryant proposed openstack/nova stable/queens: hardware: fix memory check usage for small/large pages https://review.opendev.org/716328 | |
| 19:06:22 | openstackgerrit | Marcin Juszkiewicz proposed openstack/nova master: libvirt: check for AMD SEV only on x86-64 https://review.opendev.org/714425 | |
| 19:10:00 | stephenfin | sean-k-mooney: Ah, I'd forgotten about that. Will combine | |
| 19:33:47 | openstackgerrit | Merged openstack/nova master: [Community goal] Update contributor documentation https://review.opendev.org/712420 | |
| 19:33:57 | openstackgerrit | Merged openstack/nova master: Fix os-ips policy to be admin_or_owner https://review.opendev.org/715496 | |
| 19:34:04 | openstackgerrit | Merged openstack/nova master: Add test coverage of existing ips policies https://review.opendev.org/715477 | |
| 19:34:11 | openstackgerrit | Merged openstack/nova master: Introduce scope_types in os-ips https://review.opendev.org/715529 | |
| 19:34:18 | openstackgerrit | Merged openstack/nova master: Add new default roles in os-ips policies https://review.opendev.org/715545 | |
| 20:03:23 | openstackgerrit | Merged openstack/nova master: Pass the actual target in os-agents policy https://review.opendev.org/701649 | |
| 20:46:39 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Pass the actual target in unlock override policy https://review.opendev.org/716428 | |
| 20:55:01 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Pass the actual target in limits policy https://review.opendev.org/715761 | |
| 20:55:06 | dansmith | gmann: you around? | |
| 20:55:21 | dansmith | owalsh has a question for you :) | |
| 20:55:37 | gmann | dansmith: hi | |
| 20:55:51 | dansmith | gmann: http://paste.openstack.org/show/kckeKCDgq679ixa2g5IK/ | |
| 20:56:03 | dansmith | gmann: when running nova-manage with an empty policies file | |
| 20:56:44 | owalsh | nova-manage cell_v2 discover_hosts --by-service if it matters | |
| 20:58:22 | dansmith | owalsh: I gotta step away for a bit to get ready for something, but from poking around I feel like gmann is probably your mann :) | |
| 20:58:33 | owalsh | dansmith: ack, thanks | |
| 20:58:34 | gmann | :) | |
| 20:58:40 | openstackgerrit | sean mooney proposed openstack/nova master: [WIP] cyborg evacuate support https://review.opendev.org/715326 | |
| 20:59:31 | owalsh | gmann: already covered by one of the bp/policy-default-refresh patches? | |
| 20:59:38 | gmann | owalsh: those are new defaults and it add the deprecation even you have not override it. but old token keep working as they are maintained as deprecated rule till now. | |
| 20:59:46 | gmann | yeah | |
| 21:00:38 | owalsh | gmann: cool, so should go away once they all merge | |
| 21:00:53 | gmann | owalsh: we are changing all the policy to adopt the system scope and new defaults like read-only etc | |
| 21:03:36 | gmann | owalsh: warnings will stay till we remove the deprecated old rules in 1 or 2 cycle from now | |
| 21:05:07 | owalsh | gmann: ack, thanks, expect I'll get asked about the warning quite often until then :-) | |
| 21:09:23 | gmann | owalsh: basically signal to adopt the scope check, those are configurable for now and disabled as default. our goal is to 1. remove the old deprecated roles 2. enable scope check together. but you can always move to new policy by configuring the enforce_scope=Ture | |
| 21:09:59 | gmann | i am still working on those and should provide a doc on 'how to migrate to new policy' once done. | |
| 21:10:38 | gmann | owalsh: i hope those warnings are not much disturbing (as they are for every rule). | |
| 21:11:12 | melwitt | gmann: ++ I was just gonna say I wonder if we can improve that warning message and link to a doc explaining the details and process for migrating. a main point in it is the user being able to tell whether they need to migrate at all, based on their existing policy | |
| 21:11:43 | melwitt | at a minimum once you have written a doc, we should update the warning message to include the link to the documentation | |
| 21:12:42 | gmann | melwitt: that is good idea. it will be easy to link doc to warning | |
| 21:21:28 | owalsh | gmann: so for default (empty) policy file we will still get warning for 1-2 cycles? | |
| 21:21:49 | owalsh | or just if deprecated roles are used in the policy? | |
| 21:22:03 | dansmith | it definitely sucks to warn about deprecated policy when the deprecated things are defaults | |
| 21:22:21 | dansmith | if we can't tell what is deprecated (defaults vs. overrides) I would argue we should squelch that warning | |
| 21:25:52 | gmann | owalsh: all becasue defaults are deprecated | |
| 21:27:08 | gmann | it is for all rule as we use those defaults rules as check_str for every rule and oslo policy just add warning for those | |
| 21:27:25 | gmann | not sure how to combine those. | |
| 21:30:43 | gmann | one way is disable oslo warning completely and add a single combined warning form nova policy code with link to migration doc. | |
| 21:34:03 | bnemec | The deprecations are warning you that something might break next cycle and you should test with the future defaults now. | |
| 21:35:50 | gmann | bnemec: we test with both old and new but with disable wanring. | |
| 21:36:07 | dansmith | bnemec: sounds like he has deprecated our existing defaults | |
| 21:36:13 | dansmith | which is why I think we should *not* show this to the user | |
| 21:36:20 | dansmith | there's nothing they can do about it, other than ignore | |
| 21:36:46 | dansmith | it teaches our users to ignore deprecation warnings which is majorly uncool | |
| 21:38:01 | bnemec | Ah, this is a different type of deprecation than what I was thinking of. | |
| 21:38:10 | gmann | and each warning teach what is new defaults to that operator can overidde if anything breaking for them | |
| 21:38:32 | gmann | though that info is present in policy doc also | |
| 21:39:21 | dansmith | gmann: I'm not sure what you're saying | |
| 21:39:29 | bnemec | I think the intent when a policy rule name is changing is that if the new policy name is in the policy file then we don't log the warning. | |
| 21:39:39 | dansmith | if the user has made no policy choices and we're logging things telling them that their policy is deprecated, that's a problem | |
| 21:40:25 | dansmith | also, why are we logging this from nova-manage? | |
| 21:40:47 | dansmith | we're just making admin eyes bleed if we complain about something not even related to nova-manage on each command invocation | |
| 21:40:55 | gmann | dansmith: i mean each warning say old default of xyz rule is replaced with one of new default. for example legacy admin to system_reader | |
| 21:41:10 | dansmith | gmann: but we're complaining about our own defaults right? | |
| 21:41:17 | gmann | yeah | |
| 21:41:21 | bnemec | That's fair, we've actually shut off the policy deprecations in some cli tools and unit tests. | |
| 21:41:24 | dansmith | *that* is not okay | |
| 21:42:23 | dansmith | if we have no way to distinguish then we need to squelch the warning until we've fixed all our defaults | |
| 21:42:35 | gmann | i think waning should be added once during api service only | |