from:"Bug Watch Updater"

[Yahoo-eng-team] [Bug 2057763] Re: Ubuntu 22.04 (v20240301) boot delay of ~2 minutes due to timeout in DataSourceMAAS

2024-03-19 Thread Bug Watch Updater

** 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/2057763

Title:
  Ubuntu 22.04 (v20240301) boot delay of ~2 minutes due to timeout in
  DataSourceMAAS

Status in cloud-init:
  Fix Released
Status in MAAS:
  Triaged

Bug description:
  On every MAAS version when I deploy ubuntu 22.04
  (https://images.maas.io/ephemeral-v3/stable/jammy/amd64/20240301/) the
  os is properly installed, but when the machine reboots there is a
  delay in the startup and looking at the journalctl logs it's possible
  to see a timeout of ~2 minutes for the DataSourceMAAS that failed to
  make some requests to the rack.

  ```
  Mar 13 09:25:05 ubuntu cloud-init[572]: Cloud-init v. 23.4.3-0ubuntu0~20.04.1 
running 'init-local' at Wed, 13 Mar 2024 09:25:05 +. Up 4.05 seconds.
  Mar 13 09:25:05 ubuntu cloud-init[572]: 2024-03-13 09:25:05,794 - 
handlers.py[WARNING]: Failed posting event: {"name": "init-local/check-cache", 
"description": "attempting to read from cache [trust]", "event_type": "start", 
"origin": "cloudinit", "timestamp": 1710321905.77>
  Mar 13 09:25:05 ubuntu cloud-init[572]: 2024-03-13 09:25:05,795 - 
handlers.py[WARNING]: Failed posting event: {"name": "init-local/check-cache", 
"description": "no cache found", "event_type": "finish", "origin": "cloudinit", 
"timestamp": 1710321905.7760243, "result": "SUCC>
  Mar 13 09:25:05 ubuntu cloud-init[572]: 2024-03-13 09:25:05,796 - 
handlers.py[WARNING]: Failed posting event: {"name": "init-local/search-MAAS", 
"description": "searching for local data from DataSourceMAAS", "event_type": 
"start", "origin": "cloudinit", "timestamp": 171032>
  Mar 13 09:25:34 ubuntu systemd[1]: systemd-fsckd.service: Succeeded.
  Mar 13 09:27:12 ubuntu cloud-init[572]: 2024-03-13 09:27:12,029 - 
url_helper.py[ERROR]: Timed out, no response from urls: 
['http://10.0.2.250:5248/MAAS/metadata/2012-03-01/meta-data/instance-id']
  Mar 13 09:27:12 ubuntu cloud-init[572]: 2024-03-13 09:27:12,030 - 
DataSourceMAAS.py[CRITICAL]: Giving up on md from 
['http://10.0.2.250:5248/MAAS/metadata/2012-03-01/meta-data/instance-id'] after 
126 seconds
  Mar 13 09:27:12 ubuntu cloud-init[572]: 2024-03-13 09:27:12,036 - 
handlers.py[WARNING]: Failed posting event: {"name": "init-local/search-MAAS", 
"description": "no local data found from DataSourceMAAS", "event_type": 
"finish", "origin": "cloudinit", "timestamp": 1710322032>
  Mar 13 09:27:12 ubuntu systemd[1]: Condition check resulted in OpenVSwitch 
configuration for cleanup being skipped.
  Mar 13 09:27:12 ubuntu cloud-init[572]: 2024-03-13 09:27:12,169 - 
handlers.py[WARNING]: Failed posting event: {"name": "init-local", 
"description": "searching for local datasources", "event_type": "finish", 
"origin": "cloudinit", "timestamp": 1710322032.1686447, "result": >
  Mar 13 09:27:12 ubuntu cloud-init[572]: 2024-03-13 09:27:12,169 - 
handlers.py[WARNING]: Multiple consecutive failures in WebHookHandler. 
Cancelling all queued events.
  ```

  The issue here is the delay of ~2 minutes in the boot process

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2057763/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 2027975] Re: Add check on network interface name's length

2024-01-19 Thread Bug Watch Updater

** 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/2027975

Title:
  Add check on network interface name's length

Status in cloud-init:
  Fix Released
Status in MAAS:
  Triaged

Bug description:
  When adding a VLAN on long network interfaces, Cloud-init will fail
  silently to add the sub-interfaces.

  Deployed environment is :
  * MAAS 3.3.4
  * Server Dell R630 + Mellanox Connectx-5
  * name of interfaces : enp130s0f0np0 / enp130s0f1np1
  * add a VLAN like 100-4093

  Cloud-Init will not display any error message but the VLAN interfaces will 
not be added after the deployment.
  If trying to perform the operation manually, we are then greeted with the 
