I'm marking the cloud-init task invalid. After getting config and logs
we confirmed that the cloud-init package in the Debian image does not
contain a recent handle_maas_preseed() that Ubuntu uses and curtin/MAAS
rely upon to install the MAAS datasource correctly.
** Changed in: cloud-init
I'm marking the curtin task invalid; after getting config and logs we
confirmed that the cloud-init package in the Debian image does not
contain a recent handle_maas_preseed() that Ubuntu uses and curtin/MAAS
rely upon to install the MAAS datasource correctly.
** Changed in: curtin
Status:
I'm marking this bug as Invalid. cloud-init is working as expected for
NoCloud datasource. Changes to the network-config during execution
can't affect cloud-inits behavior during boot with the NoCloud
datasource.
** Changed in: cloud-init
Status: New => Invalid
--
You received this bug
I'm marking this bug invalid, cloud-init is doing what it was told to do
and it appears looks like the user-data config relies on networking but
the network-config was marked optional.
Please move this bug state back to New if you have further questions or
issues.
** Changed in: cloud-init
** Changed in: cloud-init
Status: Expired => In Progress
** Changed in: cloud-init
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1893770
" # curl http://169.254.169.254/openstack/2018-08-27/network_data.json
{"links": [{"id": "tapa035fb68-01", "vif_id":
"a035fb68-010c-42e3-8da7-ea3c36a0d607", "type": "ovs", "mtu": 8942,
"ethernet_mac_address": "fa:16:3e:31:26:f7"}], "networks": [{"id": "network0",
"type": "ipv4_dhcp", "link":
@Sean you're right... the cloud-init fix was to handle the case there is *no*
/etc/fstab ...
so any other place that expects /etc/fstab to exist must also handle missing
file.
Looking at overlayroot, it expects to be able to update/modify the
baked-in fstab, but it's not there.
I'm marking cloud-init task invalid; by the time cloud-init runs, rootfs
should be rw using overlayfs backed by tmpfs.
** Changed in: cloud-init
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
https://cloud-images.ubuntu.com/daily/server/minimal/daily/focal/current
/focal-minimal-cloudimg-amd64.manifest
Has tzdata ...
This looks like a cloudimg issue, not cloud-init.
https://cloud-
images.ubuntu.com/daily/server/minimal/daily/bionic/current/bionic-
minimal-cloudimg-amd64.manifest
I'm marking this invalid; if you find more information that would
indicate that cloud-init is not booting like a new instance after
capturing on Ec2, please reopen this bug and include updated
information.
** Changed in: cloud-init
Status: New => Invalid
--
You received this bug
I'm marking the cloud-init task invalid; if you believe there is still a
bug in cloud-init, please re-open this task along with new information
explaining the bug.
** Changed in: cloud-init
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of
This issue has already been fixed in upstream cloud-init, see:
https://github.com/canonical/cloud-
init/commit/5352dd99eb2937b4eaaaf596b40ad7ca69d87f64
And
https://bugs.launchpad.net/cloud-init/+bug/1639263
For downstream, you'll need RedHat/Centos to cherry pick this commit.
If possible,
** Changed in: cloud-init
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1880177
Title:
cloud init netplan fails to apply (v2 18.04 cloud image)
** Also affects: cloud-init
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1879103
Title:
Unattended installation user data conflict
This issue was fixed a while back in:
https://github.com/canonical/cloud-init/commit/4bcc94730
cloud-init retains the legacy bits, but prefers the use of os-release
file or kernel commandline to for checking for UbuntuCore.
** Changed in: cloud-init (Ubuntu)
Status: Confirmed => Fix
Excellent news! Thanks for following up with Kali upstream. I'm
closing this issue as invalid for cloud-init. If you find out after the
Kali changes there are still issues, either re-open this bug or file a
new one if the issue/behavior is different.
Thanks!
** Changed in: cloud-init
** Changed in: cloud-init
Status: Expired => Incomplete
** Changed in: cloud-init
Importance: Undecided => Medium
** Changed in: cloud-init
Status: Incomplete => Triaged
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is
** Also affects: ifupdown (Ubuntu)
Importance: Undecided
Status: New
** Tags added: uec-images
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1867029
Title:
Package
Thanks for reporting the bug and attaching the logs. Looking at the
logs and your description it appears to be an issue with your Debian
image itself.
The files, /etc/network/if-pre-up.d/cloud_inet6 , and
/etc/cloud/cloud.cfg.d/99-disable-network-config.cfg are not part of
cloud-init itself.
Public bug reported:
Cloud-init currently logs all headers when processing URLs. On Ec2,
this includes the IMDSv2 token negotiation and all IMDS interactions.
The value of seeing the headers in the log is quite useful, especially
for confirming whether cloud-init is using IMDSv2 or not; however
The machine I'm working on uses cloud-init to update itself, it might
only have the fix after the updates.
ah, interesting
cat /etc/cloud/build.info
that'll give us a point in time for which version you have
and I suspect you're right, the top of your cloud-init.log will the
original
Public bug reported:
initramfs-tools used to only execute klibc based networking with some
resolvconf hooks.
In recent releases, it has been greatly improved to use
isc-dhcp-client instead of klibc, support vlan= key (like in
dracut-network), bring up Z devices using chzdev, and generate netplan
*** This bug is a duplicate of bug 1843334 ***
https://bugs.launchpad.net/bugs/1843334
** This bug has been marked a duplicate of bug 1843334
Change location of DHCP leases in CloudStack provider as it doesn't work for
RHEL8
--
You received this bug notification because you are a member
Thanks for filing a bug. I've added a dmidecode task to track the issue
with the tool. It may also affect the kernel package, and possibly
firmware (though that's not something that Ubuntu provides). Cloud-init
and any other tool may invoke this package and it should not reboot the
system; but
I'm marking the cloud-init task invalid as at this time the logs point
to a nested virtualization/openstack issue with devices not being
present; not related to cloud-init. If further investigation points to
an issue with cloud-init you can move the cloud-init task back to New.
** Changed in:
Public bug reported:
E: cloud-init source: untranslatable-debconf-templates cloud-init.templates: 6
W: cloud-init source: missing-file-from-potfiles-in grub.templates
W: cloud-init source: build-depends-on-obsolete-package build-depends:
dh-systemd => use debhelper (>= 9.20160709)
W: cloud-init
Public bug reported:
the list of modules has disappeared from the documentation sidebar.
- version 19.3: https://cloudinit.readthedocs.io/en/19.3/topics/modules.html
- version 19.2: https://cloudinit.readthedocs.io/en/19.2/topics/modules.html
In 19.2, the sidebar has an entry for each module,
On trusty; this complains but works.
ubuntu@ubuntu:~$ dpkg --list | grep util-linux
ii util-linux 2.20.1-5.1ubuntu20.9
amd64Miscellaneous system utilities
ubuntu@ubuntu:~$ cat /proc/partitions
major minor #blocks name
2530
*** This bug is a duplicate of bug 1821102 ***
https://bugs.launchpad.net/bugs/1821102
The logs do contain that bug, but I'm not sure that's the failure here.
Looking at the cloud-init logs, we can see the Ephemeral DHCP start and
obtain an lease, but the end point does not respond:
** Also affects: netplan.io (Ubuntu)
Importance: Undecided
Status: New
** Changed in: cloud-init
Importance: Undecided => Wishlist
** Changed in: cloud-init
Status: New => Triaged
--
You received this bug notification because you are a member of Yahoo!
Engineering Team,
cloud-init already has support for writing sysconfig formatted files on
systems which only include NetworkManager, specifically NetworkManager
includes a plugin module, 'ifcfg-rh' which reads the sysconfig files for
NetworkManager and cloud-init will enable this plugin as needed.
Please re-open
This was an release-branch only issue; it did not affect upstream cloud-
init.
** Also affects: cloud-init (Ubuntu)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Eoan)
Importance: Undecided
Status: New
** Changed in: cloud-init (Ubuntu Eoan)
I'm marking this invalid for cloud-init as the logs do not indicate
there is any cloud-init specific failure. As you debug if you find
something that cloud-init should have done, please move this bug state
back to New.
** Changed in: cloud-init
Status: New => Invalid
--
You received
** Changed in: cloud-init
Importance: Undecided => Medium
** Changed in: cloud-init
Status: Expired => Triaged
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1837106
Title:
** Changed in: cloud-init
Status: Expired => Triaged
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1832645
Title:
fs_setup/disk_setup: option to wait for the device to exist
Public bug reported:
Hi, we're still being affected by this on Azure with 19.2-24-ge7881d5c-
0ubuntu1~18.04.1 - using PACKER to build from image: BuildSource :
Marketplace/Canonical/UbuntuServer/18.04-DAILY-LTS
Here is the packer config:
"provisioners": [
{
"type":
OK, thanks for the logs. Could you re-attach those running via sudo (or
as root)? The default user on SLES does not have permissions to read
the journal.
What I see so far looks like networking did not come up after cloud-
init-local.service completes and writes out a network config.
Issue is related to local changes, marking invalid.
** Changed in: cloud-init
Status: Incomplete => Invalid
** Changed in: cloud-init (Suse)
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
Thanks for the bug and the logs. Looking at the network-config that was
generated:
>>> print(yaml.dump(nc, default_flow_style=False, indent=4))
ethernets:
eth0:
dhcp4: true
match:
macaddress: 00:0d:3a:6d:ca:25
set-name: eth0
nameservers:
Public bug reported:
While triaging a bug in sles'based distro using cloud-init, the collect-
logs output had a few issues:
1) the user did not have systemd journal privs
Unexpected error while running command.
Command: ['journalctl', '--boot=0', '-o', 'short-precise']
Exit code: 1
Reason: -
Looks like there's nothing for cloud-init here. Please reopen the
cloud-init task if that changes.
** Changed in: cloud-init
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
Moving cloud-init task to invalid, no bug/work for cloud-init.
** Changed in: cloud-init
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1839491
*** This bug is a duplicate of bug 1702160 ***
https://bugs.launchpad.net/bugs/1702160
** This bug has been marked a duplicate of bug 1702160
OpenStack datasource should not retry user-data on 404
--
You received this bug notification because you are a member of Yahoo!
Engineering Team,
Please reopen (mark as new) if you feel there's something that cloud-
init is not doing correctly.
** Changed in: cloud-init
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
** Changed in: cloud-init
Status: New => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1758409
Title:
integration tests: restructure ssh timeout
Status in
I'm marking the cloud-init task invalid; I don't believe cloud-init did
anything wrong; but please set the task back to New if you have new
information showing that cloud-init didn't do something quite right.
** Changed in: cloud-init
Status: New => Invalid
--
You received this bug
I'm closing this bug as Fixed Released.
** Changed in: cloud-init
Status: New => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1767002
Title:
When
Hi, I don't believe this is a cloud-init bug. Cloud-init wrote the two
certificate files requested.
2018-05-02 08:55:00,913 - stages.py[DEBUG]: Running module ca-certs () with
frequency once-per-instance
2018-05-02 08:55:00,914 - handlers.py[DEBUG]: start:
init-network/config-ca-certs:
Thanks for filing the bug. I believe this issue has been resolved in
this commit:
commit a8dcad9ac62bb1d2a4f7489960395bad6cac9382
Author: Scott Moser
Date: Wed Sep 5 16:02:25 2018 +
tests: Disallow use of util.subp except for where needed.
In many cases, cloud-init uses
Hi,
I don't think this is related to the cloud-init project so I'm marking
the cloud-init task as invalid.
** Changed in: cloud-init
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
This bug is believed to be fixed in cloud-init in version 19.2. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 19.2. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 19.2. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 19.2. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 19.2. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 19.2. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
** Also affects: cloud-init
Importance: Undecided
Status: New
** Changed in: cloud-init
Status: New => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
This bug is believed to be fixed in cloud-init in version 19.2. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 19.2. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 19.2. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: New => Fix Released
--
You received this bug notification because you are a member of
Public bug reported:
This bug tracks cloud-init upstream release of version 19.2.
** Affects: cloud-init
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
for non-physical interfaces, common attributes like mtu were not copied
into the internal state when merging v2 config.
** Changed in: curtin
Status: New => Invalid
** Changed in: cloud-init
Status: New => Confirmed
--
You received this bug notification because you are a member
I've added snapd so they can look into what's going on with
snapd.seeded.service.
** Also affects: snapd
Importance: Undecided
Status: New
** Changed in: cloud-init
Status: Incomplete => Invalid
** Summary changed:
- Modules steps not taken into account since 19.1
+
Public bug reported:
Azure added additional reporting trace points, the result is that
analyze/blame output doesn't look well formatted.
-- Boot Record 01 --
The total time elapsed since completing an event is printed after the "@"
character.
The time the event takes is printed after the "+"
Public bug reported:
Attempting a cloud_test run on lxd platform had this issue.
(diglett) cloud-init % tox -r -e citest -- run --verbose --platform=lxd
--os-name centos70 --rpm ~/cloud-init-19.1+44.g12efb6d3-1.el7.noarch.rpm
--result /tmp/centos7-result.yaml
GLOB sdist-make:
Public bug reported:
On systemd systems, the cloud-init-generator uses the ds-identify
program and hardcodes the path to the program. The value is correct for
Ubuntu/Debian and other systems, however on centos-based systems, ds-
identify is installed down libexec path.
** Affects: cloud-init
OK, good to know.
w.r.t SLES 15 and cloud-init; if you've attached a NoCloud datasource
correctly (your logs indicate that you are) then I would say yes this is
a bug.
Now, upstream since 18.4 there have been quite a few fixes applied which
may not have made it into SLES15, not 100% sure about
Public bug reported:
While looking to verify an apt_pipelining test-case fix I ran this:
% tox -e citest -- tree_run --verbose --os-name bionic --test
modules/apt_pipelining_disable --test modules/apt_pipelining_os --result
/tmp/result.yaml
During which, it would fail like this:
2019-03-31
2019-03-14 17:32:34,606 - __init__.py[DEBUG]: Selected renderer
'sysconfig' from priority list: None
This is a cloud-init bug. The sysconfig renderer has NetworkManager
support, this triggered cloud-init to render sysconfig instead of
netplan.
** Also affects: cloud-init
Importance:
Public bug reported:
On at least EC2 with cloud-init xenial release, the Ec2 datasource allows the
EventType.BOOT
event to update metadata and will regenerate network configuration on each
boot. Cloud-init releases newer than Xenial are not affected since cloud-init
will detect
which
** Also affects: cloud-init (Ubuntu Cosmic)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: cloud-init (Ubuntu Bionic)
Importance: Undecided
Status: New
--
You received this bug
** Also affects: cloud-init (Ubuntu)
Importance: Undecided
Status: New
** Changed in: cloud-init (Ubuntu)
Importance: Undecided => High
** Changed in: cloud-init (Ubuntu)
Status: New => In Progress
--
You received this bug notification because you are a member of Yahoo!
Public bug reported:
#cloud-config
# from 1 files
# part-001
---
chpasswd:
expire: false
list: 'root:$2y$10$8BQjxjVByHA/Ee.O1bCXtO8S7Y5WojbXWqnqYpUW.BrPx/Dlew1Va
'
>From #cloud-init
Hey there, I'm not sure whether I'm running into a bug or not
I'm trying to set the
Public bug reported:
Currently nocloud-net does not process network-config file if included
in the seed provided via a URL. This is by-design, however, now that
several datasources have this model of using an ephemeral DHCP process
to fetch user/metadata, which includes network-configuration and
This bug is believed to be fixed in cloud-init in version 18.5. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 18.5. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 18.5. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 18.5. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 18.5. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 18.5. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 18.5. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 18.5. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 18.5. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 18.5. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 18.5. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 18.5. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a
This bug is believed to be fixed in cloud-init in version 18.5. If this
is still a problem for you, please make a comment and set the state back
to New
Thank you.
** Changed in: cloud-init
Status: New => Fix Released
--
You received this bug notification because you are a member of
Public bug reported:
This bug tracks cloud-init upstream release of version 18.5.
** Affects: cloud-init
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
This bug is believed to be fixed in curtin in version 18.2. If this is
still a problem for you, please make a comment and set the state back to
New
Thank you.
** Changed in: curtin
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of
Please reopen if you feel there's an issue with how curtin is handling
the late_commands.
** Changed in: curtin
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
Public bug reported:
Attempted to cloud-init clean from a directory clean will remove:
/var/lib/cloud/instance# cloud-init clean --logs --reboot
Traceback (most recent call last):
File "/usr/bin/cloud-init", line 9, in
load_entry_point('cloud-init==18.3', 'console_scripts',
This is an expected route for RHEL/Centos defaults. Please re-open if
you think cloud-init needs to do something here.
** Changed in: cloud-init
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1749722
Title:
NTP: take into account systemd-timesyncd
Public bug reported:
cloud-init tip fails to render a netplan bridge configuration with a stp
value.
% cat network_configs/bridge-simple.yaml
showtrace: true
network:
version: 1
config:
# Physical interfaces.
- type: physical
name: eth0
mac_address:
Public bug reported:
DHCP clients can send specific values in the dhcp request such as
hostname, lease time, client_id, vendor_id, etc.
The dhcp configuration option in v1, and v2 (and others) only has dhcp
as a boolean.
v1:
network:
version: 1
config:
- type: physical
name: eth0
Public bug reported:
When init net stage runs, it will restore the cloud object cache in
/var/lib/cloud/instance/obj.pkl
This cache dump is created before cloud-init processes the datasource,
which means some of the data cloud-init has fetched is not cached.
In particular, we've observed that
They cannot just parse /etc/network/interfaces; curtin has always
written out an eni that includes a source
/etc/network/interfaces.d/*.cfg (meaning juju has a bug if they don't
read all eni configs).
Anyone parsing eni needs to read in all of the configs. In which case,
they would pickup any
You've an error in your cloud-config file
ubuntu@withkvm:/var/log$ cat /etc/cloud/cloud.cfg.d/99_landscape_client
cloud-config files need a .cfg extension to be read.
If I use your landscape config this way, I see landscape-client
installed and file written.
% cat landscape.yaml
#cloud-config
** Bug watch added: Red Hat Bugzilla #1468192
https://bugzilla.redhat.com/show_bug.cgi?id=1468192
** Also affects: cloud-init (CentOS) via
https://bugzilla.redhat.com/show_bug.cgi?id=1468192
Importance: Unknown
Status: Unknown
** Merge proposal linked:
Public bug reported:
when supplying cloud-init with a network-configuration in version:2
format, the rename code doesn't find any of the set-name parameters as
the function expects a v1 config format.
** Affects: cloud-init
Importance: Undecided
Status: New
--
You received this
1 - 100 of 123 matches
Mail list logo
