)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":36686,"name":"Inyong Hong","display_name":"hongp","email":"inyong.hong@samsung.com","username":"hong-p"},"change_message_id":"a36c42e0b3cab890184971ad85e65af2f3a4c0e5","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":5,"id":"79d3924f_735004c7","updated":"2026-05-31 21:37:18.000000000","message":"Hi, We are very excited to see a Weka driver being contributed to Manila. We had actually reached out to Weka via email previously, and in the meantime we implemented our own Weka driver on a hard fork of Manila which we are currently running in production. We have a few questions and would appreciate your feedback.\n\nThe driver uses a single globally-configured weka_organization (defaulting to Root) for all share operations, which means there is no per-project organizational isolation at the Weka level.\n\nIn our experience implementing a Weka driver internally, we found this to be a serious security concern: \nsince all filesystems across all OpenStack projects live in the same Weka organization, all clients must use the same mount account and password regardless of which project they belong to. This means there is no organizational boundary between projects at the Weka level a client from project A and a client from project B are indistinguishable from Weka\u0027s perspective.\n\nWe addressed this by implementing share server support, mapping each Manila share server to a dedicated Weka organization — so each OpenStack project gets its own org context and mount account, and access is scoped accordingly.\n\nIs this single-org approach intentional, and do you consider it secure for multi-tenant deployments? We would appreciate your thoughts on whether our per-project org isolation approach would be a better direction.","commit_id":"77b9f5adcb7dd0ffec2f426067ada7779030b64a"},{"author":{"_account_id":38059,"name":"Anoop Kumar Shukla","display_name":"Anoop Shukla","email":"anoop.shukla@netapp.com","username":"anoop2","status":"NetApp"},"change_message_id":"608e1ee25a95ec98251ffb74c87e6e1fd5d970a8","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":5,"id":"9f6dcab4_be30fb67","updated":"2026-06-02 14:20:12.000000000","message":"Just started the review. Will incrementally review it. Had some initial comments below. Please take a look.","commit_id":"77b9f5adcb7dd0ffec2f426067ada7779030b64a"}],"doc/source/admin/weka_share_driver.rst":[{"author":{"_account_id":38059,"name":"Anoop Kumar Shukla","display_name":"Anoop Shukla","email":"anoop.shukla@netapp.com","username":"anoop2","status":"NetApp"},"change_message_id":"608e1ee25a95ec98251ffb74c87e6e1fd5d970a8","unresolved":true,"context_lines":[{"line_number":55,"context_line":"Supported Operations"},{"line_number":56,"context_line":"--------------------"},{"line_number":57,"context_line":""},{"line_number":58,"context_line":"* Create and delete shares"},{"line_number":59,"context_line":"* Extend and shrink shares"},{"line_number":60,"context_line":"* Ensure shares (re-mount on service restart)"},{"line_number":61,"context_line":"* Create, delete, and revert-to snapshots"}],"source_content_type":"text/x-rst","patch_set":5,"id":"d2be49a0_26671723","line":58,"range":{"start_line":58,"start_character":2,"end_line":58,"end_character":26},"updated":"2026-06-02 14:20:12.000000000","message":"I did not see some additional properties of shares mentioned in the spec or the code changes - eg. thick vs thin (space allocated), quality of service etc. Are these defaulted by the file system and do not require to be mentioned?","commit_id":"77b9f5adcb7dd0ffec2f426067ada7779030b64a"}],"manila/share/drivers/weka/client.py":[{"author":{"_account_id":38059,"name":"Anoop Kumar Shukla","display_name":"Anoop Shukla","email":"anoop.shukla@netapp.com","username":"anoop2","status":"NetApp"},"change_message_id":"608e1ee25a95ec98251ffb74c87e6e1fd5d970a8","unresolved":true,"context_lines":[{"line_number":40,"context_line":""},{"line_number":41,"context_line":"LOG \u003d logging.getLogger(__name__)"},{"line_number":42,"context_line":""},{"line_number":43,"context_line":"_API_V2 \u003d \u0027/api/v2\u0027"},{"line_number":44,"context_line":"_DEFAULT_TIMEOUT \u003d 30"},{"line_number":45,"context_line":"_DEFAULT_RETRIES \u003d 3"},{"line_number":46,"context_line":""},{"line_number":47,"context_line":""},{"line_number":48,"context_line":"class WekaApiClient(object):"}],"source_content_type":"text/x-python","patch_set":5,"id":"ca354048_b165634e","line":45,"range":{"start_line":43,"start_character":0,"end_line":45,"end_character":20},"updated":"2026-06-02 14:20:12.000000000","message":"Are we planning to make these configurable?","commit_id":"77b9f5adcb7dd0ffec2f426067ada7779030b64a"},{"author":{"_account_id":38059,"name":"Anoop Kumar Shukla","display_name":"Anoop Shukla","email":"anoop.shukla@netapp.com","username":"anoop2","status":"NetApp"},"change_message_id":"608e1ee25a95ec98251ffb74c87e6e1fd5d970a8","unresolved":true,"context_lines":[{"line_number":85,"context_line":""},{"line_number":86,"context_line":"        self._session \u003d requests.Session()"},{"line_number":87,"context_line":"        adapter \u003d req_adapters.HTTPAdapter("},{"line_number":88,"context_line":"            max_retries\u003d0,  # handled manually"},{"line_number":89,"context_line":"            pool_connections\u003d4,"},{"line_number":90,"context_line":"            pool_maxsize\u003d10,"},{"line_number":91,"context_line":"        )"},{"line_number":92,"context_line":"        self._session.mount(\u0027https://\u0027, adapter)"},{"line_number":93,"context_line":"        self._session.mount(\u0027http://\u0027, adapter)"}],"source_content_type":"text/x-python","patch_set":5,"id":"087c29ed_148a0136","line":90,"range":{"start_line":88,"start_character":12,"end_line":90,"end_character":28},"updated":"2026-06-02 14:20:12.000000000","message":"shouldnt these be configurable?","commit_id":"77b9f5adcb7dd0ffec2f426067ada7779030b64a"}],"manila/share/drivers/weka/driver.py":[{"author":{"_account_id":36686,"name":"Inyong Hong","display_name":"hongp","email":"inyong.hong@samsung.com","username":"hong-p"},"change_message_id":"a36c42e0b3cab890184971ad85e65af2f3a4c0e5","unresolved":true,"context_lines":[{"line_number":657,"context_line":""},{"line_number":658,"context_line":"        return rule_state_map"},{"line_number":659,"context_line":""},{"line_number":660,"context_line":"    def _update_wekafs_access(self, share, add_rules, delete_rules):"},{"line_number":661,"context_line":"        \"\"\"Handle WekaFS access rules."},{"line_number":662,"context_line":""},{"line_number":663,"context_line":"        Access control for the WekaFS (POSIX client) protocol is managed"}],"source_content_type":"text/x-python","patch_set":5,"id":"d75ccb39_a0eee23d","line":660,"updated":"2026-05-31 21:37:18.000000000","message":"For WEKAFS protocol shares, _update_wekafs_access performs no actual operation — all access rules are accepted and immediately marked active without any enforcement being applied to the\n   Weka cluster. The docstring states that access control is \"managed via Weka filesystem authentication and mount tokens\", but looking at the implementation:\n\n1. Filesystems are created with auth_required\u003dFalse (hardcoded), so mount tokens are not required at all\n2. get_filesystem_mount_token() is implemented in client.py but is never called anywhere in driver.py\n\nCould you clarify the intended design here? Specifically:\n\nIf the plan is to use mount tokens, there is no clear way to expose the token to the end user. Manila surfaces share information through export locations and access rule responses neither of which has a standard field for carrying a short-lived mount token. How would a user actually retrieve the token they need to mount the share?\n\nWhy was the security policy approach not used for WEKAFS access control? Attaching IP-based security policies to the filesystem on update_access would map naturally to Manila\u0027s access rule model, similar to how the NFS side uses client groups.\n\nAs it stands, WEKAFS shares have no access control enforced at the Weka level regardless of what rules are configured in Manila. Is this an intentional interim state, or is there a follow-up patch planned?","commit_id":"77b9f5adcb7dd0ffec2f426067ada7779030b64a"}]}