following error message.

  ```
  ubuntu@R630:~$ sudo ip link add link enp130s0f0np0 name enp130s0f0np0.103 
type vlan id 103
  Error: argument "enp130s0f0np0.103" is wrong: "name" not a valid ifname
  ```

  From Iproute2 and Kernel perspective, it is not possible to have
  interfaces with a name longer than 15 characters in total.

  A quick workaround is simply to rename the network interface to something 
shorter.
  Having a quick warning from MAAS would be nice to have to understand the 
origin of the issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2027975/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 2020375] Re: Focal loses network configuration due to failed netplan generate

2023-05-23 Thread Bug Watch Updater

** 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/2020375

Title:
  Focal loses network configuration due to failed netplan generate

Status in cloud-init:
  Fix Released
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Focal:
  Fix Released

Bug description:
  See regression reported here:

  https://github.com/canonical/cloud-init/issues/4133

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/2020375/+subscriptions


-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1745671] Re: ENI format - configuring metadata network-interfaces with iface defined twice but different family breaks all networking on cloud-init instance

2021-12-11 Thread Bug Watch Updater

** Changed in: cloud-init (CentOS)
   Status: In Progress => 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/1745671

Title:
  ENI format -  configuring metadata network-interfaces with iface
  defined twice but different family breaks all networking on cloud-init
  instance

Status in cloud-init:
  Triaged
Status in cloud-init package in CentOS:
  Fix Released

Bug description:
  Description of problem:
  Configuring metadata network-interfaces with "iface eth2 inet6 static" breaks 
all networking on cloud-init instance. This only works when configuring a sub 
interface.

  The following breaks networking:
  ~~~
  auto eth2
  iface eth2 inet static
  address 192.168.0.166
  network services
  netmask 255.255.0.0
  broadcast 192.168.255.255
  gateway 192.168.0.1
  iface eth2 inet6 static
  address 2001::166
  gateway 2001::1
  hwaddress aa:aa:aa:bb:bb:bb
  ~~~

  According to https://wiki.debian.org/NetworkConfiguration , this should work, 
though:
  +++
  If you're configuring it manually then something like this will set the 
default gateway (network, broadcast and gateway are optional):

  auto eth0
  iface eth0 inet static
  address 192.0.2.7
  netmask 255.255.255.0
  gateway 192.0.2.254

  If you want to add an IPv6 address, too, append something like:

  iface eth0 inet6 static
  address 2001:db8::c0ca:1eaf
  netmask 64
  gateway 2001:db8::1ead:ed:beef
  +++

  And https://manpages.debian.org/jessie/ifupdown/interfaces.5.en.html
  +++
  Options are usually indented for clarity (as in the example above) but are 
not required to be. 
  +++

  The following works correctly:
  ~~~
  iface eth2 inet static
  address 192.168.0.166
  network services
  netmask 255.255.0.0
  broadcast 192.168.255.255
  gateway 192.168.0.1
  auto eth2:0
  iface eth2:0 inet6 static
  address 2001::166
  gateway 2001::1
  hwaddress aa:aa:aa:bb:bb:bb
  ~~~

  Additional info:
  result working:

  
  Working instance: 
./sosreport-20180125-075718/svc-1-lvsrouter/var/log/cloud-init-output.log
  ~~~
  Cloud-init v. 0.7.9 running 'init-local' at Thu, 25 Jan 2018 07:48:44 +. 
Up 12.41 seconds.
  Cloud-init v. 0.7.9 running 'init' at Thu, 25 Jan 2018 07:48:47 +. Up 
16.00 seconds.
  ci-info: +++Net device 
info
  ci-info: 
++--++---+---+---+
  ci-info: | Device |  Up  |Address |  Mask | Scope | 
Hw-Address|
  ci-info: 
++--++---+---+---+
  ci-info: |  lo:   | True |   127.0.0.1|   255.0.0.0   |   .   | . 
|
  ci-info: |  lo:   | True |   .|   .   |   d   | . 
|
  ci-info: | eth1:  | True | 10.250.246.171 | 255.255.252.0 |   .   | 
xx:xx:xx:xx:xx:xx |
  ci-info: | eth1:  | True |   .|   .   |   d   | 
xx:xx:xx:xx:xx:xx |
  ci-info: | eth2:  | True | 192.168.0.166  |  255.255.0.0  |   .   | 
xx:xx:xx:xx:xx:xx |
  ci-info: | eth2:  | True |   .|   .   |   d   | 
xx:xx:xx:xx:xx:xx |
  ci-info: | eth0:  | True | 10.247.246.174 | 255.255.252.0 |   .   | 
xx:xx:xx:xx:xx:xx |
  ci-info: | eth0:  | True |   .|   .   |   d   | 
xx:xx:xx:xx:xx:xx |
  ci-info: | eth3:  | True | 172.16.30.226  | 255.255.255.0 |   .   | 
