*** esberglu has joined #openstack-powervm | 00:10 | |
*** esberglu has quit IRC | 00:19 | |
*** esberglu has joined #openstack-powervm | 00:50 | |
*** esberglu has quit IRC | 00:54 | |
*** esberglu has joined #openstack-powervm | 01:05 | |
*** esberglu has quit IRC | 01:09 | |
*** edmondsw has joined #openstack-powervm | 01:16 | |
*** esberglu has joined #openstack-powervm | 01:20 | |
*** edmondsw has quit IRC | 01:20 | |
*** esberglu has quit IRC | 01:30 | |
*** esberglu has joined #openstack-powervm | 01:35 | |
*** esberglu has quit IRC | 01:39 | |
*** AlexeyAbashkin has joined #openstack-powervm | 02:10 | |
*** AlexeyAbashkin has quit IRC | 02:39 | |
*** esberglu has joined #openstack-powervm | 02:49 | |
*** esberglu has quit IRC | 02:54 | |
*** esberglu has joined #openstack-powervm | 03:00 | |
*** edmondsw has joined #openstack-powervm | 03:03 | |
*** esberglu has quit IRC | 03:05 | |
*** edmondsw has quit IRC | 03:08 | |
*** esberglu has joined #openstack-powervm | 03:15 | |
*** esberglu has quit IRC | 03:19 | |
*** esberglu has joined #openstack-powervm | 03:30 | |
*** esberglu has quit IRC | 03:34 | |
*** esberglu has joined #openstack-powervm | 03:45 | |
*** esberglu has quit IRC | 03:49 | |
*** esberglu has joined #openstack-powervm | 04:00 | |
*** esberglu has quit IRC | 04:09 | |
*** esberglu has joined #openstack-powervm | 04:15 | |
*** esberglu has quit IRC | 04:24 | |
*** AlexeyAbashkin has joined #openstack-powervm | 04:32 | |
*** esberglu has joined #openstack-powervm | 04:35 | |
*** esberglu has quit IRC | 04:40 | |
*** esberglu has joined #openstack-powervm | 04:51 | |
*** edmondsw has joined #openstack-powervm | 04:52 | |
*** esberglu has quit IRC | 04:55 | |
*** edmondsw has quit IRC | 04:57 | |
*** esberglu has joined #openstack-powervm | 05:15 | |
*** esberglu has quit IRC | 05:19 | |
*** AlexeyAbashkin has quit IRC | 05:25 | |
*** openstackgerrit has quit IRC | 05:34 | |
*** esberglu has joined #openstack-powervm | 05:35 | |
*** esberglu has quit IRC | 05:40 | |
*** openstackstatus has quit IRC | 05:51 | |
*** openstackstatus has joined #openstack-powervm | 05:53 | |
*** ChanServ sets mode: +v openstackstatus | 05:53 | |
*** esberglu has joined #openstack-powervm | 06:00 | |
*** esberglu has quit IRC | 06:05 | |
*** esberglu has joined #openstack-powervm | 06:15 | |
*** esberglu has quit IRC | 06:23 | |
*** AlexeyAbashkin has joined #openstack-powervm | 06:29 | |
*** esberglu has joined #openstack-powervm | 06:30 | |
*** esberglu has quit IRC | 06:34 | |
*** esberglu has joined #openstack-powervm | 06:40 | |
*** edmondsw has joined #openstack-powervm | 06:40 | |
*** AlexeyAbashkin has quit IRC | 06:41 | |
*** openstackgerrit has joined #openstack-powervm | 06:43 | |
openstackgerrit | Chhavi Agarwal proposed openstack/nova-powervm master: iSCSI volume detach with no UDID https://review.openstack.org/576034 | 06:43 |
---|---|---|
*** esberglu has quit IRC | 06:44 | |
*** edmondsw has quit IRC | 06:46 | |
*** esberglu has joined #openstack-powervm | 06:55 | |
*** esberglu has quit IRC | 06:59 | |
*** esberglu has joined #openstack-powervm | 07:10 | |
*** esberglu has quit IRC | 07:14 | |
*** esberglu has joined #openstack-powervm | 07:25 | |
*** esberglu has quit IRC | 07:29 | |
openstackgerrit | Chhavi Agarwal proposed openstack/nova-powervm master: iSCSI volume detach with no UDID https://review.openstack.org/576034 | 07:33 |
*** esberglu has joined #openstack-powervm | 07:40 | |
*** esberglu has quit IRC | 07:44 | |
*** esberglu has joined #openstack-powervm | 07:55 | |
*** esberglu has quit IRC | 08:00 | |
*** esberglu has joined #openstack-powervm | 08:05 | |
*** esberglu has quit IRC | 08:10 | |
*** esberglu has joined #openstack-powervm | 08:20 | |
*** esberglu has quit IRC | 08:24 | |
*** edmondsw has joined #openstack-powervm | 08:29 | |
*** edmondsw has quit IRC | 08:34 | |
*** esberglu has joined #openstack-powervm | 08:35 | |
*** esberglu has quit IRC | 08:39 | |
*** esberglu has joined #openstack-powervm | 08:50 | |
*** esberglu has quit IRC | 08:54 | |
*** esberglu has joined #openstack-powervm | 09:00 | |
*** esberglu has quit IRC | 09:04 | |
*** esberglu has joined #openstack-powervm | 09:14 | |
*** esberglu has quit IRC | 09:19 | |
*** edmondsw has joined #openstack-powervm | 10:17 | |
*** edmondsw has quit IRC | 10:22 | |
*** edmondsw has joined #openstack-powervm | 12:06 | |
*** edmondsw has quit IRC | 12:11 | |
*** edmondsw has joined #openstack-powervm | 13:01 | |
*** chhagarw has joined #openstack-powervm | 13:04 | |
*** chhavi__ has joined #openstack-powervm | 13:04 | |
*** chhagarw has quit IRC | 13:18 | |
chhavi__ | edmondsw,gman-tx: please have a look at the review https://review.openstack.org/#/c/576034/ | 13:41 |
chhavi__ | lets discuss if we still have any open comments | 13:41 |
chhavi__ | efried: open for review comments and discussion https://review.openstack.org/#/c/576034/ | 13:42 |
edmondsw | chhavi__ what is "re-discovery" ? | 13:43 |
chhavi__ | re-discovery means, in during disconnect_volume call if the udid or device_name is missing, code should first try to check if the volume is available on the VIOS, and try to get the udid. | 13:44 |
edmondsw | why would it ever be missing? | 13:44 |
chhavi__ | so that it can still disconnect | 13:44 |
edmondsw | if we do SaveBDM where that is needed, it should not be missing | 13:45 |
*** esberglu has joined #openstack-powervm | 13:45 | |
chhavi__ | UDID information is something which is cached in BDM by the driver, and BDM information are updated in DB | 13:46 |
chhavi__ | so there are possibilities where BDM information is not re-liable or can wipe away | 13:47 |
chhavi__ | my point is driver should just not only rely on BDM information, and fail to disconnect the volume. | 13:48 |
edmondsw | "so" doesn't follow from your previous sentence | 13:49 |
edmondsw | I am trying to get you to get specific here | 13:50 |
edmondsw | I want a specific explanation of why/when there are possibilities of the BDM information not being reliable | 13:51 |
edmondsw | we should not be making decisions based on vague hand-waving, which is all I've heard so far | 13:51 |
chhavi__ | can't think of any? | 13:59 |
chhavi__ | if the user perform attach and detach of the same volume multiple times, it can happen the BDM information is not updated, and it can provide wrong udid. | 14:05 |
chhavi__ | this can lead BDM to have stale information | 14:05 |
*** shyama has joined #openstack-powervm | 14:07 | |
edmondsw | chhavi__ why can that happen? | 14:12 |
chhavi__ | edmondsw: re-discovery just provide stability to the code during disconnect. | 14:13 |
edmondsw | we're not talking about re-discovery right now | 14:13 |
edmondsw | we're talking about why we wouldn't already know the udid | 14:13 |
edmondsw | it looks like we're already calling SaveBDM in the migration flow... the virt driver's finish_migration method calls _add_volume_connection_tasks, which includes SaveBDM | 14:14 |
edmondsw | so I wonder if we even need to add a new SaveBDM call... I think we may just need to set the UDID in the right place | 14:15 |
edmondsw | so that the SaveBDM saves the right data | 14:15 |
chhavi__ | since we are saving the udid, we will have the udid, but during consecutive attach/detach/lpm, there are chance that BDM information is not updated and have old udid. | 14:15 |
chhavi__ | In that case there is a possibility that BDM is not updated, and so re-discovery will help to get the fresh udid. | 14:16 |
*** gman-tx has joined #openstack-powervm | 14:17 | |
chhavi__ | I am not saying the SaveBDM is not solving our purpose, this is just an extra cushion | 14:17 |
edmondsw | I don't want an extra cushion that we can't think of a reason we would need | 14:18 |
edmondsw | and I haven't heard a reason yet | 14:18 |
edmondsw | what do you mean "old udid"? Doesn't the udid stay the same across lpm and attach/detach? | 14:18 |
chhavi__ | We do have a similar implementation in vSCSI as well | 14:18 |
edmondsw | I don't care about that either | 14:18 |
chhavi__ | For every attach of the volume UDID value can change | 14:19 |
edmondsw | gman-tx was saying udid should stay the same | 14:19 |
gman-tx | explain? | 14:19 |
gman-tx | i think they are suppose to be the same? | 14:19 |
chhavi__ | gman-tx: if the same volume is attach and detach, in that case VIOS will remove the hdisk and re-create the new one, in such cases VIOS can have a new encoded string for the UDID value | 14:21 |
chhavi__ | gman-tx: Can you think of any scenario, where you feel that we can have the stale BDM UDID information, and we should re-fetch from the VIOS again using discovery. | 14:22 |
shyama | chhavi__: if the udid is specific to vios what happens when there is a reschedule | 14:25 |
chhavi__ | Also it is not only UDID value, we are relying on the VIOS response to give us the proper hdisk name based on the udid. Sometimes VIOS wrap response does not have the device_name. So in that case also re-discovery is needed | 14:26 |
chhavi__ | https://review.openstack.org/#/c/576034/9/nova_powervm/virt/powervm/volume/iscsi.py:351 | 14:27 |
chhavi__ | redisovery depends on udid and device_name | 14:27 |
chhavi__ | https://github.com/openstack/nova-powervm/commit/231147fa4d206d14b724647b65e52f7742a654c7 | 14:28 |
chhavi__ | the above commit explains the reason why it was put for the case of vSCSI | 14:29 |
chhavi__ | gman-tx: UDID is vios specific, its a VIOS generated encoded string for the pg83NAA, and VIOS stores UDID and device_name in the wrapped response. | 14:31 |
edmondsw | chhavi__ we're only talking about udid here... the existing code already "rediscovers" device name based on udid | 14:33 |
chhavi__ | So when I say they can vary, because we can have different encoded UDID strings, for the same pg83NAA value. | 14:34 |
gman-tx | I'm verifying the udid with the vios team | 14:34 |
chhavi__ | no we fetch the device_name from the UDID, that is not re-discovery. | 14:35 |
chhavi__ | device_name = vios_w.hdisk_from_uuid(udid) | 14:35 |
chhavi__ | this code retrieves the device_name value from the vios wrapper | 14:35 |
edmondsw | chhavi__ that's what I'm saying | 14:36 |
chhavi__ | https://stackoverflow.com/questions/13449595/can-two-different-base-64-encoded-strings-result-into-same-string-if-decoded | 14:37 |
edmondsw | I was replying to your statement: "Also it is not only UDID value..." | 14:37 |
edmondsw | I'll look at the commit you mentioned once I get off this call, thanks for looking up some history | 14:37 |
chhavi__ | yeah its not only UDID value, its the device_name as well which is needed for disconnect, UDID is just a mechanism to find the device_name. | 14:38 |
chhavi__ | edmondsw: sure | 14:39 |
chhavi__ | gman-tx: udid encoded strings can change if the hdisks are re-created, they can get the new encodedstring. For eg: If the same volume is attach, hdisk1 udid1, detach will remove hdisk1, and re-attach will have hdisk2 which get udid2 string. | 14:41 |
chhavi__ | both udid1 and udid2 can have the same decoded pg83NAA value | 14:42 |
gman-tx | hmm then the udid is worthless | 14:57 |
gman-tx | do you have an example of this? | 14:58 |
*** shyama has quit IRC | 15:00 | |
efried | edmondsw: Are you here today? | 15:31 |
edmondsw | efried yes | 15:31 |
edmondsw | as long as you don't mean "Austin" :) | 15:31 |
efried | edmondsw: Wanted to make sure you at least scanned https://etherpad.openstack.org/p/powervm-device-passthrough before I started coding to it, which I was planning to do soonish. | 15:32 |
edmondsw | I'll bump it up my list | 15:33 |
efried | coo | 15:33 |
chhavi__ | gman-tx: yeah I can show an example, where the vioses can have the different udid encoded string for the same volume. | 16:19 |
*** raopajay has quit IRC | 16:26 | |
*** chhavi__ has quit IRC | 18:58 | |
*** esberglu has quit IRC | 20:15 | |
*** esberglu has joined #openstack-powervm | 20:16 | |
*** esberglu has quit IRC | 20:20 | |
*** gman-tx has quit IRC | 20:22 | |
*** gman-tx has joined #openstack-powervm | 20:43 | |
*** gman-tx has quit IRC | 20:55 | |
*** edmondsw has quit IRC | 21:31 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!