| PMPriya[m] | carloss: gouthamr Continuing with Srinesh’s query on mountable snapshots: **>In case a separate capability for snapshot allow/deny like the goutham mentioned were to be implemented, would you expect us to implement it. Or it will be taken up as part of this or next release.**, As proposed by Goutham, for the H release, should we: support inheriting access rules from the parent share, or proceed with returning an error when users | 11:33 |
|---|---|---|
| PMPriya[m] | attempt to explicitly set snapshot access rules? | 11:33 |
| PMPriya[m] | Also, could you please clarify which team would take up the support for inheriting access rules from the parent share? Should we plan to proceed with erroring out for the H release in the meantime, or is this capability expected to be picked up by our team. | 11:38 |
| carloss | PMPriya[m] srinesh[m] sorry, I missed the last ping from Srinesh on this question. Considering gouthamr's suggestion to error out if one tries to allow access to a snapshot in a backend that does not currently support it - which I also agree - we'd expect that the capability is implemented as part of this change by the HPE team in the H cycle, as this implementation piece in the core is being driven by a requirement of the | 11:47 |
| carloss | HPE driver | 11:47 |
| PMPriya[m] | carloss: Thanks, carloss. Sure, we will try and discuss here if we face any issues. | 15:03 |
| PMPriya[m] | * any issues. Though this can be an option to explore for the H release, should we try to support inheriting access rules from the parent share in the I release? I think it would be a cleaner option . | 15:07 |
| carloss | PMPriya[m]: I think we can discuss it for I, yes, but at the end I believe this also comes with security risks, even though in a cloud it would be fine a scenario where a user has access to the share and also have access to the snapshot | 15:18 |
| carloss | however, what happens if the same user has the access denied and the storage can't replicate? | 15:19 |
| carloss | that would be one of the problems | 15:19 |
| carloss | s/replicate/propagate the access rules changes | 15:19 |
| srinesh[m] | carloss: Just to conclude on our understand. The option you are suggesting and what goutham suggested for H release is | 15:39 |
| srinesh[m] | 1. Implement a new capability similar to "mount_snapshot_support" for eg. "snapshot_access_rule_support". Based on which backend supports this we would error out when a user tries to add/modify any access rule on a mountable snapshot. | 15:39 |
| srinesh[m] | Would this be just an API change or would have UI / CI impact? | 15:39 |
| srinesh[m] | s/understand/understanding/, s/mount_snapshot_support/mount\_snapshot\_support/, s/snapshot_access_rule_support/snapshot\_access\_rule\_support/ | 15:39 |
| srinesh[m] | Also as an alternate if we are time limited would this alternate option also be okay? | 15:41 |
| srinesh[m] | 2. We just return error for our driver only when access rules are added. We will allow the access rules which are in error state now to be deleted. In this way it would be a driver specific change. | 15:41 |
| srinesh[m] | * specific change. Any CI impact of doing an option like this. | 15:41 |
| carloss | > Would this be just an API change or would have UI / CI impact? | 15:59 |
| carloss | this is an API, driver + interface and possibly a bit of a scheduler change and there will be CI impact, as we'll need to test when this is/isn't supported | 15:59 |
| carloss | i am saying this but the changes needed would be minor, considering that everything is in place and the scheduler already does all of the filtering for us | 15:59 |
| carloss | the concerning part about 2 is that it will take a while until we can fail the access rule creation | 16:02 |
| SilviaWachira[m] | Hi carloss, I was checking the calendar invite for today’s Outreachy meeting but I couldn’t find the meeting link. Could you please share it with me? | 16:03 |
| carloss | hey SilviaWachira[m] just emailed you with the meeting room :) | 16:03 |
| carloss | sorry for the hiccup | 16:03 |
| SilviaWachira[m] | carloss: Seen it. Thanks | 16:04 |
| opendevreview | Gireesh Awasthi proposed openstack/manila-specs master: Specs for share server replica https://review.opendev.org/c/openstack/manila-specs/+/988495 | 16:30 |
| opendevreview | Merged openstack/manila master: NetApp - Update ensure_shares() https://review.opendev.org/c/openstack/manila/+/952821 | 17:56 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!