xx:xx:xx:xx:xx:xx |
  ci-info: | eth3:  | True |   .|   .   |   d   | 
xx:xx:xx:xx:xx:xx |
  ci-info: 
++--++---+---+---+
  ci-info: +Route IPv4 
info++
  ci-info: 
+---+--+-+---+---+---+
  ci-info: | Route | Destination  |   Gateway   |Genmask| Interface | 
Flags |
  ci-info: 
+---+--+-+---+---+---+
  ci-info: |   0   |   0.0.0.0| 192.168.0.1 |0.0.0.0|eth2   |   
UG  |
  ci-info: |   1   | 10.247.244.0 |   0.0.0.0   | 255.255.252.0 |eth0   |   
U   |
  ci-info: |   2   | 10.250.244.0 |   0.0.0.0   | 255.255.252.0 |eth1   |   
U   |
  ci-info: |   3   | 172.16.30.0  |   0.0.0.0   | 255.255.255.0 |eth3   |   
U   |
  ci-info: |   4   | 192.168.0.0  |   0.0.0.0   |  255.255.0.0  |eth2   |   
U   |
  ci-info: 
+---+--+-+---+---+---+
  Cloud-init v. 0.7.9 running 'modules:config' at Thu, 25 Jan 2018 07:48:50 
+. Up 19.03 seconds.
  ~~~

  result not working:
  ~~~
  Cloud-init v. 0.7.9 running 'init-local' at Thu, 25 Jan 2018 11:50:02 +. 
Up 7.98 seconds.
  Cloud-init v. 0.7.9 running 'init' at Thu, 25 Jan 2018 11:50:10 +. Up 
15.71 seconds.
  2018-01-25 06:50:10,348 - util.py[WARNING]:

[Yahoo-eng-team] [Bug 1717147] Re: cloud-init 0.7.9 fails for CentOS 7.4 in Cloudstack

2020-12-30 Thread Bug Watch Updater

** Changed in: cloud-init (CentOS)
   Status: Fix Committed => 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/1717147

Title:
  cloud-init 0.7.9 fails for CentOS 7.4 in Cloudstack

Status in cloud-init:
  Fix Released
Status in cloud-init package in CentOS:
  Fix Released

Bug description:
  Environment:
  CentOS 7.4, cloud-init-0.7.9-9.el7.centos.2.x86_64

  Problem (quick):
  CentOS 7.4 builds on Cloudstack 4.8 don't run cloud-init because the newer 
version of cloud-init doesn't appear to like the way the dhclient lease file is 
named.

  Problem (long):

  I've just built a CentOS 7.4 instance in one of my CloudStack 4.8
  clusters.  Unfortunately, cloud-init fails with the following in
  snippet in /var/log/cloud-init.log:

  2017-09-13 18:53:00,118 - __init__.py[DEBUG]: Seeing if we can get any data 
from 
  2017-09-13 18:53:00,118 - DataSourceCloudStack.py[DEBUG]: Using 
/var/lib/dhclient lease directory
  2017-09-13 18:53:00,118 - DataSourceCloudStack.py[DEBUG]: No lease file 
found, using default gateway

  Where it then tries to use the default route to download userdata.
  The problem is that we're not using the Cloudstack VR as a default
  router, so I expected it to parse /var/lib/dhclient/dhclient--
  eth0.lease for the "dhcp-server-identifier" line.

  Theory as to cause:
  I believe that this change 
(https://github.com/cloud-init/cloud-init/commit/aee0edd93cb4d78b5e0d1aec71e977aabf31cdd0#diff-5bc9de2bb7889d66205845400c7cf99b)
 breaks cloud-init beyond the 7.3-distributed cloud-0.7.5 when 7.4 includes 
0.7.9-9.

  Fix:

  Changing it from "dhclient." to "dhclient-" in /usr/lib/python2.7
  /site-packages/cloudinit/sources/DataSourceCloudStack.py on the
  running box with an installed RPM did the trick theoretically (after
  removing the pyc and pyo files, of course).

  This *can* be patched around by RedHat/CentOS (and hopefully will),
  but I figure it might be better to take it straight upstream.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1717147/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1693361] Re: cloud-init sometimes fails on dpkg lock due to concurrent apt-daily.service execution

2020-04-09 Thread Bug Watch Updater

** Changed in: apt
   Status: Confirmed => 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/1693361

Title:
  cloud-init sometimes fails on dpkg lock due to concurrent apt-
  daily.service execution

Status in APT:
  Fix Released
Status in cloud-init:
  Fix Released
Status in apt package in Ubuntu:
  Invalid
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-init source package in Yakkety:
  Won't Fix
Status in cloud-init source package in Zesty:
  Fix Released
