Daniel,
I was aware of DataSourceAzure.py and cc_mounts.py and the fact that
built-in config for Azure requires declaration of "sdb" (and not
"ephemeral0"). The before mentioned fact is only an inconvenience for
users that would like to declare custom mount points and make the
mistake to use an in incorrect reference to the ephemeral disk (i.e. not
declaring "sdb"). The misdeclaration will only result in the ephemeral
disk not being mounted, that should not be a real issue.
However, the above reveals a (minor) bug in cc_mounts.py.
The cfg mnt array in the cc_mounts.py script is sanitized, in such a
fashion that default mounts are only added if other entries do not have
the same device name (see lines 285 - 307).
A declaration of [ sdb, <mount point> ] or [ sdbX, <mount point> ] (in
case of partitions) in custom cloud config settings will not result in
an append of the ephemeral0 default mount (since the device name remains
the same) and that is good.
After all, when declaring [ sdb, <mount point> ] or [ sdbX, <mount
point> ] (in case of partitions), cc_mounts.py will append device
"/dev/sdb" or "/dev/sdbx" (in case of partitions) to the cfg mnt arry,
instead of the default mount declarations for ephemeral0.
This is really cumbersome, when using partitions and certainly when
using swap (dedicated) partitions.
The bug is (in essence) that the sanitizing in cc_mounts.py does not
prevent that the standard alias "/dev/sdb", as specificied in
DataSourceAzure.py, or any other declared aliases will be appended to
the cfg mnt array, which should not occur, if these aliases are pointing
to one and the same ephemeral disk.
The (minor) bug can be easily resolved by sanitizing for aliases in
cc_mounts.py.
I was (also) aware that cc_mounts.py contains the declaration ["swap", "none",
"swap", "sw", "0", "0"] in the default set of mounts and that
DataSourceAzure.py does not have to contain any reference to swap or mount
points thereof.
However, the "accidental" declaration of [ swap, <mount point or "None">
] reveals a bug, that occurs even when a declaration of the form [ sdb,
<mount point> ] is provided in cloud-config settings.
The bug is, in my humble opinion, (solely) related to the following
lines of code in cc_mounts.py:
for line in actlist:
# write 'comment' in the fs_mntops, entry, claiming this
line[3] = "%s,%s" % (line[3], comment)
if line[2] == "swap":
needswap = True
if line[1].startswith("/"):
dirs.append(line[1])
cc_lines.append('\t'.join(line))
with these lines of code stating that any device called swap (or
/dev/swap, since that is the same in cloud-init)
a) will mount, as a result of
if line[1].startswith("/"):
dirs.append(line[1])
if only if
- the declaration is of form [ swap, <mount point> ] AND
- the device called swap actually exists, for instance as a result of the
existence of swap partitions AND
- the swap partition is declared first in the disk_setup cloud-config settings,
b) will not mount, as a result of (taking into account defvals = [None,
None, "auto", "defaults,nobootwait", "0", "2"])
if line[2] == "swap":
needswap = True
if the declaration is of form [ swap, <"None"> ], with the missing
fields hence being replaced by appropriate values from defvals, hence
implying that line[2] == "swap" never applies,
c) will not mount properly, if the declaration is of form [ swap,
<"mount point or None">, swap ],
d) will not mount at all, if the declaration is of form ["swap", "none",
"swap", "sw", "0", "0"], due to sanitizing in cc_mounts.py,
and one could therefore come to the obvious conclusion that the bug is
related to the definition of defvals.
However, the obvious conclusion is not appropriate in this case.
In essence, one should not be able to declare [ swap, <"mount point or
None"> ] (or similar) at all (!).
Furthermore, a declaration for swap only makes sense when using swap
partitions, but swap partitions are not desirable at all.
Moreover, the cloud-init versions 0.7.6 and 0.7.7 already allow for the
creation of swap files.
In short, the bug can and should be resolved by sanitizing (i.e.
ignoring) any declarations of the form [ swap, <mount point> ] and [
swap, <"None"> ] or similar, hence also implying that even the [ swap ]
declaration has no function in case of sanitizing.
In my humble opinion, the "swap" bug can and should be resolved quickly.
Kind regards.....
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to cloud-init in Ubuntu.
https://bugs.launchpad.net/bugs/1410835
Title:
Azure ephemeral disk and custom mount points
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1410835/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
