| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
handling of cloud-config-archive input would fail in fully_decoded_payload.
part.get_charset() would return a Charset object, but
get_charset.input_codec is a string suitable for passing to decode.
This handles that correctly, and is more careful about binary data inside
input.
The test added verifies that cloud-config inside a cloud-config-archive
is handled correctly and also that binary data there is ignored without
exceptions raised.
LP: #1445143
|
|
|
|
don't declare a Wants/Requires on network.target; this is a passive target
that should only be pulled in by implementors of the networking service.
The requirement for network needs to be expressed as a dependency on
network-online.target.
LP: #1440180
|
|
It was believed that to install a package with config the command was:
snappy install --config=config-file <package>
Instead, what was implemented in snappy was:
snappy install <package> [<config-file>]
This modifies cloud-init to invoke the latter and changes the tests
appropriately.
LP: #1438836
|
|
Some tests added here to make sure this works.
The install '--config' will only start to work with the next
version of snappy-go.
LP: #1437137
|
|
|
|
|
|
|
|
On fspath installs, look for .config files harder.
Given a file named:
pkg.namespace_0.version_arch.snap
We'll search for config files named:
pkg.namespace_0.version_arch.config
pkg.namespace.config
pkg.config
|
|
|
|
The intent has always been for the local datasource (NoCloud) to require
the provider of metadata to provide 'dsmode=local'. If that wasn't found,
then the default 'dsmode' would be 'net', and the NoCloudNet datasource
would then find the data.
The bug here was that the default 'net' wasn't being set when
data was found on a local source.
|
|
|
|
|
|
|
|
the input to 'snappy config <packagename>' is expected to have
config:
<packagename>:
content:
So here we pad that input correctly. Note, that a .config file
on disk is not modified.
Also, we change 'configs' to just be 'config', to be possibly compatible
with the a future 'snappy config /' that dumped:
config:
pkg1: data1
pkg2: data2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
v2 metadata is described at
http://eng.joyent.com/mdata/protocol.html
LP: #1436417
|
|
|
|
|
|
|
|
|
|
|
|
We are treating JoyentMetadataClient as a unit which the data source
depends on, so we mock it out instead of providing a fake implementation
of it.
|
|
|
|
|
|
LP: #1432758
|
|
We were hitting exceptions when writing to the SmartOS serial console and, once
that was fixed, we were hanging permanently waiting for b"." == "." to be true.
This fixes both of those issues.
|
|
|
|
|
|
Cloud-init crashed when received multipart userdata object with
'application/octet-stream' part or some other 'application/*' part
except archived ones (x-gzip and friends). These parts are not
processed by cloud-init and result only in a message in the log.
We used some non-python3-friendly techniques while generating
this log message which was a reason for the crash.
|
|
oddly enough, the timestamp you pass into oauthlib must be a None
or a string. If not, raises ValueError:
Only unicode objects are escapable. Got 1426021488 of type <class 'int'>
|
|
|
|
this does 2 things actually
a.) disables snappy by default, and adds checks to filesystem to enable it
this way it runs on snappy systems, but not on others.
b.) removes the 'render2env' that was mostly spike code.
LP: #1428495
|
|
|
|
This functionality has been introduced to fix LP: #978127, but was lost
while migrating cloud-init to python3.
LP: #1427939
|
|
|
|
clock skew
This functionality has been introduced to fix LP: #978127, but was lost
while migrating cloud-init to python3.
|
