This bug was originally filed in Launchpad as LP: #709946

affected_projects = []
assignee = smoser
assignee_name = Scott Moser
date_closed = 2011-10-28T02:18:48.331523+00:00
date_created = 2011-01-29T23:37:35.064179+00:00
date_fix_committed = 2011-02-01T15:58:00.727778+00:00
date_fix_released = 2011-10-28T02:18:48.331523+00:00
id = 709946
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/709946
milestone = None
owner = rlane
owner_name = Ryan Lane
private = False
status = fix_released
submitter = rlane
submitter_name = Ryan Lane
tags = []
duplicates = []

Launchpad user Ryan Lane(rlane) wrote on 2011-01-29T23:37:35.064179+00:00

Values for puppet configuration options are generally not wrapped in quotes, and wrapping quotes around certain values actually causes puppet runs to fail. configtimeout, for instance, causes puppet runs to fail if its value is wrapped in quotes.

This bug was originally filed in Launchpad as LP: #714807

affected_projects = ['cloud-init (Ubuntu)']
assignee = None
assignee_name = None
date_closed = 2011-06-15T18:08:27.793713+00:00
date_created = 2011-02-07T20:05:02.180053+00:00
date_fix_committed = 2011-06-15T18:08:27.793713+00:00
date_fix_released = 2011-06-15T18:08:27.793713+00:00
id = 714807
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/714807
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = fix_released
submitter = smoser
submitter_name = Scott Moser
tags = ['apport-bug', 'ec2-images', 'i386', 'natty']
duplicates = []

Launchpad user Scott Moser(smoser) wrote on 2011-02-07T20:05:02.180053+00:00

Binary package hint: cloud-init

In bug 635188 I made the situation much better for installation of cloud-init on non-cloud instances.

However, it is still broken if you install on a system that does not have eth0 set up.
That is due to /etc/init/cloud-init.conf and the following upstart blob:
| start on (mounted MOUNTPOINT=/ and net-device-up IFACE=eth0 and
| stopped cloud-init-local )

That ends up causing all of boot to wait indefinitely until IFACE=eth0 is up.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: cloud-init 0.6.0-0ubuntu4
ProcVersionSignature: User Name 2.6.38-2.29-virtual 2.6.38-rc3
Uname: Linux 2.6.38-2-virtual i686
Architecture: i386
Date: Mon Feb 7 19:56:42 2011
Ec2AMI: ami-0e6b9b67
Ec2AMIManifest: (unknown)
Ec2AvailabilityZone: us-east-1c
Ec2InstanceType: t1.micro
Ec2Kernel: aki-407d9529
Ec2Ramdisk: unavailable
PackageArchitecture: all
ProcEnviron:
PATH=(custom, user)
LANG=en_US.UTF-8
LC_MESSAGES=en_US.utf8
SHELL=/bin/bash
SourcePackage: cloud-init

This bug was originally filed in Launchpad as LP: #720440

affected_projects = ['cloud-init (Ubuntu)']
assignee = smoser
assignee_name = Scott Moser
date_closed = 2011-10-28T02:21:04.258562+00:00
date_created = 2011-02-16T23:15:12.542389+00:00
date_fix_committed = 2011-02-17T21:44:39.065806+00:00
date_fix_released = 2011-10-28T02:21:04.258562+00:00
id = 720440
importance = low
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/720440
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = fix_released
submitter = jepst79
submitter_name = John Baptist
tags = []
duplicates = []

Launchpad user John Baptist(jepst79) wrote on 2011-02-16T23:15:12.542389+00:00

Binary package hint: cloud-init

The /etc/cloud/templates/ contains templates which are used to update various configuration files in response to changing cloud metadata. The files /etc/apt/sources.list and /etc/default/locale are updated in this manner. However, the file /etc/cloud/templates/hosts.tmpl, which should be a template for /etc/hosts, is ignored. Changes to this files, followed by reboots or calls to cloud-init will not result in changes to /etc/hosts. This is especially problematic, because it's important to update the /etc/hosts files so that the cloud can refer to itself by its own hostname.

I'm testing this on Ubuntu 10.04.2, using cloud-init 0.5.10-0ubuntu1.5, but the problem persists even on cloud-init version 0.6.0.

This bug was originally filed in Launchpad as LP: #675711

affected_projects = ['cloud-init (Ubuntu)']
assignee = smoser
assignee_name = Scott Moser
date_closed = 2011-01-27T00:36:32.498253+00:00
date_created = 2010-11-15T19:43:53.830580+00:00
date_fix_committed = 2011-01-27T00:36:32.498253+00:00
date_fix_released = 2011-01-27T00:36:32.498253+00:00
id = 675711
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/675711
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = fix_released
submitter = smoser
submitter_name = Scott Moser
tags = ['apport-bug', 'ec2-images', 'i386', 'maverick']
duplicates = []

Launchpad user Scott Moser(smoser) wrote on 2010-11-15T19:43:53.830580+00:00

Binary package hint: cloud-init

As reported at [1], there if a instance is launched with a user data script (--user-data-file that has '#!'), then that script will persist across a rebundle and be run on first boot after the rebundle. That is not the desired behavior.

This problem probably exists with runcmd commands also (via cloud-config syntax).

For simplicity, I copied the report here:

| IMHO there is still a problem. It might be a feature though that I never understood.
| I start an AWS micro instance (EBS based obviously) instance with userdata:
|
| #!/bin/bash
| date > /tmp/x
|
| I check for the date stamp. it is there.
|
| then I stop the image, delete /tmp/x and create a new image of the one above.
|
| I run another instance based on the new AMI, but this time WITHOUT user-data.
|
| I check for the /tmp/x file. It is there. And it contains the new timestamp!
|
| So is the user-data persisted and used again when creating a new image?
| Is it a bug or a feature? If it is a feature, is it documented :-)

--
[1] https://forums.aws.amazon.com/thread.jspa?threadID=52433

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: cloud-init 0.5.15-0ubuntu3
ProcVersionSignature: User Name 2.6.35-22.33-virtual 2.6.35.4
Uname: Linux 2.6.35-22-virtual i686
Architecture: i386
Date: Mon Nov 15 19:35:45 2010
Ec2AMI: ami-508c7839
Ec2AMIManifest: (unknown)
Ec2AvailabilityZone: us-east-1c
Ec2InstanceType: t1.micro
Ec2Kernel: aki-407d9529
Ec2Ramdisk: unavailable
PackageArchitecture: all
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: cloud-init

This bug was originally filed in Launchpad as LP: #832175

affected_projects = ['cloud-init (Ubuntu)']
assignee = None
assignee_name = None
date_closed = 2011-10-28T02:21:12.592461+00:00
date_created = 2011-08-23T16:54:07.145124+00:00
date_fix_committed = 2011-10-27T17:42:06.844849+00:00
date_fix_released = 2011-10-28T02:21:12.592461+00:00
id = 832175
importance = low
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/832175
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = fix_released
submitter = lool
submitter_name = Loïc Minier
tags = []
duplicates = []

Launchpad user Loïc Minier(lool) wrote on 2011-08-23T16:54:07.145124+00:00

Hi

If you try setting hostname to an invalid one, cloud-init will log setting the hostname (and will change /etc/hostname) but hostname (the command) will actually fail.

cloud-init should log an error in this case.

It would also be best to not set etc/hostname if running hostname fails.

Finally, if cloud-init detected the invalid syntax it could avoid running hostname entirely and display a nicer error by validating the allowed hostname chars first; this does mean validating the chars both in hostname and in cloud-init, which means it will get out of date, but that's fairly stable.

Cheers,

This bug was originally filed in Launchpad as LP: #785551

affected_projects = []
assignee = None
assignee_name = None
date_closed = 2011-10-28T02:21:22.508222+00:00
date_created = 2011-05-20T05:46:47.488256+00:00
date_fix_committed = 2011-06-22T18:48:28.522088+00:00
date_fix_released = 2011-10-28T02:21:22.508222+00:00
id = 785551
importance = undecided
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/785551
milestone = None
owner = gholms
owner_name = Garrett Holmstrom
private = False
status = fix_released
submitter = gholms
submitter_name = Garrett Holmstrom
tags = []
duplicates = []

Launchpad user Garrett Holmstrom(gholms) wrote on 2011-05-20T05:46:47.488256+00:00

cloud-init.py calls "cloud.initctl_emit()" near its end, presumably to generate an event that triggers other services to run in parallel with cloud_init_modules. This raises an exception when the system doesn't use upstart because /sbin/initctl does not exist.

I suggest moving the portion of cloud-init.py that executes cloud_init_modules into a separate script that runs after the initial cloud-init service. That should make it possible for services to trigger at the same point in the process with the same level of parallelism, while obviating the need to manually generate an event partway through the script and making it easier for non-upstart init systems to use cloud-init.

If splitting the script apart is out of the question, is there any way to skip the call to /sbin/initctl, make it fail more gracefully, or otherwise make things work when upstart is absent?

My apologies if I am failing to realize something...

This bug was originally filed in Launchpad as LP: #800856

