| opendevreview | Merged openstack/manila master: Fix 'server_migrating' status of non-active replica https://review.opendev.org/c/openstack/manila/+/945689 | 00:08 |
|---|---|---|
| opendevreview | kiran pawar proposed openstack/manila master: NetApp: delete vlan even if ipspace is reused https://review.opendev.org/c/openstack/manila/+/941084 | 05:31 |
| opendevreview | kiran pawar proposed openstack/manila stable/2025.1: Fix 'server_migrating' status of non-active replica https://review.opendev.org/c/openstack/manila/+/947553 | 05:41 |
| opendevreview | Merged openstack/manila-tempest-plugin master: Add stable/2025.1 job https://review.opendev.org/c/openstack/manila-tempest-plugin/+/947114 | 07:16 |
| opendevreview | Olamide Ojo proposed openstack/manila master: use openstack cli commands https://review.opendev.org/c/openstack/manila/+/946272 | 11:06 |
| opendevreview | Olamide Ojo proposed openstack/manila master: use os cli for shared-file-crud-share.rst https://review.opendev.org/c/openstack/manila/+/946505 | 11:51 |
| opendevreview | Olamide Ojo proposed openstack/manila master: use os cli for shared-file-crud-share.rst https://review.opendev.org/c/openstack/manila/+/946505 | 12:23 |
| opendevreview | Carlos Eduardo proposed openstack/manila-tempest-plugin master: Add CEPHFS filesystem metadata verifications https://review.opendev.org/c/openstack/manila-tempest-plugin/+/922117 | 13:01 |
| opendevreview | Merged openstack/devstack-plugin-ceph stable/2025.1: Bump default ceph version to squid https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/946081 | 13:40 |
| opendevreview | Takashi Kajinami proposed openstack/puppet-manila master: Stop purging [DEFAULT] ssl_* options https://review.opendev.org/c/openstack/puppet-manila/+/947579 | 13:49 |
| opendevreview | Merged openstack/manila master: Handle race condition for share server delete https://review.opendev.org/c/openstack/manila/+/922010 | 14:07 |
| gouthamr | ~~~ a reminder that there's no IRC meeting this week ~~~ | 14:27 |
| carloss | gouthamr++ :D | 15:38 |
| kpdev | hi carloss/Goutham, are you guys there ? | 16:04 |
| carloss | kpdev: hey, yes | 16:06 |
| kpdev | as discussed in PTG, we will implement share server level encryption only. | 16:07 |
| kpdev | previously it was decided to have --server0encryption-key-ref as option to share create API | 16:07 |
| kpdev | however we decided to not confuse end user | 16:07 |
| kpdev | and provide single option --encryption-key-ref | 16:07 |
| carloss | > and provide single option --encryption-key-ref | 16:08 |
| carloss | correct | 16:08 |
| kpdev | this can be share encryption key ref or share server encryption key ref | 16:08 |
| kpdev | the driver will decide internally and accordingly do encryption | 16:08 |
| kpdev | thus in spec it is mentioned that if driver concludes its share key ref it will store in share_instances table else it will store in share_servers table | 16:08 |
| kpdev | in implmenetation, I will not be doing anything related to share encryption key ref.. all will be implemented assuimg share-server encryption key ref | 16:09 |
| kpdev | we will introduce filter to determine which host support encryption. | 16:09 |
| kpdev | then call will go do manila-share service. there it will ask driver whether it support share or share server encryption. and accordingly it will go in respective tables | 16:10 |
| kpdev | now consider share server case. | 16:10 |
| kpdev | once determined that it is share server encryption key ref, manila share manager will ask driver for compatiable share server, if found share is created and encrypted. | 16:11 |
| kpdev | if not found, new share server will be created, | 16:11 |
| kpdev | to limit max no of share server under share network we will add quota encryption keys per share network | 16:11 |
| kpdev | once quota reached share server and hence share creation will fail | 16:12 |
| kpdev | any questions on this logic ? | 16:13 |
| carloss | kpdev: no questions on it, am I right to assume the ping for confirmation on understanding is because of the comments I posted on the spec? | 16:17 |
| kpdev | yes | 16:17 |
| carloss | alright, let me expand on them | 16:17 |
| carloss | first: if we have the encryption key ref and that is a single parameter, is there a way in castellan/barbican to know whether the encryption key should be share or share server specific? | 16:18 |
| opendevreview | kiran pawar proposed openstack/manila stable/2025.1: Handle race condition for share server delete https://review.opendev.org/c/openstack/manila/+/947608 | 16:18 |
| carloss | kpdev: the thing is: after reading your comments and thoughts on how it would work, my take is that the spec is a bit confusing at the moment. We still keep referring to share/share-server key ref | 16:21 |
| carloss | and I was under the impression that as we are currently targeting the share server implementation, the spec would focus on it | 16:21 |
| kpdev | yes, share server implementation and spec is on it only | 16:22 |
| carloss | kpdev: then we should not be mentioning that the encryption key ref will be stored in the share instance | 16:22 |
| kpdev | it just that instead of two separate option i.e. today --share-server-encryption-key-ref and in future --encryption-key-ref | 16:22 |
| kpdev | we can provide single option and let manila handle it internally | 16:22 |
| carloss | kpdev: got it | 16:23 |
| kpdev | so you are against single option ? | 16:23 |
| carloss | no, I am not | 16:23 |
| carloss | https://review.opendev.org/c/openstack/manila-specs/+/940437/5/specs/flamingo/share_encryption.rst#227 - I am referring to this sentence | 16:24 |
| kpdev | so which part needs to removed/updated ? | 16:24 |
| carloss | "If encryption key ref is provided in API call is for share-server then its stored with share-server else stored with share instance." | 16:24 |
| kpdev | ok I will remove share instance reference | 16:24 |
| carloss | there wasn't a mention in the spec that the spec also targets a change for share instances | 16:24 |
| carloss | so that was the confusing part | 16:24 |
| carloss | also, I believe we should only refer to the key ref as encryption key ref, no `share encryption key ref` or `server encryption key ref` | 16:25 |
| carloss | `Ideally storage driver must support either of share encryption key ref or share-server encryption key ref.` | 16:25 |
| carloss | this is also something that can make it confusing | 16:26 |
| kpdev | what this means is if encryption key ref is provided | 16:26 |
| kpdev | either its share server ref or share ref | 16:26 |
| * gouthamr hasn't seen the latest spec changes | 16:26 | |
| carloss | yes, I get the meaning, but I am trying to say that this makes the whole context of the spec confusing... we are talking about share server encryption, and then we have some details for share encryption | 16:27 |
| kpdev | hold on | 16:27 |
| kpdev | its share encryption only, but with key ref that belongs to share server | 16:27 |
| carloss | yes | 16:28 |
| carloss | > Ideally storage driver must support either of share encryption key ref or share-server encryption key ref. | 16:29 |
| carloss | yes, but a statement like this one makes it feel like we are targeting both implementations: Ideally storage driver must support either of share encryption key ref or share-server encryption key ref. | 16:29 |
| kpdev | >Ideally storage driver must support either of share encryption key ref or share-server encryption key ref. | 16:29 |
| kpdev | I will remove this | 16:29 |
| carloss | ack, thank | 16:29 |
| carloss | kpdev: the spec is really well written and thanks for working on it... I only found these confusing because these statements I highlighted in my review gave me the impression that we are talking about both share server and share specific encryption at the spec | 16:30 |
| kpdev | no | 16:30 |
| carloss | yep, I got it now | 16:31 |
| kpdev | ok, I will address those confusing statements | 16:31 |
| kpdev | w.r.t logic .. are you good ? | 16:31 |
| carloss | kpdev: yes, I'm good | 16:31 |
| carloss | a couple of edits at the final chapters of the spec will help clarifying what we are targeting | 16:32 |
| carloss | kpdev: again, thanks for working on it | 16:32 |
| kpdev | wc | 16:33 |
| gouthamr | through the spec, i think we're flip-flopping between the two kinds, and maybe that part can be improved.. the implementation plan sounds fine afaict | 16:37 |
| carloss | gouthamr++ | 16:38 |
| kpdev | since logic is clear, the wording can be changed // .. no issues/// please comment on spec and I will update accordingly | 16:41 |
| opendevreview | Curtis Copson proposed openstack/manila master: update doc examples https://review.opendev.org/c/openstack/manila/+/947621 | 18:28 |
| opendevreview | Merged openstack/manila-tempest-plugin master: Stop testing the LVM driver with Jammy https://review.opendev.org/c/openstack/manila-tempest-plugin/+/946714 | 18:50 |
| opendevreview | Merged openstack/puppet-manila master: Stop purging [DEFAULT] ssl_* options https://review.opendev.org/c/openstack/puppet-manila/+/947579 | 20:28 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!