Status in cloud-init source package in Artful:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  A cloud-config that contains packages to install (see below) or
  'package_upgrade' will run 'apt-get update'.  That can sometimes fail as a
  result of contention with the apt-daily.service that updates that information.

  Cloud-config showing the problem is just like:

    $ cat my.yaml
    #cloud-config
    packages: ['hello']

  [Test Case]
  lxc-proposed-snapshot is
    
https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/lxc-proposed-snapshot
  It publishes an image to lxd with proposed enabled and cloud-init upgraded.

  a.) launch an instance with proposed version of cloud-init and some user-data.
     This is platform independent.  The test case demonstrates lxd.
     $ printf "%s\n%s\n%s\n" "#cloud-config" "packages: ['hello']" \
     "package_upgrade: true" > config.yaml
     $ release=xenial
     $ ref=proposed-$release
     $ ./lxc-proposed-snapshot --proposed --publish $release $ref;

  b.) start the instance
     $ name=$release-1693361
     $ lxc launch my-xenial "--config=user.user-data=$(cat config.yaml)
     $ sleep 1
     $ lxc exec $name -- tail -f /var/log/cloud-init.log 
/var/log/cloud-init-output.log
     # watch this boot.

   c.) Look for evidence of systemd failure
     journalctl -o short-precise | grep -i break
     journalctl -o short-precise | grep -i order

  [Regression Potential]
  Regression chance here is low.  Its possible that ordering loops
  could occur.  When that does happen, journalctl will mention it.  
Unfortunately
  in such cases systemd somewhat randomly picks a service to kil so behavior
  is somewhat undefined.

  [Other Info]
  Upstream commit at
    https://git.launchpad.net/cloud-init/commit/?id=11121fe4

  === End SRU Template ===

  apt-daily is now a systemd service rather than being invoked by
  cron.daily.  If one builds a custom AMI it is possible that the apt-
  daily.timer will fire during boot.  This can fire at the same time
  cloud-init is running and if cloud-init loses the race the invocation
  of apt (e.g. use of "packages:" in the config) will fail.

  There is a lot of discussion online about this change to apt-daily
  (e.g. unattended upgrades happening during business hours, delaying
  boot, etc.) and discussion of potential systemd changes regarding
  timers firing during boot (c.f.
  https://github.com/systemd/systemd/issues/5659).

  While it would be better to solve this in apt itself, I suggest that
  cloud-init be defensive when calling apt and implement some retry
  mechanism.

  Various instances of people running into this issue:

  https://github.com/chef/bento/issues/609
  https://clusterhq.atlassian.net/browse/FLOC-4486
  https://github.com/boxcutter/ubuntu/issues/73
  
https://unix.stackexchange.com/questions/315502/how-to-disable-apt-daily-service-on-ubuntu-cloud-vm-image

To manage notifications about this bug go to:
https://bugs.launchpad.net/apt/+bug/1693361/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1800848] Re: does not recognize cloned KVM VM as new instance

2019-05-28 Thread Bug Watch Updater

** Changed in: cloud-init (Suse)
   Status: Confirmed => 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/1800848

Title:
  does not recognize cloned KVM VM as new instance

Status in cloud-init:
  New
Status in cloud-init package in Suse:
  Fix Released

Bug description:
  On a SLES 15 KVM VM on Proxmox VE  cloud-init 18.2-3.13 from
  module/repo Public-Cloud-Module_15-0  cloud-init fails to recognize a
  newly cloned VM from a template where cloud-init has initially been
  run for test purposes as a new instance. VM is using NoCloud resource.

  This leads to network configuration not applied and thus duplicate IP
  addresses when VM is started:

  % tail -f /var/log/cloud-init.log | grep -v util.py
  2018-10-31 13:55:27,370 - __init__.py[INFO]: 
/var/lib/cloud/data/previous-hostname differs from /etc/hostname, assuming user 
maintained hostname.
  2018-10-31 13:57:37,431 - main.py[DEBUG]: No kernel command line url found.
  2018-10-31 13:57:37,431 - main.py[DEBUG]: Closing stdin.
  2018-10-31 13:57:37,454 - main.py[DEBUG]: Checking to see if files that we 
need already exist from a previous run that would allow us to stop early.
  2018-10-31 13:57:37,455 - main.py[DEBUG]: Execution continuing, no previous 
run detected that would allow us to stop early.
  2018-10-31 13:57:37,455 - handlers.py[DEBUG]: start: 
init-network/check-cache: attempting to read from cache [trust]
  2018-10-31 13:57:37,463 - stages.py[DEBUG]: restored from cache with run 
check: DataSourceNoCloudNet [seed=/dev/sr0] [dsmode=net]
  2018-10-31 13:57:37,464 - handlers.py[DEBUG]: finish: 
init-network/check-cache: SUCCESS: restored from cache with run check: 
DataSourceNoCloudNet [seed=/dev/sr0][dsmode=net]
  2018-10-31 13:57:37,488 - stages.py[DEBUG]: previous iid found to be 
414842fe12da6f1078eca77443e6ab84592299ba
  2018-10-31 13:57:37,493 - main.py[DEBUG]: [net] init will now be targeting 
instance id: 414842fe12da6f1078eca77443e6ab84592299ba. new=False
  2018-10-31 13:57:37,514 - stages.py[DEBUG]: applying net config names for 
{'version': 1, 'config': [{'type': 'physical', 'name': 'eth0', 'mac_address': 
'76:61:cf:d5:65:b2', 'subnets': [{'type': 'static', 'address': '10.0.88.32', 
'netmask': '255.255.0.0', 'gateway': '10.0.0.4'}, {'type': 'static', 'address': 
'auto'}]}, {'type': 'nameserver', 'address': ['10.0.0.4'], 'search': 
['qs.de']}]}
  2018-10-31 13:57:37,515 - stages.py[DEBUG]: Using distro class 
  2018-10-31 13:57:37,529 - __init__.py[DEBUG]: no work necessary for renaming 
of [['76:61:cf:d5:65:b2', 'eth0', 'virtio_net', '0x0001']]
  2018-10-31 13:57:37,530 - stages.py[DEBUG]: not a new instance. network 
config is not applied.

  Network configuration obviously was changed however.

  Commands used for cloning (using a self-made shell script)

  qm shutdown 1032 ; qm clone 1032 2200 --name slesmaster ; qm template 2200
  qm clone 2200 2201 --name sles1 ; qm set 2201 --ipconfig0 
ip=10.0.88.201/8,gw=10.0.0.4 ; qm start 2201
  qm clone 2200 2202 --name sles2 ; qm set 2202 --ipconfig0 
ip=10.0.88.202/8,gw=10.0.0.4 ; qm start 2202

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1800848/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1771382] Re: ds-identify: fails to recognize NoCloud datasource on boot cause it does not have /sbin in $PATH and thus does not find blkid