affected_projects = ['cloud-init (Ubuntu)']
assignee = None
assignee_name = None
date_closed = 2011-10-28T02:19:50.775300+00:00
date_created = 2011-06-22T19:14:11.181186+00:00
date_fix_committed = 2011-07-20T04:17:05.202565+00:00
date_fix_released = 2011-10-28T02:19:50.775300+00:00
id = 800856
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/800856
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = fix_released
submitter = clint-fewbar
submitter_name = Clint Byrum
tags = []
duplicates = []

Launchpad user Clint Byrum(clint-fewbar) wrote on 2011-06-22T19:14:11.181186+00:00

$ sudo lxc-start -n natty-im
cloud-init start-local running: Wed, 22 Jun 2011 19:05:58 +0000. up 335311.61 seconds
no instance data found in start-local
init: cloud-init-local main process (25) terminated with status 1
init: cloud-init-nonet main process (26) killed by TERM signal
cloud-init start running: Wed, 22 Jun 2011 19:06:01 +0000. up 335314.42 seconds
found data source: DataSourceNoCloud [seed=/var/lib/cloud/seed/nocloud-net]
2011-06-22 19:06:01,362 - cc_resizefs.py[WARNING]: Failed to make device node to resize /
2011-06-22 19:06:01,362 - init.py[WARNING]: Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/cloudinit/CloudConfig/init.py", line 108, in run_cc_modules
cc.handle(name, run_args, freq=freq)
File "/usr/lib/python2.7/dist-packages/cloudinit/CloudConfig/init.py", line 72, in handle
[ name, self.cfg, self.cloud, cloudinit.log, args ])
File "/usr/lib/python2.7/dist-packages/cloudinit/init.py", line 307, in sem_and_run
func(*args)
File "/usr/lib/python2.7/dist-packages/cloudinit/CloudConfig/cc_resizefs.py", line 43, in handle
os.mknod(devpth, 0400 | stat.S_IFBLK, dev)
OSError: [Errno 1] Operation not permitted

2011-06-22 19:06:01,362 - init.py[ERROR]: config handling of resizefs, None, [] failed

init: cloud-init main process (91) terminated with status 1
mountall: Event failed
init: ureadahead-other main process (104) terminated with status 4

This error shoudl be handled more gracefully since it will happen every time on LXC containers

This bug was originally filed in Launchpad as LP: #74747

affected_projects = ['apt-setup (Ubuntu)', 'cloud-init (Ubuntu)', 'apt-setup (Ubuntu Xenial)', 'cloud-init (Ubuntu Xenial)', 'apt-setup (Ubuntu Bionic)', 'cloud-init (Ubuntu Bionic)', 'apt-setup (Ubuntu Cosmic)', 'cloud-init (Ubuntu Cosmic)']
assignee = smoser
assignee_name = Scott Moser
date_closed = 2018-12-13T20:22:44.319847+00:00
date_created = 2006-12-07T02:54:11.890275+00:00
date_fix_committed = 2018-10-04T18:20:19.821143+00:00
date_fix_released = 2018-12-13T20:22:44.319847+00:00
id = 74747
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/74747
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = fix_released
submitter = laptop006
submitter_name = LapTop006
tags = []
duplicates = [224163, 830271]

Launchpad user LapTop006(laptop006) wrote on 2006-12-07T02:54:11.890275+00:00

The default sources.list file has source packages enabled by default, this is bad for the average user (especially those on modems) because they are very unlikely to use source packages, however they will still have the download overhead of the packages list.

For most people the deb-src lines could simply be commented out by default.

(Bug reported at the behest of Robert Collins)

Implementing this would probably invalidate bug 301602. See also bug 987264.

Mailing list discussion:
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2013-May/thread.html#14503
https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2013-July/thread.html#14617

This bug was originally filed in Launchpad as LP: #855965

affected_projects = []
assignee = None
assignee_name = None
date_closed = 2011-10-28T02:20:23.580680+00:00
date_created = 2011-09-21T22:50:41.643791+00:00
date_fix_committed = 2011-09-24T13:52:47.555864+00:00
date_fix_released = 2011-10-28T02:20:23.580680+00:00
id = 855965
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/855965
milestone = None
owner = gholms
owner_name = Garrett Holmstrom
private = False
status = fix_released
submitter = gholms
submitter_name = Garrett Holmstrom
tags = []
duplicates = []

Launchpad user Garrett Holmstrom(gholms) wrote on 2011-09-21T22:50:41.643791+00:00

cloudinit/boto_utils.py bundles a bunch of code from python-boto when it could simply depend on python-boto and use it directly.

I will hopefully have a patch for this soon since Fedora won't let me package cloud-init without one. ;)

This bug was originally filed in Launchpad as LP: #812539

affected_projects = ['cloud-init (Ubuntu)']
assignee = None
assignee_name = None
date_closed = 2011-10-28T02:20:05.407665+00:00
date_created = 2011-07-18T20:35:01.595233+00:00
date_fix_committed = 2011-07-20T04:17:32.662573+00:00
date_fix_released = 2011-10-28T02:20:05.407665+00:00
id = 812539
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/812539
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = fix_released
submitter = gandelman-a
submitter_name = Adam Gandelman
tags = ['patch', 'server-o-rs']
duplicates = []

Launchpad user Adam Gandelman(gandelman-a) wrote on 2011-07-18T20:35:01.595233+00:00

 hostname -f yields, for example, "ip-10-212-67-63.localdomain" on oneiric instead of "ip-10-212-67-63.ec2.internal" as expected. This causes obvious problems when instances are exporting hostnames to be used in configuration on other instances.

This bug was originally filed in Launchpad as LP: #845155

affected_projects = ['nova', 'nova (Ubuntu)', 'nova (Ubuntu Oneiric)']
assignee = None
assignee_name = None
date_closed = 2011-09-21T18:34:59.601346+00:00
date_created = 2011-09-08T21:17:19.340667+00:00
date_fix_committed = None
date_fix_released = None
id = 845155
importance = undecided
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/845155
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = wont_fix
submitter = smoser
submitter_name = Scott Moser
tags = ['server-o-rs']
duplicates = []

Launchpad user Scott Moser(smoser) wrote on 2011-09-08T21:17:19.340667+00:00

Currently on openstack, if you did something like this:

$ cat my.userdata
#cloud-config
ssh_authorized_keys:

• ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA3I7VUf2l5gSn5uavROsc5HRDpZdQueUq5ozemNSj8T7enqKHOEaFoU2VoPgGEWC9RyzSQVeyD6s7APMcE82EtmW4skVEgEGSbDc1pvxzxtchBj78hJP6Cf5TCMFSXw+Fz5rF1dR23QDbN1mkHs7adr8GW4kSWqU7Q7NDwfIrJJtO7Hi42GyXtvEONHbiRPOe8stqUly7MvUoN+5kfjBM8Qqpfl2+FNhTYWpMfYdPUnE7u536WqzFmsaqJctz3gBxH9Ex7dFtrxR4qiqEr9Qtlu3xGn7Bw07/+i1D+ey3ONkZLN+LQ714cgj8fRS4Hj29SCmXp5Kt5/82cD/VN3NtHw== smoser@brickies

runcmd:

• [ sudo, -Hu, ubuntu, ssh-import-id, smoser ]

$ euca-run-instances --user-data-file my.userdata

you'd see a message to the console that says:
2011-09-08 20:55:52,779 - cc_ssh.py[WARNING]: applying credentials failed!

because i also inserted the key via ssh-import-id i could get to the instanc,e, then the cloud-init lgo shows:

2011-09-08 20:55:52,778 - util.py[DEBUG]: Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/cloudinit/CloudConfig/cc_ssh.py", line 73, in handle
keys = cloud.get_public_ssh_keys()
File "/usr/lib/python2.7/dist-packages/cloudinit/init.py", line 437, in get_public_ssh_keys
return(self.datasource.get_public_ssh_keys())
File "/usr/lib/python2.7/dist-packages/cloudinit/DataSource.py", line 68, in get_public_ssh_keys
for keyname, klist in self.metadata['public-keys'].items():
AttributeError: 'str' object has no attribute 'items'

2011-09-08 20:55:52,779 - cc_ssh.py[WARNING]: applying credentials failed!

The issue is that if no key is given, nova's metadata service will show an entry with an empty value. EC2's will not show the entry.

ie:

nova with no key

$ wget http://169.254.169.254/2009-04-04/meta-data/ -O - -q | grep key
public-keys
$ wget http://169.254.169.254/2009-04-04/meta-data/public-keys -O - -q ; echo

$ wget http://169.254.169.254/2009-04-04/meta-data/ -O - -q | grep key
public-keys/
$ wget http://169.254.169.254/2009-04-04/meta-data/public-keys -O - -q ; echo
0=mykey

ec2 with no key:

nova with a key

$ wget http://169.254.169.254/2009-04-04/meta-data/ -O - -q | grep key

^ there is no 'public-keys' entry listed.

This could be fixed in any number of ways.
cloud-init could be more forgiving (and probably should), but the right place to fix it is in nova, otherwise to support this in Ubuntu images we'll have to SRU it to all releases.

This bug was originally filed in Launchpad as LP: #768296

