Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
When creating the user-data file for cloud-init, if you include a space in the first line, where you type in "#cloud-config" and instead write "# cloud-config", while the VM will say it has run cloud-init on boot, it won't actually customize anything. My user credentials and hostname were not modified when I had a space in there, and since cloud-init doesn't really run a second time, when I tried to reboot the VM using an updated ISO that removed the space, still nothing was happening. I didn't know that was how cloud-init worked until a coworker mentioned I would need to torch the VM and create a new one to actually test my new cloud-init ISO.
I'm not sure why that causes a fatal error, as in most config files, a # indicates a comment, which should mean that space doesn't matter. If user-data is actually a script, and not a config file, I guess sometimes that extra space can matter, but it would be nice if we were resilient enough to handle the space and still work.
All I know about cloud-init came from our FAQ about it: https://access.redhat.com/articles/rhel-atomic-cloud-init-faq
I've since gotten the example in the FAQ that included a space updated in that doc, but it cost me a fair amount of time to figure out what was going on, I wasn't expecting the space to be the culprit, and thought I was messing up somewhere else in the process.
Comment 2Lars Kellogg-Stedman
2015-01-19 17:10:57 UTC
Cloud-init uses the first line of a file to identify the file type, much like the standard '#!' semantics for scripts under Unix. For example, the following script would fail to execute properly:
#!/usr/bin/python
from sys import stdout
stdout.write('Hello world\n')
If you were to drop that into a file and make it executable, the '#!' line would be ignore because of the space, the system would attempt to execute it with /bin/sh instead, and you would get:
./foo: line 2: from: command not found
./foo: line 3: syntax error near unexpected token `'Hello world\n''
./foo: line 3: `stdout.write('Hello world\n')'
I think that the failure you see from cloud-init is similar in nature and is the appropriate behavior.
The formats accepted by cloud-init are documented upstream in https://cloudinit.readthedocs.org/en/latest/topics/format.html. I'm glad you were able to have our local documentation corrected.