2018-05-23 Thread Bug Watch Updater

** Changed in: cloud-init (openSUSE)
   Status: Confirmed => 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/1771382

Title:
  ds-identify: fails to recognize NoCloud datasource on boot cause it
  does not have /sbin in $PATH and thus does not find blkid

Status in cloud-init:
  Fix Committed
Status in cloud-init package in openSUSE:
  Fix Released

Bug description:
  cloud-init 18.2 from
  http://download.opensuse.org/repositories/Cloud:/Tools/SLE_12_SP3/ on
  SLES 12 SP 3 with NoCloud data source via Cloud Init drive made by
  Proxmox.

  On SLES 12 SP3 NoCloud data source was not working, despite

  slestemplate:~ # blkid -c /dev/null -o export
  […]
  DEVNAME=/dev/sr0
  UUID=2018-05-15-16-34-27-00
  LABEL=cidata
  TYPE=iso9660
  […]

  with necessary files on it. blkid gives 0 as returncode

  Why?

  I only kept parts of the output:

  slestemplate:/etc/cloud # cat /run/cloud-init/ds-identify.log 
  [up 8.63s] ds-identify 
  policy loaded: mode=search report=false found=all maybe=all notfound=disabled
  no datasource_list found, using default: MAAS ConfigDrive NoCloud AltCloud 
Azure Bigstep CloudSigma CloudStack DigitalOcean AliYun Ec2 GCE OpenNebula 
OpenStack OVF SmartOS Scaleway Hetzner IBMCloud
  ERROR: failed running [127]: blkid -c /dev/null -o export
  […]
  FS_LABELS=unavailable:error
  ISO9660_DEVS=unavailable:error

  It might have been that I did not yet add the CloudInit drive in
  Proxmox yet.

  A subsequent call to

  slestemplate:~ # /usr/lib/cloud-init/ds-identify

  did not yet yield a different result.

  Only by analysing the source I found that it caches results and I can
  use the `--force` option to override this. I did this and the NoCloud
  datasource got detected properly. Apparently this is cached now.

  The tool would only inform of the caching as a DEBUG message. However
  I set logging to INFO for all parts of Cloud Init as the FileHandler
  clutters the log with tons of messages how many bytes it read from
  each file. Sure, I could use INFO only for FileHandler.

  Several issues reduce the ease of administration here:

  1. Don´t cache errors. Really… just… don´t.

  2. Don´t cache errors almost *silently* (just as a debug message).

  3. Decide wisely what is a debug message and what is not.

  4. A search for `ds-identify` in the documentation available at
  https://cloudinit.readthedocs.io/en/latest/ did not yield any result.

  5. And in general: Keep it short and simple.

  IMHO the first is the most important: Don´t cache errors. If the
  resource now is there, recognize it, without further discussion.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1771382/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1771382] Re: ds-identify: fails to recognize NoCloud datasource on boot cause it does not have /sbin in $PATH and thus does not find blkid

2018-05-22 Thread Bug Watch Updater

