cloud-init specifies a configdrive is any drive of vfat or iso9660 type, with an openstack folder hierarchy. Our new fallback drive type satisfies these requirements and is detected properly on vanilla cloud-init installs.
However because reasons CoreOS dictates the drive must also have a filesystem label of config-2 even though this should be optional - the result is our fallback drive is not detected or used because it has a label of cidata (to satisfy nocloud requirements).
I think the easiest way forward is a small switch in the cloud-init settings area of the VM deployment page, where users themselves can switch between either a configdrive type or nocloud type. This should allow all users (even users who have changed their deployment rules to accommodate for the new nocloud drive type) to continue working happily, and CoreOS (or other weird implementations of cloud-init) can simply toggle it to the configdrive type before deploying the new VM.
I am probably not much help when it comes to adding the code, but I can add complete documentation outlining what the switch does and when it should be used (eg: switching to nocloud allows the passing of network configuration, but the cloud-init install must be able to accept nocloud drive types. Select configdrive for CoreOS)
cloud-init specifies a
configdrive
is any drive of vfat or iso9660 type, with an openstack folder hierarchy. Our new fallback drive type satisfies these requirements and is detected properly on vanilla cloud-init installs.However because reasons CoreOS dictates the drive must also have a filesystem label of
config-2
even though this should be optional - the result is our fallback drive is not detected or used because it has a label ofcidata
(to satisfy nocloud requirements).I think the easiest way forward is a small switch in the cloud-init settings area of the VM deployment page, where users themselves can switch between either a
configdrive
type ornocloud
type. This should allow all users (even users who have changed their deployment rules to accommodate for the new nocloud drive type) to continue working happily, and CoreOS (or other weird implementations of cloud-init) can simply toggle it to theconfigdrive
type before deploying the new VM.I am probably not much help when it comes to adding the code, but I can add complete documentation outlining what the switch does and when it should be used (eg: switching to nocloud allows the passing of network configuration, but the cloud-init install must be able to accept nocloud drive types. Select
configdrive
for CoreOS)