| carthaca | Hi, picking up the discussion we had yesterday re: https://etherpad.opendev.org/p/share-encryption-with-barbican-secret-ref . After a good night of sleep I thought about simplifying this even further: as an end user I don't care how the driver is doing the encryption I just want to specify my encryption key that will be used. So ultimately I don't need to know if the driver encrypts the whole share server or can encrypt a single share. | 12:26 |
|---|---|---|
| carthaca | So why bother with having two mutually exclusive options server-encryption-key and share-encryption-key then? Each driver will use one of them (if there are drivers that can support both, I think the decision which one to use should be given to the admin, not end user). The implementation detail that the NetApp driver would use the provided key to encrypt the share server, not the single share, should not be exposed imho. Limiting the | 12:26 |
| carthaca | keys_per_share_network via a quota should be set per share type and the admin can make sure that a hard limit is only in place when the driver is doing the server encryption and can encourage end users to maybe share keys in the same share network for multiple shares (and this kind of documentation would also be needed anyway, even with the alternative). WDYT? | 12:26 |
| carthaca | (Did not want to hijack the happy hour for this discussion, but also did not want to wait for the next weekly ;) ) | 12:27 |
| gouthamr | thanks for sharing that thought carthaca; i think that's feasible - i am concerned about the UX just like you are.. | 14:12 |
| gouthamr | kpdev: what do you think? | 14:12 |
| gouthamr | btw, you can totally get Sai to help with the spec/code update since he's now started thinking more about this | 14:13 |
| kpdev | yes | 14:13 |
| kpdev | If we have single option, how internal implementation will be .. needs to thought of and confirmed either in spec or POC ? | 14:13 |
| gouthamr | yes, lets update teh spec - it calls out all these options so far | 14:14 |
| kpdev | if you guys have thoughts feel free to add on spec. | 14:16 |
| gouthamr | thanks, will do | 14:25 |
| kpdev | we need to consider in future if any use case comes, where encryption can be either share or share server etc. | 14:27 |
| kpdev | we can have keys_per_share_network to restrict share server created using different share server encryption keys. | 14:27 |
| opendevreview | zgoggin proposed openstack/python-manilaclient master: Add support for out of place share backup restores https://review.opendev.org/c/openstack/python-manilaclient/+/947007 | 14:35 |
| msaravan | Thank you for the thoughts. keys_per_share_network quota is fine. The question is : What should we do if user keeps using different encryption key for every share he is creating ? Should we create new share server every time ? Wanted to understand how do we fix this basic use case, and how do we report to the user ? All the discussions happend yesterday are all around this. | 14:51 |
| msaravan | @carthaca @kpdev @gouthamr | 14:52 |
| kpdev | keys_per_share_network is set to 10, user will create at max 10 share servers under share_network using different encryption keys. Otherwise he can create as much as possible. | 15:02 |
| kpdev | setting value to -1, means no limit. | 15:02 |
| kpdev | lets add thoughts on spec | 15:05 |
| msaravan | When it is set to -1, when the user creates a share with different keys, we'll keep creating a brand new share server every time with only one share per share server ? We may eat up lif/vlan limits easily. | 15:41 |
| msaravan | we can discuss more when we meet next week.. | 15:41 |
| msaravan | Do you have any document, which I can go through where we'll create multiple share servers though we use same share network ? In my lab, when I use new share network I always see new share server is created. Pardon my knowledge on this. | 16:41 |
| gouthamr | msaravan et al. was in a few more PTG discussions this week, looking at teh scrollback now to respond | 18:46 |
| gouthamr | > When it is set to -1, when the user creates a share with different keys, we'll keep creating a brand new share server every time with only one share per share server ? We may eat up lif/vlan limits easily. | 18:48 |
| gouthamr | yes, and that should be prevented by the administrator.. -1 is not going to be the default. Default would be something sane, like 5 or 10. i think there's a possibility of this quota being applied per backend or pool too | 18:48 |
| gouthamr | will add this comment back on the spec | 18:48 |
| gouthamr | > In my lab, when I use new share network I always see new share server is created. Pardon my knowledge on this. | 18:50 |
| gouthamr | yes, this is by design.. are you expecting something different? even if the underlying network is the same, if you use a new share network, manila will allocate a new share server for it | 18:50 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!