Open Stack

Hello Gorka,

On 2017/10/02 20:37, Gorka Eguileor wrote:
> On 02/10, Rikimaru Honjo wrote:
>> Hello,
>>
>> I'd like to discuss about the following bug of os-brick.
>>
>> * os-brick's iscsi initiator unexpectedly reverts node.startup from "automatic" to "manual".
>>    https://bugs.launchpad.net/os-brick/+bug/1670237
>>
>> The important point of this bug is:
>>
>> When os-brick initializes iscsi connections:
>> 1. os-brick will run "iscsiadm -m discovery" command if we use iscsi multipath.
> 
> This only happens with a small number of cinder drivers, since most
> drivers try to avoid the discovery path due to the number of
> disadvantages it presents for a reliable deployment.  The most notorious
> issue is that the path to the discovery portal on the attaching node is
> down you cannot attach the volume no matter how many of the other paths
> are up.
> 
> 
> 
>> 2. os-brick will update node.startup values to "automatic" if we use iscsi.
>> 3. "iscsiadm -m discovery" command will recreate iscsi node repositories.[1]
>>     As a result, node.startup values of already attached volumes will be revert
>>     to default(=manual).
>>
>> Gorka Eguileor and I discussed how do I fix this bug[2].
>> Our idea is this:
>>
>> 1. Confirm node.startup values of all the iscsi targets before running discovery.
>> 2. Re-update node.startup values of all the iscsi targets after running discovery.
>>
>> But, I afraid that this operation will take a long time.
>> I ran showing & updating node.startup values 100 times for researching.
>> As a result, it took about 4 seconds.
>> When I ran 200 times, it took about 8 seconds.
>> I think this is a little long.
>>
>> If we use multipath and attach 25 volumes, 100 targets will be created.
>> I think that updating 100 times is a possible use case.
>>
>> How do you think about it?
>> Can I implement the above idea?
>>
> 
> The approach I proposed is on the review is valid, the flaw is in the
> specific implementation, you are doing 100 request where 4 would
> suffice.
> 
> You don't need to do a request for each target-portal tuple, you only
> need to do 1 request per portal, which reduces the number of calls to
> iscsiadm from 100 to 4 in the case you mention.
> 
> You can check all targets for an IP with:
>    iscsiadm -m node -p IP
> 
> This means that the performance hit from having 100 or 200 targets
> should be negligible.

I have one question.

I can see node.startup values by 1 request per portal as you said.

But, may I update values by 1 request per portal?
Updating values has been done by 1 request per target until now.
So I think my patch should update values in same way(=1 request per target).

> Cheers,
> Gorka.
> 
> 
> 
>> [1]This is correct behavior of iscsiadm.
>>     https://github.com/open-iscsi/open-iscsi/issues/58#issuecomment-325528315
>> [2]https://bugs.launchpad.net/os-brick/+bug/1670237
>> --
>> _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>> Rikimaru Honjo
>> E-mail:honjo.rikimaru at po.ntt-tx.co.jp
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 

-- 
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
★社名とメールアドレスが変わりました。

NTTテクノクロス株式会社
クラウド&セキュリティ事業部 第二事業ユニット（CS2BU）
本上力丸
TEL.  :045-212-7539
E-mail:honjo.rikimaru at po.ntt-tx.co.jp
〒220-0012
   横浜市西区みなとみらい4丁目4番5号
   横浜アイマークプレイス 13階