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:[email protected]
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
★社名とメールアドレスが変わりました。
NTTテクノクロス株式会社
クラウド&セキュリティ事業部 第二事業ユニット（CS2BU）
本上力丸
TEL. :045-212-7539
E-mail:[email protected]
〒220-0012
横浜市西区みなとみらい4丁目4番5号
横浜アイマークプレイス 13階
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
