This option allows users to suspend execution of the cloud-init provisioning
until a valid network is detected.
This detection is currently done through requesting a DNS lookup for one
of the Clear Linux NTP service IP addresses (this is a RR record, we
don't actually look at the result).
This lookup is not infinite. After 5 minutes, the wait exits no matter
what even if there is no network detected.
The option can be provided manually. `packages` and `package_upgrade`
options *imply* this option, but one can explicitly disable the wait
by providing it early in the cloud-config file with a value of `false`.
The wait routing is active - it will retry relatively quickly to detect
an active connection. Any failure will result in another retry. In
a fully private network without public DNS, this will not work.
The DNS hostname used for testing can be manipulated through the
`-with-dnstestaddr=<hostname>` configure flag. You shouldn't put an
IP address in here, since that fully disables any network testing.
When I deduplicated this code I mistakenly used parse_headers() in
the same way twice. This was incorrect.
We definitely need to error out if a 404 or something else happens
for the SSH keys, since then we've lost entirely.
But a missing `user-data` is mostly harmless and optional, so, in
case a 404 happens for the second `GET` request, we shouldn't error
out, because this makes the instance unusable. Instead, we can
carry on as normal.
Create a new function for both sections of code needing to output
remainder stream bytes into output file. This makes error handling simpler
and easier to focus on the errors here in tencent.
I've adapted the code to use the OCI model of outputting the needed
data since OCI code written by William handles the output slightly
different based on previous experiences with OCI and I think this may
just help the Tencent case as well.
Also change some types to reduce casting. All in all this slightly
cleans up the code a bit.
We do not want to break anything where HTTP/1.0 is only supported,
so we advertise 1.1 but allow responses from 1.0 capable server
as well as 1.1 capable servers.
Instead of keep duplicating existing code, we can make this program
a little bit more versatile and cover all 3 use cases and add some
extensibility for further additions.
A static table describes what needs fetching and from where. The
rest is logically the same and so the delta isn't so bad.
We add tencent cloud support on top of this.
Other cloud-config implementations like cloud-init resizes automatically the
rootfs to the maximum allowed, ucd should do the same.
fixes#34
Signed-off-by: Julio Montes <julio.montes@intel.com>
On some of the computational AWS instances, the HTTP service at
169.254* does not support HTTP/1.0 keep-alive. This causes the
second part of the user-data not to be transferred and results
in an error during the execution of ucd-aws. Subsequently, the
SSH key never gets provisioned by `ucd`. The result is an unusable
AWS instance that can't be remotely logged into.
Instead, we just terminate and reconnect for the second HTTP
request, reusing some memory where we can. This is a minute
bit slower, and doesn't really come at a size penalty either,
since it's just the same functions being used.
Since we have another task also run `usermod` as well, these
might bump into a lock file for /etc/ files and fail, leaving
the system unable to login a normal user.
This adds support for parsing openstack meta-data.json files in
config-2 filesystems and extracting and installing any SSH pubkeys
into the default user account.
In order to properly parse a config-2 json blob outside of the normal
openstack early initialization, we need to fill the parser table
properly and clean it up.
This exposes some flaws in other parts of this code that appear that
this wasn't entirely fully tested. I have not yet confirmed that
in a config-2 scenario everything actually automatically works yet,
this remains to be done.
Auke Kok