Bug 1181727

Summary:	Including a space in first line of user-data seems to cause cloud-init to not fully run
Product:	Red Hat Enterprise Linux 7	Reporter:	Matt Reid <mreid>
Component:	cloud-init	Assignee:	Lars Kellogg-Stedman <lars>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.0
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-01-19 17:10:57 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Matt Reid 2015-01-13 16:42:02 UTC

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 2 Lars 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.