[feature request] iSCSI initiator name export over the relation
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Nova Compute Charm |
New
|
Undecided
|
Unassigned |
Bug Description
== Problem statement
There is neither no way to dynamically generate the iSCSI initiator list somewhere externally, nor change it with some predictable value.
== Rationale
I'm working now on the cloud which has external Huawei OceanStor storage array; and the upstream driver doesn't have a default PortGroup option - it has only the "DefaultTargetIP" option. While the option itself could accept multiple IPs:
text = xml_root.
if text:
iscsi_
ip.strip() for ip in text.split(';') if ip.strip()]
It's still using only the first one supplied, ignoring others:
default_target_ips = self.iscsi_
if default_target_ips:
target_
The only viable approach currently is to use the PortGroup configuration on the storage array side, since it is supported by the driver: https:/
temp_tgt_ips = self._get_
valid_port_info = self._get_
valid_tgt_ips = valid_port_info
for ip in temp_tgt_ips:
if ip in valid_tgt_ips:
From the storage array point of view, PortGroup is a logical grouping of multiple storage controller interfaces, and driver is querying storage array's API to get all of those IPs:
temp_tgt_ips = self._get_
valid_port_info = self._get_
valid_tgt_ips = valid_port_info
for ip in temp_tgt_ips:
if ip in valid_tgt_ips:
This is required in order to let driver initialize multiple iSCSI sessions to the same storage array, enabling the iSCSI multipathing effectively.
However, there is no way to specify a default PortGroup - it could only be specified per-initiator (read: per compute host), requiring an InitiatorName to be provided in the driver config:
"To configure iSCSI Multipathing, follow the steps below:
Add the port group settings in the Huawei-customized driver configuration file and configure the port group name needed by an initiator.
<iSCSI>
<DefaultTarg
<Initiator Name="xxxxxx" TargetPortGroup
</iSCSI>"
Currently, we are workarounding this issue by supplying all of the initiators manually to the charm via the following snippet:
juju run -m openstack --application nova-compute --format=json "sudo cat /etc/iscsi/
However, it would be nice to have an option to create a relation between cinder backend charm and nova-compute to get this information dynamically.