affected_projects = ['cloud-init (Ubuntu)']
assignee = None
assignee_name = None
date_closed = 2011-06-14T20:27:56.064083+00:00
date_created = 2011-04-21T12:29:30.333261+00:00
date_fix_committed = None
date_fix_released = None
id = 768296
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/768296
milestone = None
owner = avishai-ish-shalom
owner_name = Avishai Ish-Shalom
private = False
status = invalid
submitter = avishai-ish-shalom
submitter_name = Avishai Ish-Shalom
tags = ['ec2-images', 'hostname', 'hosts', 'uec-images']
duplicates = []

Launchpad user Avishai Ish-Shalom(avishai-ish-shalom) wrote on 2011-04-21T12:29:30.333261+00:00

When setting the hostname using the hostname attribute (cc_set_hostname plugin), cc_update_etc_hosts will ignore the modified hostname and use the default hostname instead.

This bug was originally filed in Launchpad as LP: #766547

affected_projects = []
assignee = None
assignee_name = None
date_closed = 2011-04-19T21:12:01.651638+00:00
date_created = 2011-04-19T20:40:25.527830+00:00
date_fix_committed = None
date_fix_released = None
id = 766547
importance = undecided
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/766547
milestone = None
owner = lynxman
owner_name = Marc Cluet
private = False
status = invalid
submitter = lynxman
submitter_name = Marc Cluet
tags = []
duplicates = []

Launchpad user Marc Cluet(lynxman) wrote on 2011-04-19T20:40:25.527830+00:00

The file /etc/cloud/templates/hosts.tmpl provided by cloud-init defines the default IP for $hostname as 127.0.1.1 instead of 127.0.0.1 which can result in undesired results if activated

The value '$hostname' will be replaced with the local-hostname

127.0.1.1 $hostname

This bug was originally filed in Launchpad as LP: #668400

affected_projects = ['cloud-init (Ubuntu)']
assignee = smoser
assignee_name = Scott Moser
date_closed = 2011-01-27T00:37:32.105099+00:00
date_created = 2010-10-29T15:58:00.196934+00:00
date_fix_committed = 2011-01-27T00:37:32.105099+00:00
date_fix_released = 2011-01-27T00:37:32.105099+00:00
id = 668400
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/668400
milestone = None
owner = clint-fewbar
owner_name = Clint Byrum
private = False
status = fix_released
submitter = jeremydei
submitter_name = Jeremy Deininger
tags = []
duplicates = []

Launchpad user Jeremy Deininger(jeremydei) wrote on 2010-10-29T15:58:00.196934+00:00

Binary package hint: cloud-init

The goal here is to get Canonical's official images to launch with RightScale hooks so that RightScale customers can use the official Canonical image. Currently the only option available for RightScale customers wanting to use the official Canonical image is to re-bundle the Canonical image.

RightScale formats the EC2 user-data in the following way:
"CLOUD_INIT_REMOTE_HOOK=http://rightscale.com/install_rightlink.sh&RS_INTERNAL_STUFF=other&ANOTHER_VARIABLE=etc"

The current proposal is to add an option to cloud-init to detect/parse
out this variable from the RightScale formatted user-data, download
the file it specifies, and execute it.

This bug was originally filed in Launchpad as LP: #819507

affected_projects = ['cloud-init (Ubuntu)']
assignee = smoser
assignee_name = Scott Moser
date_closed = 2011-10-28T02:20:11.518288+00:00
date_created = 2011-08-01T20:37:49.512045+00:00
date_fix_committed = 2011-10-27T19:48:37.909777+00:00
date_fix_released = 2011-10-28T02:20:11.518288+00:00
id = 819507
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/819507
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = fix_released
submitter = smoser
submitter_name = Scott Moser
tags = ['amd64', 'apport-bug', 'ec2-images', 'oneiric']
duplicates = []

Launchpad user Scott Moser(smoser) wrote on 2011-08-01T20:37:49.512045+00:00

Right now, cloud-init.py has:
# parse the user data (ec2-run-userdata.py)
try:
cloud.sem_and_run("consume_userdata", "once-per-instance",
cloud.consume_userdata,[],False)
except:
warn("consuming user data failed!\n")
raise

What that means is that the consume_userdata code only happens once per instance.
consume_userdata is what then walks the userdata, with callbacks for each type.
The types at the moment are:
'text/x-shellscript' : self.handle_user_script,
'text/cloud-config' : self.handle_cloud_config,
'text/upstart-job' : self.handle_upstart_job,
'text/part-handler' : self.handle_handler,
'text/cloud-boothook' : self.handle_cloud_boothook

if the user-data changes, these will not be called again unless 'consume_userdata' lock has also been removed.

That means that

