Friday, 2020-02-28

*** tosky has quit IRC00:18
*** enriquetaso has quit IRC00:24
*** brinzhang has joined #openstack-manila00:27
*** brinzhang has quit IRC00:28
*** brinzhang_ has quit IRC00:30
*** jcollin has quit IRC00:57
openstackgerrithaixin proposed openstack/python-manilaclient master: Support query user message by timestamp  https://review.opendev.org/70880706:13
*** tosky has joined #openstack-manila08:21
openstackgerritMaari Tamm proposed openstack/python-manilaclient master: Add functional tests for OSC  https://review.opendev.org/70757708:26
openstackgerritMaari Tamm proposed openstack/python-manilaclient master: Implement OSC share type commands  https://review.opendev.org/70122909:27
*** trident has quit IRC10:31
*** trident has joined #openstack-manila10:34
*** enriquetaso has joined #openstack-manila12:59
*** brinzhang has joined #openstack-manila13:20
*** jmlowe has joined #openstack-manila13:28
*** toabctl has quit IRC13:38
*** jvisser has joined #openstack-manila14:59
*** danielarthurt has joined #openstack-manila16:52
dviroelping danielarthurt16:53
danielarthurthttps://www.irccloud.com/pastebin/7eNOfcq9/17:01
dviroeldanielarthurt is proposing to raise new exception inside shrink_share, instead of shrink_error_possible_data_loss and treat this in the manager by not setting the share to an error state.17:06
dviroelthis will bring some problems because we'll need to fix the scenario test,  and drivers that raises 'error_possible_data_loss' will start to fail.17:08
dviroelunless we start to accept both exceptions for the same scenario, that may be weird also17:09
*** tosky has quit IRC17:09
dviroelany thoughts on this ^ gouthamr tbarron17:09
gouthamrdanielarthurt dviroel: re: "a new type of exception (e.g. ShinkRefused)", we have an exception for this: https://opendev.org/openstack/manila/src/commit/14d3e268a05265db53b5cfd19d9a85a3ba73a271/manila/exception.py#L712-L71517:12
dviroelbut this was something that we were discussing, this exception is being used to lead the  share-instance to an error, meaning that the  share might be in invalid state at the back end.17:20
danielarthurtAnd the shrinking operations does not happens, so it's not possible to have a lost data.17:22
gouthamryes ^17:23
dviroelIf we consider the ShareShrinkingPossibleDataLoss as a rejection from the driver side, without affecting the share, we need to fix the share manager only.17:24
gouthamrso, we're _currently_ using this exception to set the share instance to "share_shrinking_possible_data_loss_error" - but this can be changed17:24
gouthamrdviroel: +1, and any driver not implementing this validation17:24
danielarthurt@dviroel +117:25
openstackgerritAndre Luiz Beltrami Rocha proposed openstack/manila master: Create share from snapshot in another pool or backend  https://review.opendev.org/70969717:25
tbarronso the idea is to just stop saying telling the user there is possible data loss but still call it that internally?17:27
dviroelIf any driver wants to report a shrink_error, just need to raise ShareShrinkingError17:27
dviroeland this will lead the share to 'shrinking_error'17:28
tbarronok, and change tests ^^^17:28
gouthamrdviroel: i'd prefer they just stuck to raising a sub-class of "ShareBackendException" - provides more uniformity17:29
gouthamrno drivers are currently raising "ShareShrinkingError" ..17:30
gouthamrtbarron: yes, we'd transition the share status to "available" and create an asynchronous user message saying that the consumed space is more than the requested new size17:31
dviroel^true17:31
tbarroni'm a little worried about just having the user message rather than a new state17:32
gouthamrand that the operation was not performed to prevent data loss17:32
gouthamrtbarron: a new status will render the share unusable for any other management operation17:32
tbarronWill share owners really know their shrink operation failed?17:32
gouthamrtbarron: we'll need to clarify this behavior in doc i suppose17:33
tbarrondo we handle other failures that way?17:33
dviroeltbarron: its a cons, but let the share unusable is also a bad thing17:33
gouthamrtbarron: if the size is unchanged, the shrink operation hasn't succeeded17:33
tbarroncorrect17:33
tbarronthe operation failed17:33
tbarronwhat do we do when growing a share fails?17:34
tbarronon the back end, not b/c of a quota check, etc.17:34
gouthamrtbarron: extending_error, analogous to shrinking_error17:35
tbarronis the share usable after that?  do we make it available after extendiing error?17:35
gouthamrtbarron: ^ but these two apply only to cases where shrinking or extending failed, and we don't know if the share is usable17:35
tbarronwe should treat them in parallel fashion, no?17:36
gouthamrthis class of errors should be rare - but, the share can be perfectly usable17:36
dviroelthen we also need a  different exception for extend, to identify drivers errors (share unusable) or operation refused.17:39
danielarthurtdviroel: This is a good idea17:40
dviroeldo we agree with a proposal?18:28
dviroeldanielarthurt is looking forward to fix this.18:29
*** enriquetaso has quit IRC21:09
gouthamrdviroel: late ack, seems like we're in agreement,21:28
dviroelAwesome, danielarthurt will help us with this21:36
*** sfernand has quit IRC22:11
*** danielarthurt has quit IRC22:12
*** tosky has joined #openstack-manila22:24
*** jmlowe has quit IRC23:00
*** jmlowe has joined #openstack-manila23:03
*** jvisser has quit IRC23:41

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!