Thursday, 2018-06-28

*** esberglu has joined #openstack-powervm00:10
*** esberglu has quit IRC00:19
*** esberglu has joined #openstack-powervm00:50
*** esberglu has quit IRC00:54
*** esberglu has joined #openstack-powervm01:05
*** esberglu has quit IRC01:09
*** edmondsw has joined #openstack-powervm01:16
*** esberglu has joined #openstack-powervm01:20
*** edmondsw has quit IRC01:20
*** esberglu has quit IRC01:30
*** esberglu has joined #openstack-powervm01:35
*** esberglu has quit IRC01:39
*** AlexeyAbashkin has joined #openstack-powervm02:10
*** AlexeyAbashkin has quit IRC02:39
*** esberglu has joined #openstack-powervm02:49
*** esberglu has quit IRC02:54
*** esberglu has joined #openstack-powervm03:00
*** edmondsw has joined #openstack-powervm03:03
*** esberglu has quit IRC03:05
*** edmondsw has quit IRC03:08
*** esberglu has joined #openstack-powervm03:15
*** esberglu has quit IRC03:19
*** esberglu has joined #openstack-powervm03:30
*** esberglu has quit IRC03:34
*** esberglu has joined #openstack-powervm03:45
*** esberglu has quit IRC03:49
*** esberglu has joined #openstack-powervm04:00
*** esberglu has quit IRC04:09
*** esberglu has joined #openstack-powervm04:15
*** esberglu has quit IRC04:24
*** AlexeyAbashkin has joined #openstack-powervm04:32
*** esberglu has joined #openstack-powervm04:35
*** esberglu has quit IRC04:40
*** esberglu has joined #openstack-powervm04:51
*** edmondsw has joined #openstack-powervm04:52
*** esberglu has quit IRC04:55
*** edmondsw has quit IRC04:57
*** esberglu has joined #openstack-powervm05:15
*** esberglu has quit IRC05:19
*** AlexeyAbashkin has quit IRC05:25
*** openstackgerrit has quit IRC05:34
*** esberglu has joined #openstack-powervm05:35
*** esberglu has quit IRC05:40
*** openstackstatus has quit IRC05:51
*** openstackstatus has joined #openstack-powervm05:53
*** ChanServ sets mode: +v openstackstatus05:53
*** esberglu has joined #openstack-powervm06:00
*** esberglu has quit IRC06:05
*** esberglu has joined #openstack-powervm06:15
*** esberglu has quit IRC06:23
*** AlexeyAbashkin has joined #openstack-powervm06:29
*** esberglu has joined #openstack-powervm06:30
*** esberglu has quit IRC06:34
*** esberglu has joined #openstack-powervm06:40
*** edmondsw has joined #openstack-powervm06:40
*** AlexeyAbashkin has quit IRC06:41
*** openstackgerrit has joined #openstack-powervm06:43
openstackgerritChhavi Agarwal proposed openstack/nova-powervm master: iSCSI volume detach with no UDID  https://review.openstack.org/57603406:43
*** esberglu has quit IRC06:44
*** edmondsw has quit IRC06:46
*** esberglu has joined #openstack-powervm06:55
*** esberglu has quit IRC06:59
*** esberglu has joined #openstack-powervm07:10
*** esberglu has quit IRC07:14
*** esberglu has joined #openstack-powervm07:25
*** esberglu has quit IRC07:29
openstackgerritChhavi Agarwal proposed openstack/nova-powervm master: iSCSI volume detach with no UDID  https://review.openstack.org/57603407:33
*** esberglu has joined #openstack-powervm07:40
*** esberglu has quit IRC07:44
*** esberglu has joined #openstack-powervm07:55
*** esberglu has quit IRC08:00
*** esberglu has joined #openstack-powervm08:05
*** esberglu has quit IRC08:10
*** esberglu has joined #openstack-powervm08:20
*** esberglu has quit IRC08:24
*** edmondsw has joined #openstack-powervm08:29
*** edmondsw has quit IRC08:34
*** esberglu has joined #openstack-powervm08:35
*** esberglu has quit IRC08:39
*** esberglu has joined #openstack-powervm08:50
*** esberglu has quit IRC08:54
*** esberglu has joined #openstack-powervm09:00
*** esberglu has quit IRC09:04
*** esberglu has joined #openstack-powervm09:14
*** esberglu has quit IRC09:19
*** edmondsw has joined #openstack-powervm10:17
*** edmondsw has quit IRC10:22
*** edmondsw has joined #openstack-powervm12:06
*** edmondsw has quit IRC12:11
*** edmondsw has joined #openstack-powervm13:01
*** chhagarw has joined #openstack-powervm13:04
*** chhavi__ has joined #openstack-powervm13:04
*** chhagarw has quit IRC13: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 comments13:41
chhavi__efried: open for review comments and discussion https://review.openstack.org/#/c/576034/13:42
edmondswchhavi__ 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
edmondswwhy would it ever be missing?13:44
chhavi__so that it can still disconnect13:44
edmondswif we do SaveBDM where that is needed, it should not be missing13:45
*** esberglu has joined #openstack-powervm13:45
chhavi__UDID information is something which is cached in BDM by the driver, and BDM information are updated in DB13:46
chhavi__so there are possibilities where BDM information is not re-liable or can wipe away13: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 sentence13:49
edmondswI am trying to get you to get specific here13:50
edmondswI want a specific explanation of why/when there are possibilities of the BDM information not being reliable13:51
edmondswwe should not be making decisions based on vague hand-waving, which is all I've heard so far13: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 information14:05
*** shyama has joined #openstack-powervm14:07
edmondswchhavi__ why can that happen?14:12
chhavi__edmondsw: re-discovery just provide stability to the code during disconnect.14:13
edmondswwe're not talking about re-discovery right now14:13
edmondswwe're talking about why we wouldn't already know the udid14:13
edmondswit 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 SaveBDM14:14
edmondswso 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 place14:15
edmondswso that the SaveBDM saves the right data14: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-powervm14:17
chhavi__I am not saying the SaveBDM is not solving our purpose, this is just an extra cushion14:17
edmondswI don't want an extra cushion that we can't think of a reason we would need14:18
edmondswand I haven't heard a reason yet14:18
edmondswwhat 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 well14:18
edmondswI don't care about that either14:18
chhavi__For every attach of the volume UDID value can change14:19
edmondswgman-tx was saying udid should stay the same14:19
gman-txexplain?14:19
gman-txi 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 value14: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
shyamachhavi__: if the udid is specific to vios what happens when there is a reschedule14: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 needed14:26
chhavi__https://review.openstack.org/#/c/576034/9/nova_powervm/virt/powervm/volume/iscsi.py:35114:27
chhavi__redisovery depends on udid and device_name14:27
chhavi__https://github.com/openstack/nova-powervm/commit/231147fa4d206d14b724647b65e52f7742a654c714:28
chhavi__the above commit explains the reason why it was put for the case of vSCSI14: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
edmondswchhavi__ we're only talking about udid here... the existing code already "rediscovers" device name based on udid14: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-txI'm verifying the udid with the vios team14: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 wrapper14:35
edmondswchhavi__ that's what I'm saying14:36
chhavi__https://stackoverflow.com/questions/13449595/can-two-different-base-64-encoded-strings-result-into-same-string-if-decoded14:37
edmondswI was replying to your statement: "Also it is not only UDID value..."14:37
edmondswI'll look at the commit you mentioned once I get off this call, thanks for looking up some history14: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: sure14: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 value14:42
gman-txhmm then the udid is worthless14:57
gman-txdo you have an example of this?14:58
*** shyama has quit IRC15:00
efriededmondsw: Are you here today?15:31
edmondswefried yes15:31
edmondswas long as you don't mean "Austin" :)15:31
efriededmondsw: 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
edmondswI'll bump it up my list15:33
efriedcoo15: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 IRC16:26
*** chhavi__ has quit IRC18:58
*** esberglu has quit IRC20:15
*** esberglu has joined #openstack-powervm20:16
*** esberglu has quit IRC20:20
*** gman-tx has quit IRC20:22
*** gman-tx has joined #openstack-powervm20:43
*** gman-tx has quit IRC20:55
*** edmondsw has quit IRC21:31

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