iSCSI volume backend treats FLAGS.host as a hostname

[Ewan Mellor]

The iSCSI nova-volume backend treats FLAGS.host (i.e. --host=<foo> on the command line) as a hostname. However, it is not required that this flag is a hostname (though that is the default). The intention of --host is for that to optionally be an opaque ID, allowing the admin to control the identity of nodes (across rolling upgrade for example).

This means that nova-volume can't assume that FLAGS.host is a hostname or IP address, and it needs to understand its own IP addresses for communication with nova-compute.

[Ewan Mellor (ewanmellor)]

https://review.openstack.org/1982

[Openstack Gerrit (openstack-gerrit)]

Reviewed: https://review.openstack.org/1982
Committed: http://github.com/openstack/nova/commit/f6c74d6563e48df6a8a7ff09a27d812840f23d02
Submitter: Jenkins
Branch: master

 status fixcommitted
 done

commit f6c74d6563e48df6a8a7ff09a27d812840f23d02
Author: Ewan Mellor <email address hidden>
Date: Wed Nov 30 10:34:42 2011 -0800

    Bug #898290: iSCSI volume backend treats FLAGS.host as a hostname

    Change ISCSIDriver to set volume.provider_location during create_export.
    This records the location of the LUN, so that nova-compute does not need
    to run the iSCSI discovery code itself.

    As part of this, include the IP address of the target (--iscsi_ip_address) in
    the provider_location. This means that we don't use volume's host identifier
    (which could be an opaque ID) when trying to connect to the iSCSI target --
    we use the admin-specified IP address instead.

    The string-join to set provider_location is shared with ZadaraBEDriver,
    which was doing something similar. I've brought that into a helper function.

    The docstring for the --host flag has been clarified.

    Change-Id: I8402da86345e786a46a4d222ad4d8a4449d2bd3f