*** tosky has quit IRC | 00:18 | |
*** enriquetaso has quit IRC | 00:24 | |
*** brinzhang has joined #openstack-manila | 00:27 | |
*** brinzhang has quit IRC | 00:28 | |
*** brinzhang_ has quit IRC | 00:30 | |
*** jcollin has quit IRC | 00:57 | |
openstackgerrit | haixin proposed openstack/python-manilaclient master: Support query user message by timestamp https://review.opendev.org/708807 | 06:13 |
---|---|---|
*** tosky has joined #openstack-manila | 08:21 | |
openstackgerrit | Maari Tamm proposed openstack/python-manilaclient master: Add functional tests for OSC https://review.opendev.org/707577 | 08:26 |
openstackgerrit | Maari Tamm proposed openstack/python-manilaclient master: Implement OSC share type commands https://review.opendev.org/701229 | 09:27 |
*** trident has quit IRC | 10:31 | |
*** trident has joined #openstack-manila | 10:34 | |
*** enriquetaso has joined #openstack-manila | 12:59 | |
*** brinzhang has joined #openstack-manila | 13:20 | |
*** jmlowe has joined #openstack-manila | 13:28 | |
*** toabctl has quit IRC | 13:38 | |
*** jvisser has joined #openstack-manila | 14:59 | |
*** danielarthurt has joined #openstack-manila | 16:52 | |
dviroel | ping danielarthurt | 16:53 |
danielarthurt | https://www.irccloud.com/pastebin/7eNOfcq9/ | 17:01 |
dviroel | danielarthurt 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 |
dviroel | this 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 |
dviroel | unless we start to accept both exceptions for the same scenario, that may be weird also | 17:09 |
*** tosky has quit IRC | 17:09 | |
dviroel | any thoughts on this ^ gouthamr tbarron | 17:09 |
gouthamr | danielarthurt 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-L715 | 17:12 |
dviroel | but 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 |
danielarthurt | And the shrinking operations does not happens, so it's not possible to have a lost data. | 17:22 |
gouthamr | yes ^ | 17:23 |
dviroel | If 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 |
gouthamr | so, we're _currently_ using this exception to set the share instance to "share_shrinking_possible_data_loss_error" - but this can be changed | 17:24 |
gouthamr | dviroel: +1, and any driver not implementing this validation | 17:24 |
danielarthurt | @dviroel +1 | 17:25 |
openstackgerrit | Andre Luiz Beltrami Rocha proposed openstack/manila master: Create share from snapshot in another pool or backend https://review.opendev.org/709697 | 17:25 |
tbarron | so the idea is to just stop saying telling the user there is possible data loss but still call it that internally? | 17:27 |
dviroel | If any driver wants to report a shrink_error, just need to raise ShareShrinkingError | 17:27 |
dviroel | and this will lead the share to 'shrinking_error' | 17:28 |
tbarron | ok, and change tests ^^^ | 17:28 |
gouthamr | dviroel: i'd prefer they just stuck to raising a sub-class of "ShareBackendException" - provides more uniformity | 17:29 |
gouthamr | no drivers are currently raising "ShareShrinkingError" .. | 17:30 |
gouthamr | tbarron: 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 size | 17:31 |
dviroel | ^true | 17:31 |
tbarron | i'm a little worried about just having the user message rather than a new state | 17:32 |
gouthamr | and that the operation was not performed to prevent data loss | 17:32 |
gouthamr | tbarron: a new status will render the share unusable for any other management operation | 17:32 |
tbarron | Will share owners really know their shrink operation failed? | 17:32 |
gouthamr | tbarron: we'll need to clarify this behavior in doc i suppose | 17:33 |
tbarron | do we handle other failures that way? | 17:33 |
dviroel | tbarron: its a cons, but let the share unusable is also a bad thing | 17:33 |
gouthamr | tbarron: if the size is unchanged, the shrink operation hasn't succeeded | 17:33 |
tbarron | correct | 17:33 |
tbarron | the operation failed | 17:33 |
tbarron | what do we do when growing a share fails? | 17:34 |
tbarron | on the back end, not b/c of a quota check, etc. | 17:34 |
gouthamr | tbarron: extending_error, analogous to shrinking_error | 17:35 |
tbarron | is the share usable after that? do we make it available after extendiing error? | 17:35 |
gouthamr | tbarron: ^ but these two apply only to cases where shrinking or extending failed, and we don't know if the share is usable | 17:35 |
tbarron | we should treat them in parallel fashion, no? | 17:36 |
gouthamr | this class of errors should be rare - but, the share can be perfectly usable | 17:36 |
dviroel | then we also need a different exception for extend, to identify drivers errors (share unusable) or operation refused. | 17:39 |
danielarthurt | dviroel: This is a good idea | 17:40 |
dviroel | do we agree with a proposal? | 18:28 |
dviroel | danielarthurt is looking forward to fix this. | 18:29 |
*** enriquetaso has quit IRC | 21:09 | |
gouthamr | dviroel: late ack, seems like we're in agreement, | 21:28 |
dviroel | Awesome, danielarthurt will help us with this | 21:36 |
*** sfernand has quit IRC | 22:11 | |
*** danielarthurt has quit IRC | 22:12 | |
*** tosky has joined #openstack-manila | 22:24 | |
*** jmlowe has quit IRC | 23:00 | |
*** jmlowe has joined #openstack-manila | 23:03 | |
*** jvisser has quit IRC | 23:41 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!