Joint UserData must have a header

[weizhouapache]

With #7643 , joint userdata must have a header, a plain text cannot be used as one of the joint userdata any more.
This breaks backward compatibility while in elder versions userdata can be any string.

• template has linked userdata
• vm has manual entry or appended userdata.

ISSUE TYPE

• Bug Report

COMPONENT NAME

Userdata 

CLOUDSTACK VERSION

4.19

CONFIGURATION

OS / ENVIRONMENT

SUMMARY

STEPS TO REPRODUCE

EXPECTED RESULTS

ACTUAL RESULTS

[mlsorensen]

I thought the header requirement only applied if the underlying template had userdata linked to it.

This could be an issue, as there are appliances that read config from userdata that is in proprietary (or at least non-cloud-init) formats. For example, vASA "Day 0 configuration" has been shown to work with CloudStack by reading day 0 config from config drive.

If it is only an issue for underlying templates linked with userdata, it is probably OK, as the admin of the template has done this, we enforce the VM's additional userdata is compatible with the template's userdata. However, we probably don't want to require header for all userdata.

[weizhouapache]

I thought the header requirement only applied if the underlying template had userdata linked to it.

@mlsorensen
you are right. If there are joint userdata, both should have a header.

In some scenarios, plain-text userdata still works, for example

• only template has linked userdata, but no vm userdata
• only vm has userdata (template does not have linked userdata)

Assume there are two userdata

#!/bin/bash
echo "acs-1"

and

echo "acs-2"

If we use the first as template userdata and the second as manual entry, it works in 4.18 but not in 4.19

This could be an issue, as there are appliances that read config from userdata that is in proprietary (or at least non-cloud-init) formats. For example, vASA "Day 0 configuration" has been shown to work with CloudStack by reading day 0 config from config drive.

If it is only an issue for underlying templates linked with userdata, it is probably OK, as the admin of the template has done this, we enforce the VM's additional userdata is compatible with the template's userdata. However, we probably don't want to require header for all userdata.