** Changed in: cloud-init (openSUSE)
   Status: Fix Released => Confirmed

-- 
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/1771382

Title:
  ds-identify: fails to recognize NoCloud datasource on boot cause it
  does not have /sbin in $PATH and thus does not find blkid

Status in cloud-init:
  Fix Committed
Status in cloud-init package in openSUSE:
  Confirmed

Bug description:
  cloud-init 18.2 from
  http://download.opensuse.org/repositories/Cloud:/Tools/SLE_12_SP3/ on
  SLES 12 SP 3 with NoCloud data source via Cloud Init drive made by
  Proxmox.

  On SLES 12 SP3 NoCloud data source was not working, despite

  slestemplate:~ # blkid -c /dev/null -o export
  […]
  DEVNAME=/dev/sr0
  UUID=2018-05-15-16-34-27-00
  LABEL=cidata
  TYPE=iso9660
  […]

  with necessary files on it. blkid gives 0 as returncode

  Why?

  I only kept parts of the output:

  slestemplate:/etc/cloud # cat /run/cloud-init/ds-identify.log 
  [up 8.63s] ds-identify 
  policy loaded: mode=search report=false found=all maybe=all notfound=disabled
  no datasource_list found, using default: MAAS ConfigDrive NoCloud AltCloud 
Azure Bigstep CloudSigma CloudStack DigitalOcean AliYun Ec2 GCE OpenNebula 
OpenStack OVF SmartOS Scaleway Hetzner IBMCloud
  ERROR: failed running [127]: blkid -c /dev/null -o export
  […]
  FS_LABELS=unavailable:error
  ISO9660_DEVS=unavailable:error

  It might have been that I did not yet add the CloudInit drive in
  Proxmox yet.

  A subsequent call to

  slestemplate:~ # /usr/lib/cloud-init/ds-identify

  did not yet yield a different result.

  Only by analysing the source I found that it caches results and I can
  use the `--force` option to override this. I did this and the NoCloud
  datasource got detected properly. Apparently this is cached now.

  The tool would only inform of the caching as a DEBUG message. However
  I set logging to INFO for all parts of Cloud Init as the FileHandler
  clutters the log with tons of messages how many bytes it read from
  each file. Sure, I could use INFO only for FileHandler.

  Several issues reduce the ease of administration here:

  1. Don´t cache errors. Really… just… don´t.

  2. Don´t cache errors almost *silently* (just as a debug message).

  3. Decide wisely what is a debug message and what is not.

  4. A search for `ds-identify` in the documentation available at
  https://cloudinit.readthedocs.io/en/latest/ did not yield any result.

  5. And in general: Keep it short and simple.

  IMHO the first is the most important: Don´t cache errors. If the
  resource now is there, recognize it, without further discussion.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1771382/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1771382] Re: ds-identify: fails to recognize NoCloud datasource on boot cause it does not have /sbin in $PATH and thus does not find blkid

2018-05-17 Thread Bug Watch Updater

** Changed in: cloud-init (openSUSE)
   Status: Confirmed => 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/1771382

Title:
  ds-identify: fails to recognize NoCloud datasource on boot cause it
  does not have /sbin in $PATH and thus does not find blkid

Status in cloud-init:
  New
Status in cloud-init package in openSUSE:
  Fix Released

Bug description:
  cloud-init 18.2 from
  http://download.opensuse.org/repositories/Cloud:/Tools/SLE_12_SP3/ on
  SLES 12 SP 3 with NoCloud data source via Cloud Init drive made by
  Proxmox.

  On SLES 12 SP3 NoCloud data source was not working, despite

  slestemplate:~ # blkid -c /dev/null -o export
  […]
  DEVNAME=/dev/sr0
  UUID=2018-05-15-16-34-27-00
  LABEL=cidata
  TYPE=iso9660
  […]

  with necessary files on it. blkid gives 0 as returncode

  Why?

  I only kept parts of the output:

  slestemplate:/etc/cloud # cat /run/cloud-init/ds-identify.log 
  [up 8.63s] ds-identify 
  policy loaded: mode=search report=false found=all maybe=all notfound=disabled
  no datasource_list found, using default: MAAS ConfigDrive NoCloud AltCloud 
