| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-03-26 | |||
| 16:53:31 | johnthetubaguy | its a new policy I think, admin_or_owner one | |
| 16:53:45 | johnthetubaguy | probably need to rename the old one I guess | |
| 16:54:54 | gmann | ok. | |
| 16:54:54 | dansmith | yeah, new policy | |
| 16:55:44 | johnthetubaguy | gmann: update -> swap, new one called "put" ? | |
| 16:56:19 | gmann | i was thinking new one to 'update' but that is existing and conflcit at deprecation logic | |
| 16:56:37 | johnthetubaguy | yeah, agreed | |
| 16:56:40 | gmann | 'put' will be inconsistentname from other one | |
| 16:57:15 | gmann | 'os-volumes-attachments:volume:update' for new ? | |
| 16:57:32 | gmann | volume is redundant though | |
| 16:57:38 | johnthetubaguy | that seems more inconsistent though | |
| 16:57:43 | gmann | :) | |
| 16:58:38 | dansmith | I would think that it would be okay to rename the existing one, given the conflict | |
| 16:58:40 | dansmith | with a reno | |
| 16:59:03 | dansmith | the existing one, if opened to non-admin users wouldn't be terrible if it applied to the delete flag, and probably expected | |
| 16:59:05 | johnthetubaguy | yeah, I am tempted to just reno about the conflict | |
| 16:59:11 | gmann | ok, deprecation message saying this old policy is being used for this new operation ? | |
| 16:59:18 | dansmith | in all likelihood nobody has changed this one since it _is_ supposed to be for cinder only | |
| 16:59:41 | dansmith | gmann: maybe not deprecation, but a warning if it's set to non-default? | |
| 16:59:55 | johnthetubaguy | nah, skip deprecation, make existing "update" PROJECT_MEMBER_OR_SYSTEM_ADMIN, then add new rule for swap | |
| 17:00:17 | dansmith | yeah, that | |
| 17:00:45 | gmann | ok, that is better. | |
| 17:00:48 | johnthetubaguy | they shouldn't have changed it, if they did, they should read the reno note | |
| 17:01:24 | dansmith | exactly | |
| 17:01:41 | dansmith | if this was for any other thing I would take more care, but this is suuuper obscure and special | |
| 17:02:22 | gmann | and cinder will keep working as new defaults keep allowing admin to access | |
| 17:02:53 | dansmith | yeah | |
| 17:03:09 | gmann | ok adding comment on the review for brinzhang_ | |
| 17:03:19 | sean-k-mooney | gibi: looking at that os-vif repo we have not merged any patches since we did the last release so i think we can stick with the 2.0.0 release for m3 which we created at m2 | |
| 17:04:22 | sean-k-mooney | gibi: if we do merge something between no and next week i can request a release but for now we are good. | |
| 17:14:48 | openstackgerrit | John Garbutt proposed openstack/nova master: Add reno for unified limits https://review.opendev.org/715271 | |
| 17:49:37 | gmann | dansmith: please let me your opinion on this, 'not expose the non-nova exception name to non-amdin' - https://review.opendev.org/#/c/694428/9/nova/objects/instance_action.py@200 | |
| 17:52:24 | dansmith | mnaser: right, which is why we hide the message now | |
| 17:52:41 | dansmith | mnaser: the question is whether or not hiding the actual name of the exception (i.e. LibvirtError) is a problem and I assert that it is not | |
| 17:53:22 | mnaser | dansmith: i agree with that, especially if its a libvirt-specific error | |
| 17:53:29 | mnaser | makes life easier | |
| 17:57:39 | sean-k-mooney | mnaser: to be fair the cve that we had in the past was not acatlly as sever as the bug suggested since the cpeh monitor details specifcaly the ip are also availabel to non admins via the attachment which they can see. but just reporting the name avoids that entirely | |
| 17:59:10 | sean-k-mooney | the only infomation leak that actully causes was the name of the ceph keyfile, still not ideal. | |
| 17:59:23 | sean-k-mooney | but that is fixed in that case at least | |
| 18:02:35 | gmann | mnaser: does any user ask about what driver you use for your cloud and my VM will be running on? before they buy :) | |
| 18:02:54 | gmann | or hypervisor | |
| 18:02:55 | openstackgerrit | Sasha Andonov proposed openstack/nova master: rbd_utils: increase _destroy_volume timeout https://review.opendev.org/705764 | |
| 18:03:03 | mnaser | gmann: i don't think we've actually ever had a customer ask what hypervisor/backend storage/etc | |
| 18:03:10 | sean-k-mooney | gmann: in principaly they should not care | |
| 18:04:00 | gmann | yeah, they should not. I was curious if they make the decision based on that. | |
| 18:04:24 | sean-k-mooney | they might make a dession based on specific features | |
| 18:05:08 | sean-k-mooney | which might only work with specific hyperviors but if vmware and libvirt but suppoted the features/api actions they cared about they proably would not care as long as there application worked fine | |
| 18:06:33 | sean-k-mooney | i mean i think aws uses xen in some from and google cloud suses some form of kvm with its own lightweight qemu alternitive but i dont think most people care when they use either product | |
| 18:08:38 | gmann | in one of our RFP, the customer asked to provide hypervisor-based choice to the user request of VM. not sure how good/bad/usable that was. | |
| 18:09:13 | gmann | though I am not sure it was user request or just customer thought. | |
| 18:09:25 | sean-k-mooney | well that is not realy that hard to do you just use multple virt dirvers in one cloud | |
| 18:09:47 | sean-k-mooney | there are then several filter you can use | |
| 18:11:21 | sean-k-mooney | the over used example is running windows instnace on hyperv but you can use custom extra specs in flaovr or a trait today to support that | |
| 18:58:38 | mnaser | sean-k-mooney: aws has moved away from xen btw :p | |
| 19:03:15 | sean-k-mooney | mnaser: good to know but im not sure there customer will notice which was kind of my point. to them the use an awx m1.whatever instnace | |
| 19:04:20 | mnaser | sean-k-mooney: yep agreed | |
| 20:06:01 | sean-k-mooney | dansmith: im currently testing resculde. it seams to work but sofar i have just added a raise ValueError at the top of spawn in the libvirt driver | |
| 20:06:19 | dansmith | cool | |
| 20:06:23 | sean-k-mooney | the allocation and arq were correctly created against the second host | |
| 20:06:37 | sean-k-mooney | is there anything else you want me to check specificlly | |
| 20:08:28 | dansmith | on reschedule? | |
| 20:08:37 | dansmith | I forget, did you try cold migration? | |
| 20:09:04 | sean-k-mooney | no but i can. i thikn we expect that to fail like evaucate and resize fails. | |
| 20:09:51 | dansmith | ah okay.. I can see migration working and resize not, but only in a few scenarios, so if you did that already that's fine | |
| 20:09:52 | sean-k-mooney | dansmith: this is the current list of followups that we need to adress after the current series is merged https://etherpad.openstack.org/p/cyborg-nova-followup | |
| 20:10:03 | dansmith | evac is a little different since it doesn't get help from the original node | |
| 20:10:20 | dansmith | sean-k-mooney: ah sweet, hadn't seen this | |
| 20:10:32 | sean-k-mooney | ya so evac works but it does not claim an fpga on the dest or update the arq | |
| 20:10:46 | sean-k-mooney | dansmith: sundar created it todeay | |
| 20:10:49 | sean-k-mooney | *today | |
| 20:11:02 | dansmith | doesn't try to update the arq, or fails because the old one isn't deleted? | |
| 20:11:33 | sean-k-mooney | good question i will check but since the placemnt allocation does not have a device i suspect it doesnt even try | |
| 20:11:48 | sean-k-mooney | dansmith: the rebuild path does not have to do any arq updates | |
| 20:11:55 | sean-k-mooney | so i suspect it does not try | |
| 20:12:17 | dansmith | but we scheduled to pick a new host, | |
| 20:12:18 | dansmith | but yeah, fair point | |
| 20:12:42 | sean-k-mooney | ill go check and let you know | |
| 20:14:44 | dansmith | I'm sure there are plenty of things missing, but yeah it'd be good to know where we're starting from | |
| 20:17:15 | sean-k-mooney | dansmith: ah so cold migration is blocked in the code :) | |
| 20:17:16 | sean-k-mooney | Forbidden with instances that have accelerators. (HTTP 403) (Request-ID: req-c318fb6b-730c-4bd3-9ddf-cb7de6e472a3) | |
| 20:17:30 | dansmith | ah okay, I haven't really gotten to that patch at all | |
| 20:17:33 | dansmith | so... good :) | |
| 20:17:44 | sean-k-mooney | so that works at least although the respocne code still looks wrong to me | |
| 20:17:54 | sean-k-mooney | it should proably be a 400 or 409 | |
| 20:22:29 | dansmith | I thought we agreed on 403? | |
| 20:22:45 | sean-k-mooney | we proably did | |
| 20:23:08 | sean-k-mooney | i just find 403 forbiden which is normaly used for auth issues confusing | |
| 20:23:33 | sean-k-mooney | i would expect to get 403 if i did not have enough permission to do something not because its unsupported | |
| 20:26:15 | dansmith | IIRC, 401 means "authorization required" and 403 means "not permitted" - the latter which may or may not be because of insufficient or missing credentials | |
| 20:26:40 | sean-k-mooney | https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/403 | |
| 20:26:49 | dansmith | "401 Unauthorized: If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. 403 Forbidden: The server understood the request, but is refusing to fulfill it" | |
| 20:27:19 | dansmith | "tied to the application logic" | |
| 20:27:36 | sean-k-mooney | ya it gives us leway to use it this way | |
| 20:27:45 | dansmith | "such as (but not limited to) insufficient rights" | |
| 20:28:10 | sean-k-mooney | im just used to thinking about it as related to authorisation | |
| 20:28:33 | melwitt | zzzeek: I've been tracing the gate bug situation with DNM debug logging and the latest thing I found is that this call to _create_session never returns https://github.com/openstack/oslo.db/blob/master/oslo_db/sqlalchemy/enginefacade.py#L657-L658 any ideas how or why that could happen? | |
| 20:28:35 | dansmith | I think a lot of things don't use 401 and 403 properly, so it's common to not have a gut feeling about the difference | |
| 20:33:13 | sean-k-mooney | so this is interesting GET /placement/allocation_candidates?limit=1000&resources=DISK_GB%3A1%2CMEMORY_MB%3A64%2CVCPU%3A1&root_required=COMPUTE_ACCELERATORS%2C%21COMPUTE_STATUS_DISABLED | |
| 20:33:45 | sean-k-mooney | the placement request for the evacuate gets teh trait added by the prefilter | |
| 20:33:52 | sean-k-mooney | but not the resouce requests | |