Ephemeral disk volume was not mounted after resizing from non-ephemeral flavor

[Yang Youseok]

Description
===========
After resizing from m1.flavor(no ephemeral disk) to d1.flavor(with ephemeral disk), ephemeral
disk does not mounted on the VM.

After digging the related code, I realize there is no action to re-run cloudinit's mount module.
By default, cloudinit does not rerun previously running module. Since mount module does not take action, cloudinit does not write ephemeral disk data to /etc/fstab.

Steps to reproduce
==================
1. Make VM with m1.small flavor which does not have ephemeral disk
2. Resize VM with d1.small flavor which have ephemeral disk

Expected result
===============
1. Ephemeral disk volume (/dev/sdb) was mounted at /mnt

Actual result
=============
1. There is /dev/sdb in there by 'lsblk', but not mounted

Environment
===========
Stable/ocata
Libvirt driver

Logs & Configs
==============

[Artom Lifshitz (notartom)]

I don't think this is Nova's responsibility - as long as the new block device shows up with `lsblk`, it's up to the guest OS/tooling to mount it (or not). I've changed the component to cloud-init in case there's something actionable for them in this bug. Thanks!

[Yang Youseok (ileixe)]

As far as I know, cloud-init does not rerun the module which was completed. So if there is nothing to re-launch the action(Nova maybe for this role), I think cloud-init could nothing to do.

[Dan Watkins (oddbloke)]

Hi Yang,

On the face of it, this is something that we would _like_ to support in cloud-init. Could you run `cloud-init collect-logs` on a post-resize instance and attach the output to the bug so we can determine how feasible we think it would be? Once you've done so, please set the status back to New.

Thanks! (And thanks to Artom for reassigning the bug!)

Dan

[Launchpad Janitor (janitor)]

[Expired for cloud-init because there has been no activity for 60 days.]

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3372