Age | Commit message (Collapse) | Author |
|
adding run-pylint makes it easy to run pylint with given configuration
against the code.
|
|
|
|
|
|
This is actually a pylint bug, but it considers use of string.letters
and string.whitespace deprecated.
|
|
|
|
|
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
This pulls in the named patch for LP: #914739 with a few other changes.
|
|
This merge pulls in Jeurg's 'fix-pylint-warnings.tgz' patchset from
LP: #914739.
|
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
|
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
|
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
|
|
single line)
From: Juerg Haefliger <juerg.haefliger@hp.com>
|
|
LP: #914739
|
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
|
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
outside __init__)
|
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
Replace superseded builtin functions 'filter' and 'map' using
list comprehension.
|
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
argument)
|
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
|
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
effect)
|
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
|
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
|
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
|
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
|
|
Juerg Haefliger <juerg.haefliger@hp.com>
|
|
instead of spaces)
From: Juerg Haefliger <juerg.haefliger@hp.com>
|
|
From: Juerg Haefliger <juerg.haefliger@hp.com>
|
|
|
|
|
|
|
|
Add initial tests for mergedict.
|
|
LP: #915282
|
|
|
|
on EC2, you can:
stop instance
resize root volume
start instance
Currently, the partition would get grown correctly in the initramfs, but
the root filesystem will not get automatically resized in that case as it
only runs per_instance.
This should not be harmfull in any case, as resizefs will just report
nothing to do:
$ sudo resize2fs /dev/sda5
resize2fs 1.42-WIP (16-Oct-2011)
The filesystem is already 25600278 blocks long. Nothing to do!
|
|
Previously,
* if content came into cloud-init for processing came in via a multipart
mime file, and was already base64 encoded, it would get base64 encoded
again before being handed to a part-handler.
* if it came in via a '#include'd file then it would not be encoded at
all.
This drops the internal 'parts' array, that was just converted to and then
from. Instead, we keep MIME format throughout and keep headers along
the way.
That means that a message that comes in with 'Content-Transfer-Encoding'
set to 'base64' will be decoded before being handed to a part-handler.
It also reduces the chance of failure due to content appearing to be an
actual email. Previously if content contained colon separated fields, it
might be read as headers (email.message_from_string(open("/etc/passwd","r"))
would come back as all headers, no payload)
The weak point right now is that '#include'd data cannot have mime types
associated with it (unless it is a mime formatted content). I had hoped
to read user headers and possibly set 'Content-Type' from that.
LP: #874342
|
|
|
|
Previously,
* if content came into cloud-init for processing came in via a multipart
mime file, and was already base64 encoded, it would get base64 encoded
again before being handed to a part-handler.
* if it came in via a '#include'd file then it would not be encoded at
all.
This drops the internal 'parts' array, that was just converted to and then
from. Instead, we keep MIME format throughout and keep headers along
the way.
That means that a message that comes in with 'Content-Transfer-Encoding'
set to 'base64' will be decoded before being handed to a part-handler.
It also reduces the chance of failure due to content appearing to be an
actual email. Previously if content contained colon separated fields, it
might be read as headers (email.message_from_string(open("/etc/passwd","r"))
would come back as all headers, no payload)
The weak point right now is that '#include'd data cannot have mime types
associated with it (unless it is a mime formatted content). I had hoped
to read user headers and possibly set 'Content-Type' from that.
|
|
This adds the ability to configure landscape client code from
cloud-config. The fields available are those that were populated to
/etc/landscape/client.conf when I ran landscape-config on precise
('11.07.1.1-0ubuntu2')
LP: #857366
|
|
|
|
|
|
This adds the ability to configure landscape client code from
cloud-config. The fields available are those that were populated to
/etc/landscape/client.conf when I ran landscape-config on precise
('11.07.1.1-0ubuntu2')
|
|
This is the same 2 changes that were made to cloud-init under LP: #904248
|
|
the environment varible INSTANCE_ID is set when invoking boothooks from
multi-part input. However, previously that was not the case for things
run via bootcmd.
This adds cloud-init-per, which makes it easy for user in bootcmd or
boothook to do something per 'instance', 'always', or 'once'.
The functionality in cloud-init-per mostly duplicated what was in
cloud-init-run-module. That supported "modules", but it is unlikely
that it was used for anything other than "execute". So, cloud-init-per
now replaces cloud-init-run-module and provides legacy support for
the 'execute' path.
|
|
|
|
|
|
- reference cloud-init-per
- mention that INSTANCE_ID is in environment of bootcmd scripts
|
|
This replaces cloud-init-run-module (which was probably rarely or never used)
with 'cloud-init-per' which does basically the same thing, but doesn't
support "modules".
|
|
|
|
Currently cloud-init writes something like this to console output:
ec2: #############################################################
ec2: -----BEGIN SSH HOST KEY FINGERPRINTS-----
ec2: 2048 78:ae:f3:91:04:6f:8d:ee:ef:e1:2d:72:83:6a:d0:82 root@h (RSA)
ec2: 1024 d3:b6:32:64:22:d4:43:05:f9:25:b4:f3:65:4e:e2:51 root@h (DSA)
ec2: -----END SSH HOST KEY FINGERPRINTS-----
ec2: #############################################################
the key fingerprints are useful for humans to read, but not so useful
for machines, as you cannot populate a KnownHostsFile (~/.ssh/known_hosts)
from the data there.
This change adds output like:
-----BEGIN SSH HOST KEY KEYS-----
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdH......STI= root@h
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDYRIQe6m......tWF3 root@h
-----END SSH HOST KEY KEYS-----
Those lines can easily be grabbed and appended to a known_hosts file.
LP: #893400
|
|
Currently cloud-init writes something like this to console output:
ec2: #############################################################
ec2: -----BEGIN SSH HOST KEY FINGERPRINTS-----
ec2: 2048 78:ae:f3:91:04:6f:8d:ee:ef:e1:2d:72:83:6a:d0:82 root@h (RSA)
ec2: 1024 d3:b6:32:64:22:d4:43:05:f9:25:b4:f3:65:4e:e2:51 root@h (DSA)
ec2: -----END SSH HOST KEY FINGERPRINTS-----
ec2: #############################################################
the key fingerprints are useful for humans to read, but not so useful
for machines, as you cannot populate a KnownHostsFile (~/.ssh/known_hosts)
from the data there.
This change adds output like:
-----BEGIN SSH HOST KEY KEYS-----
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdH......STI= root@h
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDYRIQe6m......tWF3 root@h
-----END SSH HOST KEY KEYS-----
Those lines can easily be grabbed and appended to a known_hosts file.
|
|
revision 490 missed some required imports.
|