no reliable way to boot from iscsi root

Just an observation that maybe the /dev/disk-by-path stuff is a useful way of describing what you want to boot reliably

for me in my test setup I have:
ip-192.168.122.10:3260-iscsi-iqn.2008-09.com.example:server1.share1-lun1-part1

as one of the names in there; certainly the iscsi iqn seems not an unreasonable way to identify what you want to boot from.
Including the IP is probably more questionable, given you probably want to multipath and cope with booting when all but 1 path is down.

Thanks to Dave's comment above, I successfully booted a precise ephemeral image with the following patch applied to maas:
--- /usr/share/pyshared/provisioningserver/kernel_opts.py.dist 2013-01-31 15:43:30.419250392 -0500
+++ /usr/share/pyshared/provisioningserver/kernel_opts.py 2013-01-31 15:49:09.991260224 -0500
@@ -136,7 +136,9 @@
             # in the initramfs.
             "ip=::::%s:BOOTIF" % params.hostname,
             # cloud-images have this filesystem label.
- "ro root=LABEL=cloudimg-rootfs",
+ "ro root=/dev/disk/by-path/ip-%s:%s-iscsi-%s:%s-lun-1" % (
+ params.fs_host, "3260", ISCSI_TARGET_NAME_PREFIX,
+ get_ephemeral_name(params.release, params.arch)),
             # Read by overlayroot package.
             "overlayroot=tmpfs",
             # Read by cloud-init.

Basically, that ends up with a cmdline like:
nomodeset iscsi_target_name=iqn.2004-05.com.ubuntu:maas:maas-precise-daily-amd64-ephemeral-20130107 iscsi_target_ip=10.98.191.16 iscsi_target_port=3260 iscsi_initiator=maas-enlist ip=::::maas-enlist:BOOTIF ro root=/dev/disk/by-path/ip-10.98.191.16:3260-iscsi-iqn.2004-05.com.ubuntu:maas:maas-precise-daily-amd64-ephemeral-20130107-lun-1 overlayroot=tmpfs cloud-config-url=http://10.98.191.16/MAAS/metadata/latest/enlist-preseed/?op=get_enlist_preseed log_host=10.98.191.16 log_port=514 -- console=ttyS0,115200 initrd=amd64/generic/precise/commissioning/initrd.gz BOOT_IMAGE=amd64/generic/precise/commissioning/linux BOOTIF=01-52-54-00-06-e4-d5

This may well be sufficent for our needs.

It also worked for a quantal image (I was concerned that the path in by-path might not be reliable across kernels, but at least precise -> quantal kernels, it is).

For some context wrt maas. We hit an issue when were were booting the ephemeral environment to do installation (or commissioning) but the system had previously been booted and installed into a cloud image. Thus, local disk and iscsi both had LABEL=cloudimg-rootfs.

Hi Scott,
  When does that expansion of the parameter set get run - is it boot time or when you build the initrd image?
I don't know how maas works, but I'm just wondering if you can rely on the IP of the storage server to stay the same.

I'm not really sure when it gets run. Heres the time-line I'm generally familiar with. The parties involved are kernel, udev, initramfs-tools and open-iscsi's local-top hook (/usr/share/initramfs-tools/scripts/local-top/iscsi).

a. initramfs is built
b. kernel boot with set of command line parameters
c. initramfs calls 'local-top' scripts (see initramfs-tools(8))
d. open-iscsi reads kernel parameters, and if parameters are there,
   i. starts networking
   ii. sets up the iscsi target device
e. something (I'm pretty sure its udev) puts an entry into /dev/by-path for this new device that the kernel knows about. [1]
f. initramfs code takes over again, and calls 'mountroot' which does 'wait-for-root'. wait-for-root blocks for up to 30 seconds for the provided ROOT= device to appear.

We do block for up to 30 seconds, and also there is 'wait_for_udev', so there should not be any race involved in using this.

So, if the path is consistent/reliable, then this seem safe to me.

--
[1] https://wiki.archlinux.org/index.php/Persistent_block_device_naming#by-id_and_by-path

The thing is I'd not necessarily expect the path to be stable; as I said in comment 2, I'd expect the iqn to be
stable, but I wouldn't bet on the IP of the SAN staying stable - it's normal for a SAN to have multiple IPs for multiple controllers
etc, and by the magic of multipath stuff often moves around.

Your line of:

            "ro root=/dev/disk/by-path/ip-%s:%s-iscsi-%s-lun-1" % (
                params.fs_host, "3260", tname

is thus OK if the IP address %s is expanded inside the initramfs at boot time to see where it's connection is currently coming from, but it's not safe if that expansion is done when the initramfs is built; and I don't understand the python or the script your modifying to know which of those happens.