Azure Bigstep CloudSigma CloudStack DigitalOcean AliYun Ec2 GCE OpenNebula 
OpenStack OVF SmartOS Scaleway Hetzner IBMCloud
  ERROR: failed running [127]: blkid -c /dev/null -o export
  […]
  FS_LABELS=unavailable:error
  ISO9660_DEVS=unavailable:error

  It might have been that I did not yet add the CloudInit drive in
  Proxmox yet.

  A subsequent call to

  slestemplate:~ # /usr/lib/cloud-init/ds-identify

  did not yet yield a different result.

  Only by analysing the source I found that it caches results and I can
  use the `--force` option to override this. I did this and the NoCloud
  datasource got detected properly. Apparently this is cached now.

  The tool would only inform of the caching as a DEBUG message. However
  I set logging to INFO for all parts of Cloud Init as the FileHandler
  clutters the log with tons of messages how many bytes it read from
  each file. Sure, I could use INFO only for FileHandler.

  Several issues reduce the ease of administration here:

  1. Don´t cache errors. Really… just… don´t.

  2. Don´t cache errors almost *silently* (just as a debug message).

  3. Decide wisely what is a debug message and what is not.

  4. A search for `ds-identify` in the documentation available at
  https://cloudinit.readthedocs.io/en/latest/ did not yield any result.

  5. And in general: Keep it short and simple.

  IMHO the first is the most important: Don´t cache errors. If the
  resource now is there, recognize it, without further discussion.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1771382/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1750780] Re: Race with local file systems can make open-vm-tools fail to start

2018-03-20 Thread Bug Watch Updater

** Changed in: open-vm-tools (Debian)
   Status: Incomplete => 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/1750780

Title:
  Race with local file systems can make open-vm-tools fail to start

Status in cloud-init:
  Invalid
Status in open-vm-tools package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in open-vm-tools source package in Xenial:
  Invalid
Status in systemd source package in Xenial:
  New
Status in open-vm-tools package in Debian:
  Fix Released

Bug description:
  Since the change in [1] open-vm-tools-service starts very (very) early.
  Not so much due to the 
  Before=cloud-init-local.service
  But much more by
  DefaultDependencies=no

  That can trigger an issue that looks like
  root@ubuntuguest:~# systemctl status -l open-vm-tools.service
  ● open-vm-tools.service - Service for virtual machines hosted on VMware
 Loaded: loaded (/lib/systemd/system/open-vm-tools.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: resources)

  
  As it is right now open-vm-tools can race with the other early start and then 
fail.
  In detail one can find a message like:
open-vm-tools.service: Failed to run 'start' task: Read-only file system"

  This is due to privtaeTmp=yes which is also set needing a writable
  /var/tmp [2]

  To ensure this works PrivateTmp would have to be removed (not good) or some 
after dependencies added that make this work reliably.
  I added
  After=local-fs.target
  which made it work for me in 3/3 tests.

  I' like to have an ack by the cloud-init Team that this does not totally kill 
the originally intended Before=cloud-init-local.service
  I think it does not as local-fs can complete before cloud-init-local, then 
open-vm-tools can initialize and finally cloud-init-local can pick up the data.

  To summarize:
  # cloud-init-local #
  DefaultDependencies=no
  Wants=network-pre.target
  After=systemd-remount-fs.service
  Before=NetworkManager.service
  Before=network-pre.target
  Before=shutdown.target
  Before=sysinit.target
  Conflicts=shutdown.target
  RequiresMountsFor=/var/lib/cloud

  # open-vm-tools #
  DefaultDependencies=no
  Before=cloud-init-local.service

  Proposed is to add to the latter:
  After=local-fs.target

  [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859677
  [2]: https://github.com/systemd/systemd/issues/5610

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1750780/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1700091] Re: Non-free repositories enabled

2017-08-01 Thread Bug Watch Updater

** Changed in: cloud-init (Debian)
   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/1700091

Title:
  Non-free repositories enabled

Status in cloud-init:
  New
Status in cloud-init package in Debian:
  Fix Released

Bug description:
  The non-free repositories are enabled both in Debian and Ubuntu
  template files located in the templates directory
  (sources.list.ubuntu.tmpl and sources.list.debian.tmpl). They should
  not be enabled, and thus be removed from the .tmpl files. This bug has
  been reported already in the Debian distribution:
  .

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1700091/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1700338] Re: cloud-init-local would fail on NFS if no networking

2017-07-22 Thread Bug Watch Updater

** Changed in: cloud-init (Debian)
   Status: Incomplete => 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/1700338

Title:
  cloud-init-local would fail on NFS if no networking

Status in cloud-init:
  New
Status in cloud-init package in Debian:
  Fix Released

Bug description:
  The cloud-init-local systemd service's executable is stored in
  /usr/bin. Also the service is currently run before networking has
  started. If a person wants to use NFS for /usr then it would mean that
  cloud-init-local service could not be run. See https://bugs.debian.org
  /cgi-bin/bugreport.cgi?bug=805866#40 for further information.

  I also think that it is weird that the Debian's sysvinit file has $remote_fs 
as start requirement (it's the opposite of systemd service file): 
  # Required-Start:$local_fs $remote_fs

  However the redhat sysvinit file doesn't have $remote_fs as
  requirement for start which makes this even more confusing.

  
  Files related to this bug:
  cloud-init/sysvinit/redhat/cloud-init-local
  cloud-init/sysvinit/debian/cloud-init-local
  cloud-init/systemd/cloud-init-local.service

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1700338/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1367899] Re: cloud-init rsyslog config uses deprecated syntax

