Age | Commit message (Collapse) | Author |
|
On reboot (loading module from obj.pkl) we would hit a AttributeError
when trying to access cmdline_id.
Addtionally, dsmode was inadvertantly defaulting to local for
DataSourceNoCloud.
LP: #1592505
|
|
this would cause the datasource to operate in local mode by default.
|
|
python3's OSError does not have a .message attribute.
|
|
|
|
pylint --errors-only found several errors. Some of the changes
here represent real errors, others just code that pylint did
not like.
|
|
|
|
|
|
LP: #1592505
|
|
This commit includes the content of that commit, plus a fix for the tests
(provided by Phil).
|
|
This change broke tox tests.
|
|
A bug was reported (lp:1581200) where if there is no DNS server configured
or it is not running then the metadata lookup on GCE will fail as it contains a
trailing dot 'metadata.google.internal.'. As there is no DNS configured or
running it will use the /etc/hosts file but the hosts file does not contain
an entry with the trailing dot.
One solution is to add an entry to the /etc/hosts file with the trailing dot
but according to the manpage, /etc/hosts entries must end with an alphanumeric
character and cannot end with a dot.
The trailing dot was added to avoid MIM by dns search but we should probably
assume the instance being started has no DNS and as such when querying
metadata should use a URL that will resolve using /etc/hosts.
LP: #1581200
|
|
|
|
|
|
the network json in openstack provides a type of 'bridge' when
the underlying (host) type is a bridge. Silly, but we need to
consider that a physical device as it will be for us.
also, the 'mtu' will appear on the link, not on the route
|
|
'id' on a link in the openstack spec should be "Generic, generated ID".
current implementation was to use the host's name for the host
side nic. Which provided names like 'tap-adfasdffd'.
We do not want to name devices like that as its quite unexpected
and non user friendly. So here we use the system name for any
nic that is present, but then require that the nics found also
be present at the time of rendering.
The end result is that if the system boots with net.ifnames=0
then it will get 'eth0' like names. and if it boots without net.ifnames
then it will get enp0s1 like names.
|
|
When the .pkl file is loaded, the module that it is loaded
from must have the same symbol. Ie, if booted once and got
DataSourceConfigDriveNet
then upgraded and rebooted, then next boot would show
Can't get attribute 'DataSourceConfigDriveNet'
|
|
|
|
if get_smartos_environ() returned a None, then
the datasoure would raise a ValueError when get_data was called.
Fix that.
|
|
The network config file is /etc/network/interfaces formated.
We will decode that here so that the user can expect that it is
a string. The issue was that it was bytes but convert_eni_data
was expecting a string.
|
|
This adds support for reading networking information from the
SmartOS metadata service and applying.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
configdrive
|
|
|
|
|
|
== background ==
DataSource Mode (dsmode) is present in many datasources in cloud-init.
dsmode was originally added to cloud-init to specify when this datasource
should be 'realized'.
cloud-init has 4 stages of boot.
a.) cloud-init --local . network is guaranteed not present.
b.) cloud-init (--network). network is guaranteed present.
c.) cloud-config
d.) cloud-init final
'init_modules' [1] are run "as early as possible". And as such, are executed
in either 'a' or 'b' based on the datasource. However, executing them means
that user-data has been fully consumed. User-data and vendor-data may have
'#include http://...' which then rely on the network being present. boothooks
are an example of the things run in init_modules.
The 'dsmode' was a way for a user to indicate that init_modules
should run at 'a' (dsmode=local) or 'b' (dsmode=net) directly.
Things were further confused when a datasource could provide networking
configuration. Then, we needed to apply the networking config at 'a'
but if the user had provided boothooks that expected networking, then the
init_modules would need to be executed at 'b'. The config drive datasource
hacked its way through this and applies networking if *it* detects it is
a new instance.
== Suggested Change ==
The plan is to
1. incorporate 'dsmode' into DataSource superclass
2. make all existing datasources default to network
3. apply any networking configuration from a datasource on first boot only
apply_networking will always rename network devices when it runs.
for bug 1579130.
4. run init_modules at cloud-init (network) time frame unless datasource
is 'local'.
5. Datasources can provide a 'first_boot' method that will be called when
a new instance_id is found. This will allow the config drive's write_files
to be applied once.
Over all, this will very much simplify things. We'll no longer have
2 sources like DataSourceNoCloud and DataSourceNoCloudNet, but would just
have one source with a dsmode.
== Concerns ==
Some things have odd reliance on dsmode. For example, OpenNebula's get_hostname
uses it to determine if it should do a lookup of an ip address.
== Bugs to fix here ==
http://pad.lv/1577982 ConfigDrive: cloud-init fails to configure network from network_data.json
http://pad.lv/1579130 need to support systemd.link renaming of devices in container
http://pad.lv/1577844 Drop unnecessary blocking of all net udev rules
|
|
|
|
|
|
This allows it to be used outside of cloudinit
more easily in the future.
|
|
Timeouts and retries were triggering so make it so
that tests do not use the typical timesouts and retries
so that the tests finish faster.
|
|
|
|
|
|
|
|
Instead of aborting all serial using tests instead just
create a serial module in cloudinit that will create a fake
and broken serial class when pyserial is not actually installed.
This allows for using the datasource and tests that exist in
a more functional and tested manner (even when pyserial is not
found).
|
|
|
|
|
|
|
|
|
|
After reboot cloud-init would fail as the previously pickled object
would have a check_instance_id signature but it didn't match expected
LP: #1575055
|