• changes to cloud-config dont get realized (old cloud-config would be used)
• upstart jobs are not re-written
• handlers are not updated
• handlers will not be called more than once per instance
• boothooks are not called more than once (they are documented that they are)

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: cloud-init 0.6.1-0ubuntu12
ProcVersionSignature: User Name 3.0.0-7.8-virtual 3.0.0
Uname: Linux 3.0.0-7-virtual x86_64
Architecture: amd64
Date: Mon Aug 1 20:29:57 2011
Ec2AMI: ami-318e4858
Ec2AMIManifest: (unknown)
Ec2AvailabilityZone: us-east-1b
Ec2InstanceType: t1.micro
Ec2Kernel: aki-825ea7eb
Ec2Ramdisk: unavailable
PackageArchitecture: all
ProcEnviron:
PATH=(custom, user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: cloud-init
UpgradeStatus: No upgrade log present (probably fresh install)

This bug was originally filed in Launchpad as LP: #828186

affected_projects = ['cloud-init (Ubuntu)']
assignee = None
assignee_name = None
date_closed = 2011-10-28T02:21:30.498909+00:00
date_created = 2011-08-17T17:11:49.077842+00:00
date_fix_committed = 2011-09-21T18:35:48.790230+00:00
date_fix_released = 2011-10-28T02:21:30.498909+00:00
id = 828186
importance = undecided
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/828186
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = fix_released
submitter = smoser
submitter_name = Scott Moser
tags = ['amd64', 'apport-bug', 'oneiric']
duplicates = []

Launchpad user Scott Moser(smoser) wrote on 2011-08-17T17:11:49.077842+00:00

Often times when cloud-init boots, I want to know its IP address that it got.

It would be nice to see some things like:

• list of network interfaces (with IP if up)
• route intformation
• public-ipv4
  http://code.activestate.com/recipes/439093-get-names-of-all-up-network-interfaces-linux-only/

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: cloud-init 0.6.1-0ubuntu14
ProcVersionSignature: User Name 3.0.0-8.11-virtual 3.0.1
Uname: Linux 3.0.0-8-virtual x86_64
Architecture: amd64
Date: Wed Aug 17 16:41:07 2011
PackageArchitecture: all
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: cloud-init
UpgradeStatus: No upgrade log present (probably fresh install)

This bug was originally filed in Launchpad as LP: #693292

affected_projects = []
assignee = None
assignee_name = None
date_closed = 2011-01-27T00:37:44.332955+00:00
date_created = 2010-12-22T07:51:19.348768+00:00
date_fix_committed = 2011-01-19T14:35:57.983423+00:00
date_fix_released = 2011-01-27T00:37:44.332955+00:00
id = 693292
importance = low
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/693292
milestone = None
owner = jbauer
owner_name = Jeff Bauer
private = False
status = fix_released
submitter = jbauer
submitter_name = Jeff Bauer
tags = []
duplicates = []

Launchpad user Jeff Bauer(jbauer) wrote on 2010-12-22T07:51:19.348768+00:00

It would be nice if it cloud-config offered "UBUNTU_MIRROR" and "UBUNTU_RELEASE" keys, so the values could be accessed from a user-script.

Work-around for UBUNTU_RELEASE:
DISTRIB_CODENAME=lsb_release -s --codename

cloud-init selects the mirror, but a user-script doesn't know about it unless it duplicates cloud-init's logic.

Original exchange on the ec2ubuntu group:
http://groups.google.com/group/ec2ubuntu/browse_thread/thread/78df1ddd7ec0026a?hl=en#

This bug was originally filed in Launchpad as LP: #655837

affected_projects = []
assignee = None
assignee_name = None
date_closed = 2012-11-14T20:34:44.110704+00:00
date_created = 2010-10-06T16:47:10.063293+00:00
date_fix_committed = None
date_fix_released = None
id = 655837
importance = low
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/655837
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = wont_fix
submitter = smoser
submitter_name = Scott Moser
tags = ['ec2-images', 'uec-images']
duplicates = []

Launchpad user Scott Moser(smoser) wrote on 2010-10-06T16:47:10.063293+00:00

Amazon's linux image uses cloud-init: http://aws.amazon.com/amazon-linux-ami/ .

Amazon made changes to cloud-init to support their Fedora/CentOS base.

the changes should be integrated into cloud-init upstream.

I'm attaching the cloud-init srpm obtained with: get_reference_source -p cloud-init
from ami-3ac33653 (137112412989/amzn-ami-0.9.8-beta.i386-ebs) on 2010-10-06.

This bug was originally filed in Launchpad as LP: #871297

affected_projects = ['cloud-init (Ubuntu)']
assignee = None
assignee_name = None
date_closed = 2011-10-28T02:21:17.821702+00:00
date_created = 2011-10-09T14:05:55.861742+00:00
date_fix_committed = 2011-10-09T22:59:04.164631+00:00
date_fix_released = 2011-10-28T02:21:17.821702+00:00
id = 871297
importance = low
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/871297
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = fix_released
submitter = eswierk
submitter_name = Ed Swierk
tags = []
duplicates = []

Launchpad user Ed Swierk(eswierk) wrote on 2011-10-09T14:05:55.861742+00:00

uncloud-init apparently tries to allow updating the filesystem from an updates.tar tarball (itself contained within the xupdate tarball or filesystem image).

But in the updateFrom function, it ignores updates.tar unless it's a directory:

if [ -d "${mp}/updates.tar" ]; then
...

This looks like a copy-and-paste bug from the code above, which is checking for a directory called updates. The obvious fix is to change the -d to -f.

This bug was originally filed in Launchpad as LP: #603329

affected_projects = ['cloud-init (Ubuntu)']
assignee = smoser
assignee_name = Scott Moser
date_closed = 2011-01-24T17:31:03.923171+00:00
date_created = 2010-07-08T20:37:26.900397+00:00
date_fix_committed = 2010-07-09T00:51:09.788994+00:00
date_fix_released = 2011-01-24T17:31:03.923171+00:00
id = 603329
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/603329
milestone = None
owner = clint-fewbar
owner_name = Clint Byrum
private = False
status = fix_released
submitter = clint-fewbar
submitter_name = Clint Byrum
tags = []
duplicates = []

Launchpad user Clint Byrum(clint-fewbar) wrote on 2010-07-08T20:37:26.900397+00:00

Binary package hint: cloud-init

When trying to add glusterfs mounts, this cloud config yaml section fails to produce any errors or fstab entries:

mounts:

• [ 'volfile-server-hostname:6996', /mnt/data, glusterfs, "defaults,nobootwait", "0", "2" ]

In chatting w/ Scott on IRC, he believe it is a problem with anything that starts with a non slash char:

This bug was originally filed in Launchpad as LP: #672417

affected_projects = ['cloud-init (Ubuntu)']
assignee = None
assignee_name = None
date_closed = 2011-01-27T00:37:16.856411+00:00
date_created = 2010-11-08T06:51:27.895283+00:00
date_fix_committed = 2011-01-26T19:50:52.754951+00:00
date_fix_released = 2011-01-27T00:37:16.856411+00:00
id = 672417
importance = low
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/672417
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = fix_released
submitter = esh
submitter_name = Eric Hammond
tags = ['apport-bug', 'ec2-images', 'i386', 'maverick']
duplicates = []

Launchpad user Eric Hammond(esh) wrote on 2010-11-08T06:51:27.895283+00:00

Binary package hint: cloud-init

Attempting to log in to the "root" user on an Ubuntu AMI returns the message:

Please login as the ubuntu user rather than root user.

This has two minor problems:

1. There is a missing "the" before the word "root".

2. Adding quotes around the usernames would reduce confusion (see https://bugs.launchpad.net/ubuntu/+source/ec2-init/+bug/506981/comments/7)

Proposed new messaging:

Please login as the user "ubuntu" rather than the user "root".

or

Please login as the "ubuntu" user rather than the "root" user.

The first one is slightly clearer to me, but both get the message across.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: ec2-init (not installed)
ProcVersionSignature: User Name 2.6.35-22.33-virtual 2.6.35.4
Uname: Linux 2.6.35-22-virtual i686
Architecture: i386
Date: Sun Nov 7 18:27:51 2010
Ec2AMI: ami-508c7839
Ec2AMIManifest: (unknown)
Ec2AvailabilityZone: us-east-1b
Ec2InstanceType: m1.small
Ec2Kernel: aki-407d9529
Ec2Ramdisk: unavailable
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: cloud-init

This bug was originally filed in Launchpad as LP: #785542

affected_projects = []
assignee = smoser
assignee_name = Scott Moser
date_closed = 2011-10-28T02:21:09.801547+00:00
date_created = 2011-05-20T04:41:04.954753+00:00
date_fix_committed = 2011-09-21T18:33:54.421397+00:00
date_fix_released = 2011-10-28T02:21:09.801547+00:00
id = 785542
importance = low
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/785542
milestone = None
owner = gholms
owner_name = Garrett Holmstrom
private = False
status = fix_released
submitter = gholms
submitter_name = Garrett Holmstrom
tags = []
duplicates = []

Launchpad user Garrett Holmstrom(gholms) wrote on 2011-05-20T04:41:04.954753+00:00

Since the "nobootwait" mount option is not part of upstream util-linux, mountall chokes on fstab entries created by cloud-init when run on a distro that doesn't patch that option into the source. Is the idea to prevent boot failure due to disks that go missing between boots? If so, perhaps "nofail" would be better.

This bug was originally filed in Launchpad as LP: #744019

affected_projects = ['cloud-init (Ubuntu)']
assignee = None
assignee_name = None
date_closed = 2011-10-28T02:21:07.180976+00:00
date_created = 2011-03-28T04:30:07.310664+00:00
date_fix_committed = 2011-08-01T14:01:43.617319+00:00
date_fix_released = 2011-10-28T02:21:07.180976+00:00
id = 744019
importance = low
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/744019
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = fix_released
submitter = error404notfound
submitter_name = Muhammad Shoaib
tags = []
duplicates = []

Launchpad user Muhammad Shoaib(error404notfound) wrote on 2011-03-28T04:30:07.310664+00:00

Binary package hint: cloud-init

My Setup

I am using the official Ubuntu 10.10 Maverick Meekat EBS AMIs (ami-ccf405a5,ami-cef405a7) on
64bit t1.micro and
32bit m1.small
instances.

Both instances have: cloud-init v 0.5.15-0ubuntu3

Nothing additional besides the defaults set of tools available on these AMIs was installed.

Problems

On every boot i get:
cloud-init start-local running: Mon, 28 Mar 2011 03:33:16 +0000. up 2.40 seconds
no instance data found in start-local
init: cloud-init-local main process (374) terminated with status 1

cloud-init start running: Mon, 28 Mar 2011 03:33:17 +0000. up 2.75 seconds
found data source: DataSourceEc2
mountall: Event failed

• Starting AppArmor profiles [80G 2011-03-28 04:00:52,257 - DataSourceEc2.py[WARNING]: unable to convert swap to a device
  2011-03-28 04:00:52,268 - cc_mounts.py[WARNING]: 'mount -a' failed

Lastly even though the t1.micro instance type has only one drive attached to it, e.g. /dev/sda1 the "/". It appends "/dev/sdb" to be mounted over "/mnt" in fstab as well as swap. According to Amazon's Instance Guide with t1.micro instance there is neither swap nor /mnt drive.

How to reproduce the errors?

Use same AMIs and launch an instance, get system log from aws console of /var/log.

This bug was originally filed in Launchpad as LP: #859814

affected_projects = ['cloud-init (Ubuntu)']
assignee = smoser
assignee_name = Scott Moser
date_closed = 2012-04-11T04:12:20.195020+00:00
date_created = 2011-09-26T17:12:38.924636+00:00
date_fix_committed = 2012-04-04T18:27:07.518331+00:00
date_fix_released = 2012-04-11T04:12:20.195020+00:00
id = 859814
importance = undecided
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/859814
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = fix_released
submitter = james-page
submitter_name = James Page
tags = ['amd64', 'apport-bug', 'ec2-images', 'oneiric']
duplicates = []

Launchpad user James Page(james-page) wrote on 2011-09-26T17:12:38.924636+00:00

Default locale of image appears to be en_US.UTF-8 - however when I logon from a en_GB.UTF-8 client via SSH I get the following errors - springs up in a few places while doing things on the server.

This was from a local openstack test instance; however I get the same error in ec2 instances with the latest daily snapshot.

ubuntu@server-3:~$ locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE=en_GB.UTF-8
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE=en_GB.UTF-8
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES=en_GB.UTF-8
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Related Bugs:
 * Bug 920601: cloud-images don't accept LANG settings

• Bug 969462: postgresql-9.1 fails to start after install if invalid locale is set

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: cloud-init 0.6.1-0ubuntu15
ProcVersionSignature: User Name 3.0.0-9.15-virtual 3.0.3
Uname: Linux 3.0.0-9-virtual x86_64
Architecture: amd64
Date: Mon Sep 26 17:09:24 2011
Ec2AMI: ami-00000002
Ec2AMIManifest: FIXME
Ec2AvailabilityZone: nova
Ec2InstanceType: m1.small
Ec2Kernel: aki-00000001
Ec2Ramdisk: unavailable
PackageArchitecture: all
ProcEnviron:
 LC_CTYPE=en_GB.UTF-8
 LC_COLLATE=en_GB.UTF-8
 LANG=en_US.UTF-8
 LC_MESSAGES=en_GB.UTF-8
 SHELL=/bin/bash
SourcePackage: cloud-init
UpgradeStatus: No upgrade log present (probably fresh install)

This bug was originally filed in Launchpad as LP: #785570

affected_projects = []
assignee = None
assignee_name = None
date_closed = 2022-02-28T10:43:57.818713+00:00
date_created = 2011-05-20T06:34:32.439014+00:00
date_fix_committed = None
date_fix_released = None
id = 785570
importance = wishlist
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/785570
milestone = None
owner = gholms
owner_name = Garrett Holmstrom
private = False
status = wont_fix
submitter = gholms
submitter_name = Garrett Holmstrom
tags = []
duplicates = []

Launchpad user Garrett Holmstrom(gholms) wrote on 2011-05-20T06:34:32.439014+00:00

CloudConfig.install_packages and CloudConfig.update_package_sources could both be made more distro-agnostic by calling PackageKit's pkcon program instead of apt-get. It should be a drop-in replacement like so:

apt-get upgrade -> pkcon upgrade
apt-get install -> pkcon install
apt-get update -> pkcon refresh

AFAICT, pkcon's "-y" option is equivalent to passing "--force-confdef", "--force-confold" and "--assume-yes" to the appropriate programs. Passing "-p" to pkcon makes its output suitable for logging. Unfortunately there doesn't seem to be an option to silence its output completely, but its stdout could always be dropped.

This bug was originally filed in Launchpad as LP: #857926

affected_projects = []
assignee = None
assignee_name = None
date_closed = 2011-10-28T02:20:58.262616+00:00
date_created = 2011-09-24T01:24:19.790448+00:00
date_fix_committed = 2011-10-27T19:59:00.969124+00:00
date_fix_released = 2011-10-28T02:20:58.262616+00:00
id = 857926
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/857926
milestone = None
owner = gholms
owner_name = Garrett Holmstrom
private = False
status = fix_released
submitter = gholms
submitter_name = Garrett Holmstrom
tags = []
duplicates = []

Launchpad user Garrett Holmstrom(gholms) wrote on 2011-09-24T01:24:19.790448+00:00

The way in which util.runparts calls the run-parts command makes scripts-per-once and friends fail unnecessarily when their scripts/* directories are empty. The attached patch makes the function simply return when called on an empty directory so modules do not fail in that case.

LaunchPad Issue #1656144

This bug was originally filed in Launchpad as LP: #802637

affected_projects = []
assignee = lynxman
assignee_name = Marc Cluet
date_closed = 2011-07-01T11:39:27.373744+00:00
date_created = 2011-06-27T16:52:25.712637+00:00
date_fix_committed = 2011-07-01T11:39:27.373744+00:00
date_fix_released = 2011-07-01T11:39:27.373744+00:00
id = 802637
importance = undecided
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/802637
milestone = None
owner = lynxman
owner_name = Marc Cluet
private = False
status = fix_released
submitter = lynxman
submitter_name = Marc Cluet
tags = []
duplicates = []

Launchpad user Marc Cluet(lynxman) wrote on 2011-06-27T16:52:25.712637+00:00

cloud-init needs to check that $hostname is resolvable to the IP 127.0.1.1 and fix /etc/hosts to make sure that is properly configured

This bug was originally filed in Launchpad as LP: #857366

affected_projects = ['cloud-init (Ubuntu)', 'cloud-init (Ubuntu Precise)']
assignee = smoser
assignee_name = Scott Moser
date_closed = 2012-04-11T04:07:20.245592+00:00
date_created = 2011-09-23T13:05:25.710115+00:00
date_fix_committed = 2011-12-21T14:17:00.981618+00:00
date_fix_released = 2012-04-11T04:07:20.245592+00:00
id = 857366
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/857366
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = fix_released
submitter = smoser
submitter_name = Scott Moser
tags = ['apport-bug', 'ec2-images', 'i386', 'oneiric']
duplicates = []

Launchpad user Scott Moser(smoser) wrote on 2011-09-23T13:05:25.710115+00:00

This is a feature request to include support for configuring landscape-client via cloud-config syntax.

The syntax would look something like:
#cloud-config
landscape:
account-name: foobar
title: cloud1
secret: hiya

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: cloud-init 0.6.1-0ubuntu19
ProcVersionSignature: User Name 3.0.0-11.18-virtual 3.0.4
Uname: Linux 3.0.0-11-virtual i686
ApportVersion: 1.23-0ubuntu1
Architecture: i386
Date: Fri Sep 23 12:22:06 2011
Ec2AMI: ami-00000094
Ec2AMIManifest: FIXME
Ec2AvailabilityZone: nova
Ec2InstanceType: m1.small
Ec2Kernel: unavailable
Ec2Ramdisk: unavailable
PackageArchitecture: all
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: cloud-init
UpgradeStatus: No upgrade log present (probably fresh install)

This bug was originally filed in Launchpad as LP: #797336

affected_projects = ['cloud-init (Ubuntu)']
assignee = smoser
assignee_name = Scott Moser
date_closed = 2011-10-28T02:21:24.556721+00:00
date_created = 2011-06-14T18:08:56.728294+00:00
date_fix_committed = 2011-06-14T20:29:58.390486+00:00
date_fix_released = 2011-10-28T02:21:24.556721+00:00
id = 797336
importance = undecided
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/797336
milestone = None
owner = gandelman-a
owner_name = Adam Gandelman
private = False
status = fix_released
submitter = gandelman-a
submitter_name = Adam Gandelman
tags = []
duplicates = []

Launchpad user Adam Gandelman(gandelman-a) wrote on 2011-06-14T18:08:56.728294+00:00

It seems the byobu bits of cloud-config exist to easily enable byobu by default on cloud systems. As of oneiric alpha1, byobu is enabled by default system-wide. There should be an option to the 'byobu_by_default' parameter to disable byobu in the same way it was previously enabled.

This bug was originally filed in Launchpad as LP: #810044

affected_projects = ['cloud-init (Ubuntu)', 'ifupdown (Ubuntu)']
assignee = None
assignee_name = None
date_closed = 2011-10-28T02:20:00.543630+00:00
date_created = 2011-07-13T17:49:47.204378+00:00
date_fix_committed = 2011-08-02T01:35:19.504411+00:00
date_fix_released = 2011-10-28T02:20:00.543630+00:00
id = 810044
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/810044
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = fix_released
submitter = smoser
submitter_name = Scott Moser
tags = ['amd64', 'apport-bug', 'oneiric']
duplicates = []

Launchpad user Scott Moser(smoser) wrote on 2011-07-13T17:49:47.204378+00:00

right now, if there are multiple network adapters in a system, cloud-init coudl start running cloud-config jobs before network was really up.

That means installing additional packages could be attempted before the network required was up. cloud-config could start as early as the first network coming up.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: cloud-init 0.6.1-0ubuntu11
ProcVersionSignature: User Name 3.0-3.4-virtual 3.0.0-rc5
Uname: Linux 3.0-3-virtual x86_64
Architecture: amd64
Date: Wed Jul 13 17:46:07 2011
PackageArchitecture: all
ProcEnviron:
PATH=(custom, user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: cloud-init
UpgradeStatus: No upgrade log present (probably fresh install)

This bug was originally filed in Launchpad as LP: #871966

affected_projects = ['ubuntu-release-notes', 'cloud-init (Ubuntu)', 'cloud-init (Ubuntu Precise)', 'cassandra (Juju Charms Collection)']
assignee = smoser
assignee_name = Scott Moser
date_closed = 2012-04-11T04:07:45.010543+00:00
date_created = 2011-10-10T19:35:34.612691+00:00
date_fix_committed = 2011-12-20T03:52:41.187412+00:00
date_fix_released = 2012-04-11T04:07:45.010543+00:00
id = 871966
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/871966
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = fix_released
submitter = clint-fewbar
submitter_name = Clint Byrum
tags = []
duplicates = []

Launchpad user Clint Byrum(clint-fewbar) wrote on 2011-10-10T19:35:34.612691+00:00

*** Ubuntu 11.10 Release Note ***

Cloud instances and servers pre-seeded with cloud-init will have their FQDN written to /etc/hosts and pointed to the IP 127.0.1.1. This may cause issues for daemons which try to listen on their hostname, rather than 0.0.0.0, as they will now only be reachable locally, rather than on the network address that their FQDN resolves to.

By writing the FQDN to /etc/hosts as resolving to 127.0.1.1, systems like Cassandra have a much harder time determining their address to communicate to other cluster members.

While some might see communicating your IP to others as a bug, being able to use gethostname() and then resolving it to get the actual IP address of one's machine is fairly important.

Its my understanding that in resolving bug #802637 , the Debian networking docs were used as a guide:

http://www.debian.org/doc/manuals/debian-reference/ch05.en.html
Point 5.1.2 specifically.

It does suggest that one needs an FQDN in /etc/hosts.

However cloud-init should only set the addresss if it cannot be determined.

cloud-init should first try gethostbyname() on the FQDN. If it resolves, do not write FQDN to /etc/hosts. This assures that if it has been configured to be resolvable by some method in nsswitch.conf such as DNS or NIS or etc., it will not be overidden by /etc/hosts.

related bugs:
bug 890501: EC2 cloud-init overwrites 127.0.1.1 in /etc/hosts on every reboot

This bug was originally filed in Launchpad as LP: #857378

affected_projects = ['cloud-init (Ubuntu)', 'cloud-init (Ubuntu Precise)']
assignee = None
assignee_name = None
date_closed = 2012-04-11T04:07:26.763285+00:00
date_created = 2011-09-23T13:10:18.819585+00:00
date_fix_committed = 2012-03-05T21:10:55.805597+00:00
date_fix_released = 2012-04-11T04:07:26.763285+00:00
id = 857378
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/857378
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = fix_released
submitter = smoser
submitter_name = Scott Moser
tags = ['apport-bug', 'ec2-images', 'i386', 'oneiric']
duplicates = []

Launchpad user Scott Moser(smoser) wrote on 2011-09-23T13:10:18.819585+00:00

This came up when talking with Soren on IRC.
We can now attach a OVF CDrom and seed cloud-init that way, but it would be nice to be able to do the same with a more friendly disk format.

Ie, if there were a disk (cdrom or disk) that had:

• LABEL=cloudinit
• user-data
• meta-data

Or something like that. That would it trivial to attach a local disk and boot the images in "NoCloud".

Something in this general vicinity is 'configdrive' from openstack/nova.

It would be good to support configdrive right out of the box.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: cloud-init 0.6.1-0ubuntu19
ProcVersionSignature: User Name 3.0.0-11.18-virtual 3.0.4
Uname: Linux 3.0.0-11-virtual i686
ApportVersion: 1.23-0ubuntu1
Architecture: i386
Date: Fri Sep 23 12:22:27 2011
Ec2AMI: ami-00000094
Ec2AMIManifest: FIXME
Ec2AvailabilityZone: nova
Ec2InstanceType: m1.small
Ec2Kernel: unavailable
Ec2Ramdisk: unavailable
PackageArchitecture: all
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: cloud-init
UpgradeStatus: No upgrade log present (probably fresh install)

This bug was originally filed in Launchpad as LP: #684804

affected_projects = ['cloud-init (Ubuntu)']
assignee = None
assignee_name = None
date_closed = 2019-03-06T22:17:20.758451+00:00
date_created = 2010-12-03T16:12:28.642188+00:00
date_fix_committed = 2019-03-06T22:17:20.758451+00:00
date_fix_released = 2019-03-06T22:17:20.758451+00:00
id = 684804
importance = low
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/684804
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = fix_released
submitter = ubuntu-alex-org
submitter_name = Alex Bligh
tags = []
duplicates = []

Launchpad user Alex Bligh(ubuntu-alex-org) wrote on 2010-12-03T16:12:28.642188+00:00

Binary package hint: cloud-init

cloud-init should fetch data specific to the image (and the platform) prior to fetching user-data, and treat it the same way.

It should be an objective of ubuntu cloud images that they will run on multiple cloud platforms without customization. As cloud platforms differ, if the image is not customized, it is necessary for the image to perform certain platform-specific operations on first boot. These tend to be image specific too. An example would be to map PV driver disks.

Currently cloud-init sucks down and run a user-data script if supplied. It gets this by default by reading
http://169.254.169.254/user-data
Cloud platform providers cannot provide data there because there is no agreed format for user-data (i.e. not every user uses the MIME format ubuntu's cloud-init uses), meaning that (a) we would corrupt the user-data blob, and (b) even prepending another MIME part, we'd run into problems with bad MIME etc.

It is suggested that instead cloud-init FIRST gets a user-data script from
http://169.254.169.254/image-data
or similar. This would be platform specific data (as opposed to instance specific data) that would be run first. This could do platform specific stuff (for instance, change UUID, use custom first password code, disable bits of udev, and so forth).

Added to the end of the URL would be GET parameters describing the operating system type, release, etc. that could be used to help the platform provider interpret what they should send down (although this could form part of the metadata of the image itself, in a situation where a server is e.g. installed manually on a blank disk it won't be there).

This should be a pretty trivial addition to cloud-init.

This bug was originally filed in Launchpad as LP: #845208

affected_projects = []
assignee = avishai-ish-shalom
assignee_name = Avishai Ish-Shalom
date_closed = 2011-10-28T02:20:16.965214+00:00
date_created = 2011-09-08T22:48:55.386212+00:00
date_fix_committed = 2011-09-21T18:39:40.968451+00:00
date_fix_released = 2011-10-28T02:20:16.965214+00:00
id = 845208
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/845208
milestone = None
owner = avishai-ish-shalom
owner_name = Avishai Ish-Shalom
private = False
status = fix_released
submitter = avishai-ish-shalom
submitter_name = Avishai Ish-Shalom
tags = ['chef']
duplicates = []

Launchpad user Avishai Ish-Shalom(avishai-ish-shalom) wrote on 2011-09-08T22:48:55.386212+00:00

Chef 0.10 introduced environments which are set in the chef-client config file. The chef plugin should allow specifying the environment in cloud-config.
Also, additional attributes can be specified in initial json - that too should be available via cloud-config.

This bug was originally filed in Launchpad as LP: #798844

affected_projects = ['cloud-init (Ubuntu)']
assignee = None
assignee_name = None
date_closed = 2011-10-28T02:19:44.570723+00:00
date_created = 2011-06-17T17:09:36.735964+00:00
date_fix_committed = 2011-07-19T16:40:08.690817+00:00
date_fix_released = 2011-10-28T02:19:44.570723+00:00
id = 798844
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/798844
milestone = None
owner = avishai-ish-shalom
owner_name = Avishai Ish-Shalom
private = False
status = fix_released
submitter = avishai-ish-shalom
submitter_name = Avishai Ish-Shalom
tags = ['chef']
duplicates = []

Launchpad user Avishai Ish-Shalom(avishai-ish-shalom) wrote on 2011-06-17T17:09:36.735964+00:00

Implement chef integration similar to puppet module.

This bug was originally filed in Launchpad as LP: #874342

affected_projects = []
assignee = smoser
assignee_name = Scott Moser
date_closed = 2012-04-11T04:07:50.951769+00:00
date_created = 2011-10-14T15:29:21.310533+00:00
date_fix_committed = 2012-01-13T10:34:51.551447+00:00
date_fix_released = 2012-04-11T04:07:50.951769+00:00
id = 874342
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/874342
milestone = None
owner = mlowery
owner_name = Mat Lowery
private = False
status = fix_released
submitter = mlowery
submitter_name = Mat Lowery
tags = []
duplicates = []

Launchpad user Mat Lowery(mlowery) wrote on 2011-10-14T15:29:21.310533+00:00

I created a part handler to handle application/octet-stream types. In order to get the true payload, I had to base64 decode twice. The first encode happens because I used write-mime-multipart. The second encode seems to happen in UserDataHandler.parts2mime. Am I doing something wrong or should this second encode not be performed?

If i specify the password when create a new linux VM in the console, but fail to read admin_pass to reset the root password with cloud-init agent. while the cloudbase-init agent for windows can read the admin_pass to reset the administrator password.

This bug was originally filed in Launchpad as LP: #737882

affected_projects = ['cloud-init (Ubuntu)']
assignee = None
assignee_name = None
date_closed = 2011-03-19T00:07:14.360138+00:00
date_created = 2011-03-18T22:47:13.688900+00:00
date_fix_committed = 2011-03-19T00:07:14.360138+00:00
date_fix_released = 2011-03-19T00:07:14.360138+00:00
id = 737882
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/737882
milestone = None
owner = lexinator
owner_name = alexius ludeman
private = False
status = fix_released
submitter = lexinator
submitter_name = alexius ludeman
tags = ['cloud-init', 'mimebase']
duplicates = []

Launchpad user alexius ludeman(lexinator) wrote on 2011-03-18T22:47:13.688900+00:00

init: cloud-init-local main process (254) terminated with status 1
cloud-init start running: Fri, 18 Mar 2011 20:54:30 +0000. up 2.25 seconds
Traceback (most recent call last):
  File "/usr/bin/cloud-init", line 196, in
    main()
  File "/usr/bin/cloud-init", line 78, in main
    cloud.update_cache()
  File "/usr/lib/python2.6/dist-packages/cloudinit/init.py", line 278, in update_cache
    self.store_userdata()
  File "/usr/lib/python2.6/dist-packages/cloudinit/init.py", line 282, in store_userdata
    util.write_file(userdata, self.datasource.get_userdata(), 0600)
  File "/usr/lib/python2.6/dist-packages/cloudinit/DataSource.py", line 32, in get_userdata
    self.userdata = ud.preprocess_userdata(self.userdata_raw)
  File "/usr/lib/python2.6/dist-packages/cloudinit/UserDataHandler.py", line 120, in preprocess_userdata
    return(parts2mime(parts))
  File "/usr/lib/python2.6/dist-packages/cloudinit/UserDataHandler.py", line 104, in parts2mime
    msg = MIMEBase(maintype, subtype)
NameError: global name 'MIMEBase' is not defined

This is due a lack of import of MIMEBase

This bug was originally filed in Launchpad as LP: #761847

affected_projects = ['cloud-init (Ubuntu)']
assignee = None
assignee_name = None
date_closed = 2011-10-28T02:19:33.981217+00:00
date_created = 2011-04-15T15:04:22.964901+00:00
date_fix_committed = 2011-06-01T20:33:58.436969+00:00
date_fix_released = 2011-10-28T02:19:33.981217+00:00
id = 761847
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/761847
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = fix_released
submitter = smoser
submitter_name = Scott Moser
tags = ['apport-bug', 'i386', 'natty', 'uec-images']
duplicates = []

Launchpad user Scott Moser(smoser) wrote on 2011-04-15T15:04:22.964901+00:00

Binary package hint: cloud-init

from http://open.eucalyptus.com/wiki/EucalyptusNetworkConfiguration_v2.0

| If your system is configured using SYSTEM or STATIC networking modes,
| then retrieving data requires the IP (or hostname) and port number of the
| Eucalyptus Cloud Controller (CLC):
|
| http://:8773/
|
| (We recommend that you set up a DNS entry for each cloud controller.
| This way you can configure your images to access the metadata service
| using a DNS name, thus avoiding the need to recreate pre-configured images
| in the event a specific IP address changes.)

cloud-init could/should try a well-known hostname in addition to the well
known hostname in addition to the well known IP address '169.254.169.254'
to support this.

on EC2, Amazon provides 'instance-data' hostname:
$ host instance-data
instance-data.compute-1.internal has address 169.254.169.254

So that might be a good idea to use that.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: cloud-init 0.6.1-0ubuntu7
ProcVersionSignature: User Name 2.6.38-8.42-virtual 2.6.38.2
Uname: Linux 2.6.38-8-virtual i686
Architecture: i386
Date: Fri Apr 15 14:58:05 2011
PackageArchitecture: all
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: cloud-init
UpgradeStatus: No upgrade log present (probably fresh install)

This bug was originally filed in Launchpad as LP: #812646

affected_projects = ['cloud-init (Ubuntu)']
assignee = None
assignee_name = None
date_closed = 2011-10-28T02:20:08.117757+00:00
date_created = 2011-07-19T02:02:41.284098+00:00
date_fix_committed = 2011-07-20T03:53:35.164006+00:00
date_fix_released = 2011-10-28T02:20:08.117757+00:00
id = 812646
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/812646
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = fix_released
submitter = tpot
submitter_name = Tim Potter
tags = ['amd64', 'apport-bug', 'natty', 'running-unity']
duplicates = []

Launchpad user Tim Potter(tpot) wrote on 2011-07-19T02:02:41.284098+00:00

Hi there. I'm trying to configure a 11.04 KVM instance using nocloud-net and it sometimes works, sometimes not.

I have configured kernel args of init=/usr/lib/cloud-init/uncloud-init ds=nocloud-net;s=http://192.168.122.1/;h=blah and have a user-data and meta-data file at the address above. Most of the time things work and the VM starts up properly.

Some time, usually the very first boot of the VM, I get "get_data of DataSourceNoCloudNet raised <urlopen error [Errno 101] Network is unreachable> and cloud-init falls through to (non-existent) DataSourceEc2. A power down and power up again usually fixes this.

This looks like a race, though I can't figure exactly how the upstart jobs run.

init: plymouth-splash main process (276) terminated with status 2
cloud-init start-local running: Tue, 19 Jul 2011 01:27:10 +0000. up 9.83 seconds
no instance data found in start-local
init: cloud-init-local main process (242) terminated with status 1
cloud-init start running: Tue, 19 Jul 2011 01:27:10 +0000. up 10.12 seconds
2011-08-19 01:27:10,371 - init.py[WARNING]: get_data of DataSourcenoCloudNet raised <urlopenerror [Errno 101] Network is unreachable>
2011-07-19 01:27:10,415 - DataSourceEc2.py[WARNING]: waiting for metadata service at http://169.254.159.254/2009-04-04/meta-data/instance-id
....

A successful boot looks like this:

init: plymouth-splash main process (339) terminated with status 2
cloud-init start running: Tue, 19 Jul 2011 02:00:56 +0000. up 2.50 seconds
found data source: DataSourceNoCloud [seed=cmdline,http://192.168.122.1/]
....

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: cloud-init (not installed)
ProcVersionSignature: Ubuntu 2.6.38-10.46-generic 2.6.38.7
Uname: Linux 2.6.38-10-generic x86_64
Architecture: amd64
Date: Tue Jul 19 11:52:48 2011
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007.1)
ProcEnviron:
LANGUAGE=en_AU:en
PATH=(custom, user)
LANG=en_AU.UTF-8
SHELL=/bin/bash
SourcePackage: cloud-init
UpgradeStatus: Upgraded to natty on 2011-05-18 (61 days ago)

This bug was originally filed in Launchpad as LP: #861943

affected_projects = []
assignee = smoser
assignee_name = Scott Moser
date_closed = 2012-04-11T04:07:33.006381+00:00
date_created = 2011-09-29T00:34:33.794574+00:00
date_fix_committed = 2011-10-31T15:54:53.930281+00:00
date_fix_released = 2012-04-11T04:07:33.006381+00:00
id = 861943
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/861943
milestone = None
owner = gholms
owner_name = Garrett Holmstrom
private = False
status = fix_released
submitter = gholms
submitter_name = Garrett Holmstrom
tags = []
duplicates = []

Launchpad user Garrett Holmstrom(gholms) wrote on 2011-09-29T00:34:33.794574+00:00

Cloud-init is currently very upstart-specific. Adding support for systemd would help make it work on Fedora.

This bug was originally filed in Launchpad as LP: #848932

affected_projects = ['cloud-init (Ubuntu)']
assignee = smoser
assignee_name = Scott Moser
date_closed = 2011-10-28T02:21:14.978970+00:00
date_created = 2011-09-13T12:34:06.097196+00:00
date_fix_committed = 2011-10-28T01:42:44.172065+00:00
date_fix_released = 2011-10-28T02:21:14.978970+00:00
id = 848932
importance = low
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/848932
milestone = None
owner = clint-fewbar
owner_name = Clint Byrum
private = False
status = fix_released
submitter = smoser
submitter_name = Scott Moser
tags = ['apport-bug', 'ec2-images', 'i386', 'oneiric', 'patch']
duplicates = []

Launchpad user Scott Moser(smoser) wrote on 2011-09-13T12:34:06.097196+00:00

there is currently a 'ruby_packages' dictionary that maps the ruby version (1.8, 1.9, 1.9.1) to a list of packages that would need to be installed to get a functional gems.

That won't work for future versions of ruby (ie, 1.9.2). and woudl require updates to cloud-init to support it.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: cloud-init 0.6.1-0ubuntu17
ProcVersionSignature: User Name 3.0.0-11.17-virtual 3.0.4
Uname: Linux 3.0.0-11-virtual i686
ApportVersion: 1.22.1-0ubuntu2
Architecture: i386
Date: Tue Sep 13 12:32:00 2011
Ec2AMI: ami-00000084
Ec2AMIManifest: FIXME
Ec2AvailabilityZone: nova
Ec2InstanceType: m1.small
Ec2Kernel: unavailable
Ec2Ramdisk: unavailable
PackageArchitecture: all
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: cloud-init
UpgradeStatus: No upgrade log present (probably fresh install)

This bug was originally filed in Launchpad as LP: #850206

affected_projects = ['cloud-init (Ubuntu)']
assignee = smoser
assignee_name = Scott Moser
date_closed = 2011-10-28T02:21:34.648545+00:00
date_created = 2011-09-14T17:51:12.303784+00:00
date_fix_committed = 2011-10-27T19:49:57.856693+00:00
date_fix_released = 2011-10-28T02:21:34.648545+00:00
id = 850206
importance = undecided
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/850206
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = fix_released
submitter = smoser
submitter_name = Scott Moser
tags = ['amd64', 'apport-bug', 'ec2-images', 'oneiric']
duplicates = []

Launchpad user Scott Moser(smoser) wrote on 2011-09-14T17:51:12.303784+00:00

Right now, if there is no 'local-hostname' in a DataSource's meta-data, then cloud-init will default the domain portion of the fqdn to be 'localdomain'. I did this because determining a system's fully qualified domain name is non-trivial, especially if this is occuring while network interfaces might be coming up or are not up. See the manpage of 'hostname' for warnings around '--fqdn'.

This was affecting our cobbler based installed systems. The ensemble/juju scripts were using 'hostname -f' to get a hostname that would be reachable. (That is still non-ideal due to the issues in hostname(1)).

These instances would be provisioned to have an entry in /etc/hosts like:
IP FQDN ALIAS [ALIAS2 [ ... ] ]
but cloud-init would then update the entry to have 'localdomain' as there was no local-hostname.

So, The solution proposed is:

• boot instance with old cloud-init
• verify it has cloud-init written entry in /etc/hosts
  127.0.1.1 server-912.localdomain server-912
  on ec2, 'localdomain' would be 'internal'. In either case, modify this, so that it the domain is 'mydomain' rather than 'localdomain' (so you can verify cloud-init changed that after reboot)
• add seed content without a local-hostname
  sudo rm -Rf /var/lib/cloud/
  sudo mkdir -p /var/lib/cloud/seed/nocloud-net
  python -c 'import boto.utils, pprint; md=boto.utils.get_instance_metadata(); del md["local-hostname"]; pprint.pprint(md);' > /tmp/meta-data
  sudo cp /tmp/meta-data /var/lib/cloud/seed/nocloud-net/meta-data
  sudo touch /var/lib/cloud/seed/nocloud-net/user-data
• sudo reboot

after reboot, 'hostname -f' should will show 'localdomain'

$ hostname -f

server-912.localdomain

and /etc/hosts has been updated by cloud-init.

That is the bug we want to fix.
With our fixed available, we can then:

• now, update /etc/hosts to have '$(hostname).mydomain' again
  sudo sed -i '/^127.0.1.1/d' /etc/hosts
  echo "127.0.1.1 $(hostname).mydomain $(hostname)" | sudo tee -a /etc/hosts

• now, install new cloud-init
  sudo dpkg -i cloud-init_0.6.2_all.deb

• clean meta-data
  for d in /var/lib/cloud/*; do [ "${d%seed}" = "$d" ] && sudo rm -Rf $d; done

• reboot

• verify that the host should now have:
  $ hostname -f
  server-912.mydomain

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: cloud-init 0.6.1-0ubuntu17
ProcVersionSignature: User Name 3.0.0-11.17-virtual 3.0.4
Uname: Linux 3.0.0-11-virtual x86_64
ApportVersion: 1.22.1-0ubuntu2
Architecture: amd64
Date: Wed Sep 14 17:13:08 2011
Ec2AMI: ami-00000085
Ec2AMIManifest: FIXME
Ec2AvailabilityZone: nova
Ec2InstanceType: m1.small
Ec2Kernel: unavailable
Ec2Ramdisk: unavailable
PackageArchitecture: all
ProcEnviron:
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: cloud-init
UpgradeStatus: No upgrade log present (probably fresh install)

This bug was originally filed in Launchpad as LP: #744965

affected_projects = ['cloud-init (Ubuntu)']
assignee = None
assignee_name = None
date_closed = 2011-10-28T02:19:28.855103+00:00
date_created = 2011-03-29T13:44:31.188960+00:00
date_fix_committed = 2011-06-15T18:07:40.377065+00:00
date_fix_released = 2011-10-28T02:19:28.855103+00:00
id = 744965
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/744965
milestone = None
owner = edward-edslifedaily
owner_name = Edward Ford
private = False
status = fix_released
submitter = edward-edslifedaily
submitter_name = Edward Ford
tags = ['ec2-images']
duplicates = []

Launchpad user Edward Ford(edward-edslifedaily) wrote on 2011-03-29T13:44:31.188960+00:00

user-data scripts will not run if script contains windows style line endings. Giving error "reports that /bin/bash^M could not be found."

Incidentally, this same reference (^M) is made in the "Newline" wikipedia article: (http://en.wikipedia.org/wiki/Newline#Common_problems)

A detailed thread relating to this bug can be found here: http://groups.google.com/group/ec2ubuntu/browse_thread/thread/236facaeccc4af1c

This bug was originally filed in Launchpad as LP: #861866

affected_projects = ['cloud-init (Ubuntu)']
assignee = smoser
assignee_name = Scott Moser
date_closed = 2011-10-28T02:21:01.503023+00:00
date_created = 2011-09-28T21:50:18.313956+00:00
date_fix_committed = 2011-10-27T19:47:58.463022+00:00
date_fix_released = 2011-10-28T02:21:01.503023+00:00
id = 861866
importance = medium
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/861866
milestone = None
owner = corvus
owner_name = James E. Blair
private = False
status = fix_released
submitter = corvus
submitter_name = James E. Blair
tags = ['server-o-rs']
duplicates = []

Launchpad user James E. Blair(corvus) wrote on 2011-09-28T21:50:18.313956+00:00

cloud-init-nonet only waites for an interface to be listed in the state file. But it could take a while to get an address. 60 seconds is not uncommon when waiting for DHCP (especially on a network with spanning tree).

This bug was originally filed in Launchpad as LP: #720603

affected_projects = []
assignee = None
assignee_name = None
date_closed = 2011-02-17T16:00:53.416465+00:00
date_created = 2011-02-17T09:34:59.518053+00:00
date_fix_committed = None
date_fix_released = None
id = 720603
importance = low
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/720603
milestone = None
owner = sloughton
owner_name = Shanon Loughton
private = False
status = wont_fix
submitter = sloughton
submitter_name = Shanon Loughton
tags = []
duplicates = []

Launchpad user Shanon Loughton(sloughton) wrote on 2011-02-17T09:34:59.518053+00:00

Steps to reproduce:

1. Create simple cloud-config script
2. make at least one blank line with a tab or \t character at the beginning
3. use script with a new run instance

Expected results:
cloud-init parser to ignore lines and continue to execute script

Actually Happens:
from instance's /var/log/cloud-init.log
"...cloud-config found character '\t' that cannot start any token "
The log reports that the \t character is invalid.

More Info:

• EG
  #This will cause error
  runcmd:
  (space)-(space)echo "Test"> /tmp/test.txt
  (tab)

• Appears to happen with valid config lines as well if a tab is used, rather than a space or multiple spaces.
  IE:

This works

runcmd:
(space)-(space)echo "Test" > /tmp/test.txt

#This will cause error
runcmd:
(tab)-(space)echo "Test"> /tmp/test.txt

This bug was originally filed in Launchpad as LP: #845161

affected_projects = []
assignee = avishai-ish-shalom
assignee_name = Avishai Ish-Shalom
date_closed = 2011-10-28T02:21:32.311200+00:00
date_created = 2011-09-08T21:29:18.605019+00:00
date_fix_committed = 2011-09-08T22:35:35.401052+00:00
date_fix_released = 2011-10-28T02:21:32.311200+00:00
id = 845161
importance = undecided
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/845161
milestone = None
owner = mmoulton
owner_name = Mike Moulton
private = False
status = fix_released
submitter = mmoulton
submitter_name = Mike Moulton
tags = []
duplicates = []

Launchpad user Mike Moulton(mmoulton) wrote on 2011-09-08T21:29:18.605019+00:00

The chef plugin developed by 'avishai' located in the branch 'lp:~avishai-ish-shalom/cloud-init/chef' has some issues as it stands in the Beta 1 release of oneiric.

Per the discussion here: https://code.launchpad.net/~avishai-ish-shalom/cloud-init/chef/+merge/66528 I have produced a patch to the head of the branch that resolves some syntactical issues. This patch applied to the 'lp:~avishai-ish-shalom/cloud-init/chef' branch produces a working version of the chef plugin.

This bug was originally filed in Launchpad as LP: #827590

affected_projects = ['nova', 'cloud-init (Ubuntu)', 'nova (Ubuntu)', 'cloud-init (Ubuntu Oneiric)', 'nova (Ubuntu Oneiric)']
assignee = None
assignee_name = None
date_closed = 2011-09-13T18:21:00.874190+00:00
date_created = 2011-08-16T19:22:28.284423+00:00
date_fix_committed = None
date_fix_released = None
id = 827590
importance = undecided
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/827590
milestone = None
owner = smoser
owner_name = Scott Moser
private = False
status = invalid
submitter = smoser
submitter_name = Scott Moser
tags = ['apport-bug', 'ec2-images', 'i386', 'oneiric', 'rls-mgr-o-tracking', 'server-o-rs']
duplicates = []

Launchpad user Scott Moser(smoser) wrote on 2011-08-16T19:22:28.284423+00:00

related bug:
bug 828357: request to add a label to the filesystem for ephemeral devices
bug 827598: ephemeral device does not have a filesystem

$ python -c 'import boto.utils; print boto.utils.get_instance_metadata()["block-device-mapping"]'
{'ami': 'sda1', 'root': '/dev/sda1', 'ephemeral0': 'sda2', 'swap': 'sda3'}

$ cat /proc/partitions
$ cat /proc/partitions
major minor #blocks name

 253 0 10485760 vda
 253 16 83886080 vdb

So there is an issue here, at very least the MD should say "/dev/sda" and "/dev/sdb" would be a better guess. Additionally, there is no third disk (as reported in 'swap') present at all.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: cloud-init 0.6.1-0ubuntu14
ProcVersionSignature: User Name 3.0.0-8.11-virtual 3.0.1
Uname: Linux 3.0.0-8-virtual i686
Architecture: i386
Date: Tue Aug 16 19:17:00 2011
Ec2AMI: ami-00000011
Ec2AMIManifest: FIXME
Ec2AvailabilityZone: nova
Ec2InstanceType: <nova.db.sqlalchemy.models.InstanceTypes object at 0x4f32090>
Ec2Kernel: aki-00000010
Ec2Ramdisk: unavailable
PackageArchitecture: all
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: cloud-init
UpgradeStatus: No upgrade log present (probably fresh install)

This bug was originally filed in Launchpad as LP: #847358

affected_projects = []
assignee = avishai-ish-shalom
assignee_name = Avishai Ish-Shalom
date_closed = 2022-11-02T10:00:02.350663+00:00
date_created = 2011-09-11T20:29:51.896176+00:00
date_fix_committed = None
date_fix_released = None
id = 847358
importance = low
is_complete = True
lp_url = https://bugs.launchpad.net/cloud-init/+bug/847358
milestone = None
owner = avishai-ish-shalom
owner_name = Avishai Ish-Shalom
private = False
status = wont_fix
submitter = avishai-ish-shalom
submitter_name = Avishai Ish-Shalom
tags = ['chef']
duplicates = []

Launchpad user Avishai Ish-Shalom(avishai-ish-shalom) wrote on 2011-09-11T20:29:51.896176+00:00

Chef integration plugin should provide support for chef-solo. currently it only supports chef-client