2016-05-06 Thread Bug Watch Updater

** Changed in: cloud-init (Debian)
   Status: Fix Committed => 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/1367899

Title:
  cloud-init rsyslog config uses deprecated syntax

Status in cloud-init:
  New
Status in cloud-init package in Debian:
  Fix Released

Bug description:
  The rsyslog config snippet /etc/rsyslog.d/21-cloudinit.conf ends with the line
  & ~

  As of Trusty (well, after Precise) this syntax is deprecated in the shipped 
rsyslog, resulting in a warning message at rsyslog startup, and should be 
replaced with
  & stop

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1367899/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 1456335] Re: neutron-vpn-netns-wrapper missing in Ubuntu Package

2015-08-08 Thread Bug Watch Updater

** Changed in: neutron-vpnaas (Debian)
   Status: New = Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1456335

Title:
  neutron-vpn-netns-wrapper missing in Ubuntu Package

Status in neutron:
  Invalid
Status in neutron-vpnaas package in Ubuntu:
  Fix Released
Status in neutron-vpnaas source package in Vivid:
  New
Status in neutron-vpnaas package in Debian:
  Fix Released

Bug description:
  The executable neutron-vpn-netns-wrapper (path /usr/bin/neutron-vpn-
  netns-wrapper) in Ubuntu 14.04 packages is missing for OpenStack Kilo.

  I tried to enable VPNaaS with StrongSwan and it failed with this error 
message:
  2015-05-18 19:20:41.510 3254 TRACE 
neutron_vpnaas.services.vpn.device_drivers.ipsec Stderr: 
/usr/bin/neutron-rootwrap: Unauthorized command: ip netns exec 
qrouter-0b4c88fa-4944-45a7-b1b3-fbee1d7fc2ac neutron-vpn-netns-wrapper 
--mount_paths=/etc:/var/lib/neutron/ipsec/0b4c88fa-4944-45a7-b1b3-fbee1d7fc2ac/etc,/var/run:/var/lib/neutron/ipsec/0b4c88fa-4944-45a7-b1b3-fbee1d7fc2ac/var/run
 --cmd=ipsec,start (no filter matched)

  After copying the content of neutron-vpn-netns-wrapper from the Fedora
  repository VPNaaS with StrongSwan worked.

  The content of the vpn-netns-wrapper:

  #!/usr/bin/python2
  # PBR Generated from u'console_scripts'

  import sys

  from neutron_vpnaas.services.vpn.common.netns_wrapper import main

  
  if __name__ == __main__:
  sys.exit(main())

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1456335/+subscriptions

-- 
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help   : https://help.launchpad.net/ListHelp

[Yahoo-eng-team] [Bug 2057763] Re: Ubuntu 22.04 (v20240301) boot delay of ~2 minutes due to timeout in DataSourceMAAS

[Yahoo-eng-team] [Bug 2027975] Re: Add check on network interface name's length

[Yahoo-eng-team] [Bug 2020375] Re: Focal loses network configuration due to failed netplan generate

[Yahoo-eng-team] [Bug 1745671] Re: ENI format - configuring metadata network-interfaces with iface defined twice but different family breaks all networking on cloud-init instance

[Yahoo-eng-team] [Bug 1717147] Re: cloud-init 0.7.9 fails for CentOS 7.4 in Cloudstack

[Yahoo-eng-team] [Bug 1693361] Re: cloud-init sometimes fails on dpkg lock due to concurrent apt-daily.service execution

[Yahoo-eng-team] [Bug 1800848] Re: does not recognize cloned KVM VM as new instance

[Yahoo-eng-team] [Bug 1771382] Re: ds-identify: fails to recognize NoCloud datasource on boot cause it does not have /sbin in $PATH and thus does not find blkid

[Yahoo-eng-team] [Bug 1771382] Re: ds-identify: fails to recognize NoCloud datasource on boot cause it does not have /sbin in $PATH and thus does not find blkid

[Yahoo-eng-team] [Bug 1771382] Re: ds-identify: fails to recognize NoCloud datasource on boot cause it does not have /sbin in $PATH and thus does not find blkid

[Yahoo-eng-team] [Bug 1750780] Re: Race with local file systems can make open-vm-tools fail to start

[Yahoo-eng-team] [Bug 1700091] Re: Non-free repositories enabled

[Yahoo-eng-team] [Bug 1700338] Re: cloud-init-local would fail on NFS if no networking

[Yahoo-eng-team] [Bug 1367899] Re: cloud-init rsyslog config uses deprecated syntax

[Yahoo-eng-team] [Bug 1456335] Re: neutron-vpn-netns-wrapper missing in Ubuntu Package

15 matches

Site Navigation

Mail list logo

Footer information