[Yahoo-eng-team] [Bug 1720426] Re: network-config should allow dhcp client option values

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3015

** Bug watch added: github.com/canonical/cloud-init/issues #3015
   https://github.com/canonical/cloud-init/issues/3015

** Changed in: cloud-init
   Status: Triaged => Expired

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

Title:
  network-config should allow dhcp client option values

Status in cloud-init:
  Expired

Bug description:
  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
mac_address: 00:11:22:33:44:55
subnets:
  - type: dhcp
hostname: myhostname
client:  client_id_1
lease: 3600

  Would render in eni:

  auto iface eth0 dhcp
hostname myhostname
client: client_id_1
lease 3600

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1720426/+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 1720841] Re: Output from boothook is not logged

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3016

** Bug watch added: github.com/canonical/cloud-init/issues #3016
   https://github.com/canonical/cloud-init/issues/3016

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  Output from boothook is not logged

Status in cloud-init:
  Expired

Bug description:
  On Ubuntu 16.04 LTS I can find evidence that my boothook ran, but I
  don't see any of the log output I'd expect to see. bootcmd seems to
  work as expected.

  Repro user-data from smoser: http://paste.ubuntu.com/25661692/
  Repro result: http://paste.ubuntu.com/25661714/

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1720841/+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 1721573] Re: ntp unit tests broken if no package program available in test environment

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/3021

** Bug watch added: github.com/canonical/cloud-init/issues #3021
   https://github.com/canonical/cloud-init/issues/3021

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  ntp unit tests broken if no package program available in test
  environment

Status in cloud-init:
  Expired

Bug description:
  apply this diff to show the error, just make 'ntp_installable' not
  find a package installer.  At minimum, we just need to mock that out.

  $ git diff
  diff --git a/cloudinit/config/cc_ntp.py b/cloudinit/config/cc_ntp.py
  index 15ae1ecd..5ebdd461 100644
  --- a/cloudinit/config/cc_ntp.py
  +++ b/cloudinit/config/cc_ntp.py
  @@ -147,6 +147,7 @@ def ntp_installable():
   if util.system_is_snappy():
   return False
   
  +return False
   if any(map(util.which, ['apt-get', 'dnf', 'yum', 'zypper'])):
   return True
   
  $ tox-venv py3 python3 -m nose 
tests/unittests/test_handler/test_handler_ntp.py:TestNtp
  ...EE
  ==
  ERROR: Test ntp handler renders the shipped distro ntp.conf templates.
  --
  Traceback (most recent call last):
File 
"/home/smoser-public/src/cloud-init/cloud-init/tests/unittests/test_handler/test_handler_ntp.py",
 line 272, in test_ntp_handler_real_distro_templates
  cc_ntp.handle('notimportant', cfg, mycloud, None, None)
File 
"/home/smoser-public/src/cloud-init/cloud-init/cloudinit/config/cc_ntp.py", 
line 128, in handle
  write_ntp_config_template(ntp_cfg, cloud, confpath, 
template=template_name)
File 
"/home/smoser-public/src/cloud-init/cloud-init/cloudinit/config/cc_ntp.py", 
line 204, in write_ntp_config_template
  "not rendering %s"), path)
  RuntimeError: ('No template found, not rendering %s', 
'/etc/systemd/timesyncd.conf.d/cloud-init.conf')

  ==
  ERROR: Ntp schema validation allows for an empty ntp: configuration.
  --
  Traceback (most recent call last):
File 
"/home/smoser-public/src/cloud-init/cloud-init/tests/unittests/test_handler/test_handler_ntp.py",
 line 305, in test_ntp_handler_schema_validation_allows_empty_ntp_config
  with open(ntp_conf) as stream:
  FileNotFoundError: [Errno 2] No such file or directory: 
'/tmp/ci-TestNtp.nmgu_ja4/ntp.conf'

  ==
  ERROR: Ntp schema validation warns of invalid keys present in ntp config.
  --
  Traceback (most recent call last):
File 
"/home/smoser-public/src/cloud-init/cloud-init/tests/unittests/test_handler/test_handler_ntp.py",
 line 374, in test_ntp_handler_schema_validation_warns_invalid_key_present
  with open(ntp_conf) as stream:
  FileNotFoundError: [Errno 2] No such file or directory: 
'/tmp/ci-TestNtp.zj7sj7n8/ntp.conf'

  ==
  ERROR: Ntp schema validation warns of non-strings in pools or servers.
  --
  Traceback (most recent call last):
File 
"/home/smoser-public/src/cloud-init/cloud-init/tests/unittests/test_handler/test_handler_ntp.py",
 line 331, in test_ntp_handler_schema_validation_warns_non_string_item_type
  with open(ntp_conf) as stream:
  FileNotFoundError: [Errno 2] No such file or directory: 
'/tmp/ci-TestNtp.agut528j/ntp.conf'

  ==
  ERROR: Ntp schema validation warns of duplicates in servers or pools.
  --
  Traceback (most recent call last):
File 
"/home/smoser-public/src/cloud-init/cloud-init/tests/unittests/test_handler/test_handler_ntp.py",
 line 400, in test_ntp_handler_schema_validation_warns_of_duplicates
  with open(ntp_conf) as stream:
  FileNotFoundError: [Errno 2] No such file or directory: 
'/tmp/ci-TestNtp.ykjfhbx7/ntp.conf'

  ==
  ERROR: Ntp schema validation warns of non-array pools or servers types.
  --
  Traceback (most recent call last):
File 
"/home/smoser-public/src/cloud-init/cloud-init/tests/unittests/test_handler/test_handler_ntp.py",
 line 352, in test_ntp_handler_schema_validation_warns_of_non_array_type
  with open(ntp_conf) as stream:
  FileNotFoundError: [Errno 2] No such file or directory: 
'/tmp/ci-T

[Yahoo-eng-team] [Bug 1716773] Re: cloud-init doesn't cache network_config property in cache

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2997

** Bug watch added: github.com/canonical/cloud-init/issues #2997
   https://github.com/canonical/cloud-init/issues/2997

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  cloud-init doesn't cache network_config property in cache

Status in cloud-init:
  Expired

Bug description:
  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 the 'network_config' attribute is
  populated and set in init-local mode, but when we run init-net; it
  will re-run due to the underlying object value still be set to None
  (the default) as we failed to cache the object after modifying it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1716773/+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 1717470] Re: cloud-init should include iproute2 output (with MTU) in output

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2999

** Bug watch added: github.com/canonical/cloud-init/issues #2999
   https://github.com/canonical/cloud-init/issues/2999

** Changed in: cloud-init
   Status: Triaged => Expired

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

Title:
  cloud-init should include iproute2 output (with MTU) in output

Status in cloud-init:
  Expired

Bug description:
  cloud-init should show output of $ ip address which includes mtu in
  the console.log

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1717470/+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 1714495] Re: Archlinux Netctl Bringup

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2991

** Bug watch added: github.com/canonical/cloud-init/issues #2991
   https://github.com/canonical/cloud-init/issues/2991

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  Archlinux Netctl Bringup

Status in cloud-init:
  Expired

Bug description:
  I have been banging my head a bit with this one, especially as I am
  sure it *used* to work although in theory it should never have done! I
  would imagine a systemd update would have broken things.

  I can't get cloud-init to configure the network when using `distro:
  arch`. What seems to happen is this:

    - systemd looks at current units/services to start and begins boot.
    - cloud-init-local.service runs, mode in cmd/main.py is 'local'.
    - init.apply_network_config happens with bringup=False.
    - arch.py writes out a netctl config and enables it using netctl reenable 
enp0s3.
    - netctl creates a new systemd unit (netctl@enp0s3) and enables it
    - systemd list of services already resolved, so does not start 
netctl@enp0s3 as it was created after the boot process started

  So after the system is fully brought up, the interface is configured
  but NOT started. A subsequent reboot makes the network become
  available.

  A few things and thoughts:

    - I tried making bringup=True by force but cloud-init-local is too early in 
the boot process and netctl barfs when trying to do a restart on an interface 
here.
    - Debian and RHEL based seem to have their own ways of managing network 
that involve putting files in a certain place that an *already existing* 
service then comes along and processes later.
    - Tried from "master" and from 0.7.9.tar.gz

  I can't think of a way netctl could ever work with cloud-init.
  Possibly using systemd-networkd instead would be wise but then things
  like Vagrant and no doubt other "cloud" providers expect Arch to be
  using netctl.

  Thoughts? Ideas? Even a .patch so I can bodge something to work would
  be a big help right now but everything I have tried fails for one
  reason or another.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1714495/+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 1706973] Re: sysconfig mtu settings do not work correctly

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2962

** Bug watch added: github.com/canonical/cloud-init/issues #2962
   https://github.com/canonical/cloud-init/issues/2962

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  sysconfig mtu settings do not work correctly

Status in cloud-init:
  Expired
Status in curtin:
  Confirmed

Bug description:
  Curtin's tests that derive from CentosTestNetworkMtuAbs
  (Centos66TestNetworkMtu and Centos70TestNetworkMtu) are currently not
  working.

  That can be reproduced in curtin's vmtest with:
    ./tools/jenkins-runner -p4 tests/vmtests/test_metwork_mtu

  or more directly
    ./tools/jenkins-runner \
   tests/vmtests/test_network_mtu.py:Centos66TestNetworkMtu \
   tests/vmtests/test_network_mtu.py:Centos70TestNetworkMtu

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1706973/+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 1708255] Re: Invalid network config dictionaries are not handled well

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2969

** Bug watch added: github.com/canonical/cloud-init/issues #2969
   https://github.com/canonical/cloud-init/issues/2969

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  Invalid network config dictionaries are not handled well

Status in cloud-init:
  Expired

Bug description:
  Empty or invalid network configurations are not handled gracefully:

  network:
version: 1
config: []

  
  network:
foo: 27
wark: True

  These result in errors during rendering like this:

  File "/home/rharper/work/git/cloud-init/cloudinit/net/sysconfig.py", line 
570, in render_network_state
  network_state).items():
File "/home/rharper/work/git/cloud-init/cloudinit/net/sysconfig.py", line 
541, in _render_sysconfig
  for iface in network_state.iter_interfaces():
  AttributeError: 'NoneType' object has no attribute 'iter_interfaces'

  r.render_network_state(network_state=ns, target=args.directory)
File "/home/rharper/work/git/cloud-init/cloudinit/net/netplan.py", line 
218, in render_network_state
  content = self._render_content(network_state)
File "/home/rharper/work/git/cloud-init/cloudinit/net/netplan.py", line 
257, in _render_content
  interfaces = network_state._network_state.get('interfaces', [])
  AttributeError: 'NoneType' object has no attribute '_network_state'

  
  It appears that cloudinit.net.network_state.parse_* and the 
NetworkStateInterpretor does not do enough validation.

  In general we should decide how to handle these two types of
  configurations (empty and invalid) and allow cloud-init to fail
  gracefully, for example, cloud-init could use fallback_network config
  in the case of an invalid supplied network configuration.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1708255/+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 1704402] Re: dns-sortlist not recognized in network-config

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2953

** Bug watch added: github.com/canonical/cloud-init/issues #2953
   https://github.com/canonical/cloud-init/issues/2953

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  dns-sortlist not recognized in network-config

Status in cloud-init:
  Expired

Bug description:
  I'm using LXD with Ubuntu images, and cloud-init to do initial setup
  of container.  I'm not sure, but I believe the issue is in cloud-init,
  but would appreciate a pointer to the right location if not.
  Currently using network-config meta data, cloud-init takes the
  following config and converts correctly:

  version: 1
  config:
   - type: physical
 name: eth0
   - type: nameserver
 address: ['xx.xx.xx.xx']
 search: ['example.local', 'example.org']

  However including the following line is not recognized:

 sortlist: ['xx.xx.xx.xx', 'xx.xx.xx.xx']

  Please add support for this standard nameserver option.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1704402/+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 1705346] Re: Cloud-Init fails to deal with SWAP and Ephemeral if virtio-scsi is enabled

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2957

** Bug watch added: github.com/canonical/cloud-init/issues #2957
   https://github.com/canonical/cloud-init/issues/2957

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  Cloud-Init fails to deal with SWAP and Ephemeral if virtio-scsi is
  enabled

Status in cloud-init:
  Expired

Bug description:
  Hello!

   In my OpenStack environment, everything works great! Including Cloud-
  Init.

   However, I can not use virtio-blk anymore (i.e., /dev/vdX devices),
  because it is too slow.

   I changed to virtio-scsi (i.e., /dev/sdX devices) and the IOPS is
  more than double!

   But, after this change in Glance images, Cloud-Init is failing to
  make the SWAP and to mount the Ephemeral volumes.

  
   * Here is a normal log (with virtio-blk):

   http://paste.ubuntu.com/25127354/

  
   So, after changing my Ubuntu image properties on Glance, like this:

   glance image-update --property hw_scsi_model=virtio-scsi --property
  hw_disk_bus=scsi $UBUNTU_IMAGE_ID

  
   Cloud Init is now failing to make the SWAP, also Ephemeral is not mounted!

  
   * Here is the error log (with virtio-scsi):

   http://paste.ubuntu.com/25127989/

  
   Image used in Glance:

   http://uec-
  images.ubuntu.com/releases/16.04/release/ubuntu-16.04-server-cloudimg-
  amd64-disk1.img

  
   If I bring back virtio-blk, cloud-init works again (same Image, same Flavor).

   But, I can't use virtio-blk because it is very slow in my system! The
  virtio-scsi rocks!

  
  Cheers!
  Thiago

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1705346/+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 1701419] Re: cloud-init sets the default username to centos on rhel

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2939

** Bug watch added: github.com/canonical/cloud-init/issues #2939
   https://github.com/canonical/cloud-init/issues/2939

** Changed in: cloud-init
   Status: In Progress => Expired

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

Title:
  cloud-init sets the default username to centos on rhel

Status in cloud-init:
  Expired

Bug description:
  When using the cloud-init-curtin rpm the default user name is set to
  centos when used with RHEL7. The cloud-init package post install
  should determine if its running on centos or rhel and set the default
  user name appropriately in /etc/cloud/cloud.cfg

  
  Using cloud-init-0.7.9+191.g0bcb95a-1.el7.centos.noarch from 
http://copr-be.cloud.fedoraproject.org/results/@cloud-init/cloud-init-curtin/epel-7-x86_64

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1701419/+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 1702256] Re: [Hyper-V][Azure]cloudinit fail to get_source on Azure

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2943

** Bug watch added: github.com/canonical/cloud-init/issues #2943
   https://github.com/canonical/cloud-init/issues/2943

** Changed in: cloud-init
   Status: In Progress => Expired

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

Title:
  [Hyper-V][Azure]cloudinit fail to get_source on Azure

Status in cloud-init:
  Expired

Bug description:
  cloud-init on Azure cannot work properly:

  This is in fact a regression, caused by commit:
  ebc9ecbc8a76bdf511a456fb72339a7eb4c20568

  The issue happens in the following code:
  cloudinit/source/DataSourceAzure.py.

  The removal of "sources.DEP_NETWORK" makes sources.list_sources()
  return [] for DataSourceAzure, which is the root cause.

  +
   # Used to match classes to dependencies
   datasources = [
  -(DataSourceAzureNet, (sources.DEP_FILESYSTEM, sources.DEP_NETWORK)),
  +(DataSourceAzure, (sources.DEP_FILESYSTEM, )),
   ]

  The error log:
  2017-07-04 08:28:49,555 - __init__.py[DEBUG]: Searching for network data 
source in: []
  2017-07-04 08:28:49,555 - util.py[WARNING]: No instance datasource found! 
Likely bad things to come!
  2017-07-04 08:28:49,555 - util.py[DEBUG]: No instance datasource found! 
Likely bad things to come!
  Traceback (most recent call last):
File 
"/usr/local/lib/python2.7/site-packages/cloud_init-0.7.9-py2.7.egg/cloudinit/cmd/main.py",
 line 331, in main_init
  init.fetch(existing=existing)
File 
"/usr/local/lib/python2.7/site-packages/cloud_init-0.7.9-py2.7.egg/cloudinit/stages.py",
 line 349, in fetch
  return self._get_data_source(existing=existing)
File 
"/usr/local/lib/python2.7/site-packages/cloud_init-0.7.9-py2.7.egg/cloudinit/stages.py",
 line 259, in _get_data_source
  pkg_list, self.reporter)
File 
"/usr/local/lib/python2.7/site-packages/cloud_init-0.7.9-py2.7.egg/cloudinit/sources/__init__.py",
 line 334, in find_source
  raise DataSourceNotFoundException(msg)
  DataSourceNotFoundException: Did not find any data source, searched classes: 
()

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1702256/+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 1702721] Re: read_dmi_data warning confusing when key not found and no dmidecode

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2947

** Bug watch added: github.com/canonical/cloud-init/issues #2947
   https://github.com/canonical/cloud-init/issues/2947

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  read_dmi_data warning confusing when key not found and no dmidecode

Status in cloud-init:
  Expired

Bug description:
  On systems without dmidecode and where the dmi key is not present,
  cloud-init will print this warning:

  LOG.warning("did not find either path %s or dmidecode command",
  DMI_SYS_PATH)

  Which looks strange since the system does have /sys/class/dmi/id but
  just did not find the requested key.

  This is due to _read_dmi_syspath returning None and which('dmidecode')
  returning None.

  Ideally we'd indicate that we couldn't read the specified key
  separately from the case where the system doesn't have
  /sys/class/dmi/id.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1702721/+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 2018989] Re: [SRBAC] FIP Port Forwarding policies should be available for PARENT_OWNER with proper role

[OpenStack Infra]

Reviewed:  https://review.opendev.org/c/openstack/neutron/+/882691
Committed: 
https://opendev.org/openstack/neutron/commit/4edff4fe8dff102f13e3da0a000c03538755337d
Submitter: "Zuul (22348)"
Branch:master

commit 4edff4fe8dff102f13e3da0a000c03538755337d
Author: Slawek Kaplonski 
Date:   Tue May 9 12:54:28 2023 +0200

[S-RBAC] Fix new policies for FIP PFs APIs

During transition to the new secure RBAC API policies, we made mistake
with policies for FIP PFs by defining them to be available for
ADMIN_OR_PROJECT_MEMBER/READER or FIP owner.
First, rule PROJECT_MEMBER/READER is not appropriate in this case as FIP PFs
don't have tenant_id attribute at all and belongs to the owner of FIP 
always.
Second issue was that any FIP owner, even with just READER role could 
possibly
e.g. create port forwarding.

To fix that, this patch changes those API policies to new rules:
ADMIN_OR_PARENT_OWNER_READER
ADMIN_OR_PARENT_OWNER_MEMBER

Closes-Bug: #2018989
Change-Id: Ibff4c4f5b6d020fd598831a8a6e8ec0e2f559005


** Changed in: neutron
   Status: In Progress => 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/2018989

Title:
  [SRBAC] FIP Port Forwarding policies should be available for
  PARENT_OWNER with proper role

Status in neutron:
  Fix Released

Bug description:
  Currently new S-RBAC policies for FIP port forwardings are defined as

  policy_or(ADMIN_OR_PROJECT_MEMBER, RULE_PARENT_OWNER)

  this isn't correct as FIP PF resource don't have project_id attribute
  and always belongs to the owner of the FIP. It's very similar issue to
  what we have with QoS rules and what was reported in
  https://bugs.launchpad.net/neutron/+bug/2018727

  To fix that we need to use policies like ADMIN_OR_PARENT_OWNER_MEMBER
  to let e.g. creation of FIP PF to the owner of FIP with correct role
  assigned.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2018989/+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 1697235] Re: Getting none possible datasources warning on non-intel arches

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2926

** Bug watch added: github.com/canonical/cloud-init/issues #2926
   https://github.com/canonical/cloud-init/issues/2926

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  Getting none possible datasources warning on non-intel arches

Status in cloud-init:
  Expired

Bug description:
  I'm using Ubuntu images from here https://cloud-images.ubuntu.com in
  an OpenStack Liberty running on a ppc64le host and getting the
  following warning:

  **
  # A new feature in cloud-init identified possible datasources for#
  # this system as:#
  #   ['None'] #
  # However, the datasource used was: OpenStack#
  ##
  # In the future, cloud-init will only attempt to use datasources that#
  # are identified or specifically configured. #
  # For more information see   #
  #   https://bugs.launchpad.net/bugs/1669675  #
  ##
  # If you are seeing this message, please file a bug against  #
  # cloud-init at  #
  #https://bugs.launchpad.net/cloud-init/+filebug?field.tags=dsid  #
  # Make sure to include the cloud provider your instance is   #
  # running on.#
  ##
  # After you have filed a bug, you can disable this warning by launching  #
  # your instance with the cloud-config below, or putting that content #
  # into /etc/cloud/cloud.cfg.d/99-warnings.cfg#
  ##
  # #cloud-config  #
  # warnings:  #
  #   dsid_missing_source: off #
  **

  The debug info from Ubuntu 17.04 is attached, however it happens from
  16.04 to 17.10

  $ dpkg-query -W -f='${Version}' cloud-init
  0.7.9-113-g513e99e0-0ubuntu1~17.04.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1697235/+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 1695277] Re: cc_mounts should ensure_dir on lower, upper and workdir params

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2916

** Bug watch added: github.com/canonical/cloud-init/issues #2916
   https://github.com/canonical/cloud-init/issues/2916

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  cc_mounts should ensure_dir on lower, upper and workdir params

Status in cloud-init:
  Expired

Bug description:
  Ubuntu Trusty 14.04 machine that mounts an overlayfs at
  /var/spool/postfix, and this works great:

  fs_setup:
- label: postfix
  device: /dev/xvde
  filesystem: ext4
  mounts:
  - [ /dev/xvde, /mnt/postfix-overlay ]
  - [ overlayfs, /var/spool/postfix, "overlayfs", 
"defaults,lowerdir=/var/spool/postfix,upperdir=/mnt/postfix-overlay", "0", "2" ]
  mount_default_fields: [ None, None, "auto", "defaults,nobootwait", "0", "2” ]

  Upgrading the system image to Xenial 16.04 causes the overlayfs to
  fail to mount with the error “missing ‘workdir’”.

  Turns out, between Trusty and Xenial, the “workdir” directory in
  overlayfs went from optional to mandatory, and now the system no
  longer deploys.

  What needs to happen is that after the fs_setup step that creates
  /mnt/postfix-overlay, but before the mounts section where the
  overlayfs is created, the workdir and upperdir directories need to be
  created on the /mnt/postfix-overlay disk as /mnt/postfix-
  overlay/upperdir and /mnt/postfix-overlay/workdir (or something)
  respectively.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1695277/+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 1697635] Re: [Hyper-V][Azure]ssh session will timeout for a short while for FreeBSD on Azure

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2927

** Bug watch added: github.com/canonical/cloud-init/issues #2927
   https://github.com/canonical/cloud-init/issues/2927

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  [Hyper-V][Azure]ssh session will timeout for a short while for FreeBSD
  on Azure

Status in cloud-init:
  Expired

Bug description:
  If we install cloud-init on a FreeBSD VHD which does not install
  waagent previously, and upload this VHD to Azure. It works fine for
  SSH connection. But after a short while (~5 seconds), the SSH session
  is broken.

  The reason is cloud-init does not set "ClientAliveInterval" in
  /etc/ssh/sshd_config.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1697635/+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 1693265] Re: network_data.json should provide interface-scoped nameserver information

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2906

** Bug watch added: github.com/canonical/cloud-init/issues #2906
   https://github.com/canonical/cloud-init/issues/2906

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  network_data.json should provide interface-scoped nameserver
  information

Status in cloud-init:
  Expired
Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Nova currently provides nameserver information in network_data.json as
  a globally-scoped "services" key.  E.g., from
  https://specs.openstack.org/openstack/nova-
  specs/specs/liberty/implemented/metadata-service-network-
  info.html#rest-api-impact:

{
"links": [...],
"networks": [...],
"services": [
{
"type": "dns",
"address": "8.8.8.8"
},
{
"type": "dns",
"address": "8.8.4.4"
}
  ]
}

  This is problematic because nameserver information is actually
  provided to OpenStack *per-subnet*, and nameservers that are reachable
  via one subnet may not be reachable from others.  This is true outside
  of OpenStack as well, and is generally handled by providing nameserver
  information in interface configuration files (such as
  /etc/sysconfig/network-scripts/ifcfg-eth0 on RHEL and derivatives).

  Unfortunately, because Nova does not provide interface-scoped
  nameserver information, it is not possible to correctly configure a
  server from this information.  Depending on how /etc/resolv.conf is
  populated, this can result in name resolution delays or failures if
  some system interfaces are brought down.

  While it may be too late to remove the global nameserver information,
  we should *also* provide interface-scoped nameserver information in
  the "networks" dictionary, something like:

"networks": [
  {
"network_id": "100dc63c-e8f8-46d1-a99f-6da4aca171b1",
"type": "ipv4",
"netmask": "255.255.255.0",
"link": "tap14c7fd7d-81",
"routes": [
  {
"netmask": "0.0.0.0",
"network": "0.0.0.0",
"gateway": "10.9.8.1"
  }
],
"ip_address": "10.9.8.2",
"id": "network1",
"services": [
  {
"type": "dns",
"address": "10.9.8.1"
  }
]
  }
]

  This would allow system configuration tools to correctly configure
  interface-scoped nameserver information.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1693265/+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 1693524] Re: identify openstack kvm platform on s390

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2909

** Bug watch added: github.com/canonical/cloud-init/issues #2909
   https://github.com/canonical/cloud-init/issues/2909

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
   identify openstack kvm platform on s390

Status in cloud-init:
  Expired
Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  On i386 and amd64, openstack puts 'OpenStack Nova', into the dmi platform
  information. OpenStack using kvm on s390, does not identify itself to the 
guest in any way.

  The result is that cloud-init cannot identify it is running on
  openstack.

  We need two things
   a.) change openstack to provide that information through libvirt on s390
   in some way.
   b.) possibly changes in qemu to pass information through that the guest
   can see. Some options here might include putting information in
   the device tree or possibly on the attached disk (model of the disk 
could be 'OpenStack disk ').

  Related bugs:
    https://bugs.launchpad.net/cloud-init/+bugs?field.tag=dsid-nova

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1693524/+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 2018727] Re: [SRBAC] API policies for get_policy_*_rule are wrong

[OpenStack Infra]

Reviewed:  https://review.opendev.org/c/openstack/neutron/+/882688
Committed: 
https://opendev.org/openstack/neutron/commit/be0dc09d52efd5e7236a33be552edb6644371cd0
Submitter: "Zuul (22348)"
Branch:master

commit be0dc09d52efd5e7236a33be552edb6644371cd0
Author: Slawek Kaplonski 
Date:   Tue May 9 12:28:03 2023 +0200

[S-RBAC] Fix new policies for get QoS rules APIs

During transition to the new secure RBAC API policies, we made mistake
with policies for QoS rules by defining them to be available for
ADMIN_OR_PROJECT_READER. This can't be like that as QoS rules don't have
tenant_id attribute and belongs always to the owner of the QoS policy.

To fix that, this patch introduces new rules:
ADMIN_OR_PARENT_OWNER_READER
ADMIN_OR_PARENT_OWNER_MEMBER

and uses those in the QoS rules APIs.

Closes-Bug: #2018727
Change-Id: I522aeab5094b3f4854303d5e18f3abf6130fb33c


** Changed in: neutron
   Status: In Progress => 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/2018727

Title:
  [SRBAC] API policies for get_policy_*_rule are wrong

Status in neutron:
  Fix Released

Bug description:
  With new defaults policies for get QoS rules are set to
  ADMIN_OR_PROJECT_READER but that's wrong as rules don't have owner.
  Those API rules should be based on the parent owner (qos_policy)
  always.

  Those tests are skipped currently in our CI job neutron-tempest-
  plugin-openvswitch-enforce-scope-new-defaults due to other bug
  (https://bugs.launchpad.net/neutron/+bug/2018585).

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2018727/+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 1693020] Re: Cloud.get_template_filename should start with distro-specific template and fallback to generic template files before warning !found

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2904

** Bug watch added: github.com/canonical/cloud-init/issues #2904
   https://github.com/canonical/cloud-init/issues/2904

** Changed in: cloud-init
   Status: Triaged => Expired

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

Title:
  Cloud.get_template_filename should start with distro-specific template
  and fallback to generic template files before warning !found

Status in cloud-init:
  Expired

Bug description:
  We need get_template_filename to always start at a granular cloud
  distro-scope, if the distro-specific file doesn't exist, fallback to a
  generic scoped template name and ultimately warn on missing template
  if neither exist.

  This functionality could be used by ntp, hosts and sources template
  renderers.

  Also rename ntp.sles.tmpl -> ntp.suse.tmpl as part of this work.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1693020/+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 1687726] Re: sysconfig renderer does not process 'routes' from network_state

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2881

** Bug watch added: github.com/canonical/cloud-init/issues #2881
   https://github.com/canonical/cloud-init/issues/2881

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  sysconfig renderer does not process 'routes' from network_state

Status in cloud-init:
  Expired

Bug description:
  % cat network_static_routes.yaml 
  network:
  version: 1
  config:
- type: physical
  name: interface0
  mac_address: "52:54:00:12:34:00"
  subnets:
- address: 172.23.31.42/26
  gateway: 172.23.31.2
  type: static
- type: route
  id: 4
  metric: 0
  destination: 10.0.0.0/12
  gateway: 172.23.31.1
- type: route
  id: 5
  metric: 0
  destination: 192.168.0.0/16
  gateway: 172.23.31.1
- type: route
  id: 6
  metric: 1
  destination: 10.200.0.0/16
  gateway: 172.23.31.1

  % PYTHONPATH=`pwd` ./tools/net-convert.py --network-data
  network_static_routes.yaml --kind yaml --output-kind sysconfig -d
  target

  % find target -type f
  target/etc/resolv.conf
  target/etc/udev/rules.d/70-persistent-net.rules
  target/etc/sysconfig/network-scripts/ifcfg-interface0
  target/etc/sysconfig/network

  No route-$iface files were generated.

  1. no cloud, rendering from in-tree
  2. cloud-init master tip

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1687726/+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 1685939] Re: Speed up yaml parsing using libYAML C-bindings

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2869

** Bug watch added: github.com/canonical/cloud-init/issues #2869
   https://github.com/canonical/cloud-init/issues/2869

** Changed in: cloud-init
   Status: In Progress => Expired

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

Title:
  Speed up yaml parsing using libYAML C-bindings

Status in cloud-init:
  Expired

Bug description:
  We can speed up cloud init yaml loading and parsing by using the
  C-bindings instead of python bindings.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1685939/+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 1683038] Re: Need to convince cloud-init we really want Ec2 datasource

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2860

** Bug watch added: github.com/canonical/cloud-init/issues #2860
   https://github.com/canonical/cloud-init/issues/2860

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  Need to convince cloud-init we really want Ec2 datasource

Status in cloud-init:
  Expired
Status in diskimage-builder:
  Fix Released

Bug description:
  cloud-init was recently changed to be more selective about the types
  of data source it wants to access.  See
  https://bugs.launchpad.net/cloud-init/+bug/1660385.  In particular,
  when it is run on a non-EC2 cloud and sees EC2 metadata, it recently
  started to print annoying warnings to the user.

  When we add the "Ec2" datasource to images, we should also generate a
  workaround that suppresses the warning.  According to the warning
  itself, this can be achieved by adding a file
  /etc/cloud/cloud.cfg.d/99-ec2-datasource.cfg that says

#cloud-config
datasource:
 Ec2:
  strict_id: false

  An alternative would be to live with the warnings, and hope that DIB
  users select other datasources in preference of Ec2, for example
  OpenStack and/or ConfigDrive.

  Another option would be to convince the cloud-init developers that
  OpenStack clouds can be expected to provide the Ec2 metadata service,
  and that there's no need to issue warnings about that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1683038/+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 2004555] Re: [OSSA-2023-003] Unauthorized volume access through deleted volume attachments (CVE-2023-2088)

[OpenStack Infra]

Reviewed:  https://review.opendev.org/c/openstack/nova/+/882847
Committed: 
https://opendev.org/openstack/nova/commit/db455548a12beac1153ce04eca5e728d7b773901
Submitter: "Zuul (22348)"
Branch:master

commit db455548a12beac1153ce04eca5e728d7b773901
Author: melanie witt 
Date:   Wed Feb 15 22:37:40 2023 +

Use force=True for os-brick disconnect during delete

The 'force' parameter of os-brick's disconnect_volume() method allows
callers to ignore flushing errors and ensure that devices are being
removed from the host.

We should use force=True when we are going to delete an instance to
avoid leaving leftover devices connected to the compute host which
could then potentially be reused to map to volumes to an instance that
should not have access to those volumes.

We can use force=True even when disconnecting a volume that will not be
deleted on termination because os-brick will always attempt to flush
and disconnect gracefully before forcefully removing devices.

Closes-Bug: #2004555

Change-Id: I3629b84d3255a8fe9d8a7cea8c6131d7c40899e8


** Changed in: nova
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/2004555

Title:
  [OSSA-2023-003] Unauthorized volume access through deleted volume
  attachments (CVE-2023-2088)

Status in Cinder:
  In Progress
Status in glance_store:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) antelope series:
  In Progress
Status in OpenStack Compute (nova) wallaby series:
  In Progress
Status in OpenStack Compute (nova) xena series:
  Fix Committed
Status in OpenStack Compute (nova) yoga series:
  Fix Committed
Status in OpenStack Compute (nova) zed series:
  Fix Committed
Status in os-brick:
  In Progress
Status in OpenStack Security Advisory:
  Fix Released
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  Hello OpenStack Security Team,

  I’m writing to you, as we faced a serious security breach in OpenStack
  functionality(correlated a bit with libvirt, iscsi and huawei driver).
  I was going through OSSA documents and correlated libvirt notes, but I
  couldn't find something similar. It is not related to
  https://security.openstack.org/ossa/OSSA-2020-006.html

  In short: we observed that newly created cinder volume(1GB size) was
  attached to compute node instance, but an instance recognized it as a
  115GB volume, which(this 115GB volume) in fact was connected to
  another instance on the same compute node.

  [1. Test environment]
  Compute node: OpenStack Ussuri configured with Huawei dorado as a storage 
backend(configuration driver is available here: 
https://docs.openstack.org/cinder/rocky/configuration/block-storage/drivers/huawei-storage-driver.html)
  Packages:
  v# dpkg -l | grep libvirt
  ii  libvirt-clients   6.0.0-0ubuntu8.16   
 amd64Programs for the libvirt library
  ii  libvirt-daemon6.0.0-0ubuntu8.16   
 amd64Virtualization daemon
  ii  libvirt-daemon-driver-qemu6.0.0-0ubuntu8.16   
 amd64Virtualization daemon QEMU connection driver
  ii  libvirt-daemon-driver-storage-rbd 6.0.0-0ubuntu8.16   
 amd64Virtualization daemon RBD storage driver
  ii  libvirt-daemon-system 6.0.0-0ubuntu8.16   
 amd64Libvirt daemon configuration files
  ii  libvirt-daemon-system-systemd 6.0.0-0ubuntu8.16   
 amd64Libvirt daemon configuration files (systemd)
  ii  libvirt0:amd646.0.0-0ubuntu8.16   
 amd64library for interfacing with different 
virtualization systems
  ii  nova-compute-libvirt  2:21.2.4-0ubuntu1   
 all  OpenStack Compute - compute node libvirt support
  ii  python3-libvirt   6.1.0-1 
 amd64libvirt Python 3 bindings

  # dpkg -l | grep qemu
  ii  ipxe-qemu 
1.0.0+git-20190109.133f4c4-0ubuntu3.2all  PXE boot 
firmware - ROM images for qemu
  ii  ipxe-qemu-256k-compat-efi-roms1.0.0+git-20150424.a25a16d-0ubuntu4 
 all  PXE boot firmware - Compat EFI ROM images for qemu
  ii  libvirt-daemon-driver-qemu6.0.0-0ubuntu8.16   
 amd64Virtualization daemon QEMU connection driver
  ii  qemu  1:4.2-3ubuntu6.23   
 amd64fast processor emulator, dummy pack

[Yahoo-eng-team] [Bug 1679777] Re: Adding and reporting ssh keys fails for user in extrausers

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2851

** Bug watch added: github.com/canonical/cloud-init/issues #2851
   https://github.com/canonical/cloud-init/issues/2851

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  Adding and reporting ssh keys fails for user in extrausers

Status in cloud-init:
  Expired

Bug description:
  If a user is added with '--extrausers' (which happens on ubuntu core)
  then adding ssh keys or reporting which keys are added will fail as the users 
cannot be found.
  This seems a general issue as extrausers, see bug 1679765.

  
  The stack trace looks like:

  2017-04-04 16:57:00,117 - util.py[WARNING]: Applying ssh credentials failed!
  2017-04-04 16:57:00,117 - util.py[DEBUG]: Applying ssh credentials failed!
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_ssh.py", line 195, 
in handle
  apply_credentials(keys, user, disable_root, disable_root_opts)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_ssh.py", line 204, 
in apply_credentials
  ssh_util.setup_user_keys(keys, user)
File "/usr/lib/python3/dist-packages/cloudinit/ssh_util.py", line 241, in 
setup_user_keys
  (ssh_dir, pwent) = users_ssh_info(username)
File "/usr/lib/python3/dist-packages/cloudinit/ssh_util.py", line 205, in 
users_ssh_info
  pw_ent = pwd.getpwnam(username)
  KeyError: 'getpwnam(): name not found: ubuntu'

  and then

  2017-04-04 16:57:04,559 - util.py[WARNING]: Running module 
ssh-authkey-fingerprints ()
 failed
  2017-04-04 16:57:04,560 - util.py[DEBUG]: Running module 
ssh-authkey-fingerprints ()
 failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 787, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File 
"/usr/lib/python3/dist-packages/cloudinit/config/cc_ssh_authkey_fingerprints.py",
 line 108, in handle
  (key_fn, key_entries) = ssh_util.extract_authorized_keys(user_name)
File "/usr/lib/python3/dist-packages/cloudinit/ssh_util.py", line 212, in 
extract_authorized_keys
  (ssh_dir, pw_ent) = users_ssh_info(username)
File "/usr/lib/python3/dist-packages/cloudinit/ssh_util.py", line 205, in 
users_ssh_info
  pw_ent = pwd.getpwnam(username)
  KeyError: 'getpwnam(): name not found: ubuntu'

  Related bugs:
   * bug 1679765: cannot lock password for user created with useradd 
--extrausers

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1679777/+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 1680116] Re: ds-identify needs to support check_instance_id like function

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2853

** Bug watch added: github.com/canonical/cloud-init/issues #2853
   https://github.com/canonical/cloud-init/issues/2853

** Changed in: cloud-init
   Status: Triaged => Expired

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

Title:
  ds-identify needs to support check_instance_id like function

Status in cloud-init:
  Expired

Bug description:
  When ds-identify runs, it identifies the cloud platform based on available 
information.
  For some datasources provided as an attached disk, the cloud provider may 
remove that disk at some time (or potentially, the user might destroy it).  In 
such cases (Azure and ConfigDrive) the system id read from smbios is the same 
as the instance-id, so we can locally quickly check.

  cloud-init's datasource search code supports this via the 'check_instance_id' 
method in a datasource.
  Basically, that function is called from the old datasource.  If it retunrs 
true, then cloud-init would not go looking for an attached disk that it would 
not find.

  The ds-identify code does not support this at the moment.  The result is if 
you did:
   * boot system with configdrive
   * dd if=/dev/zero of=/dev/disk/by-name/config-2
   * reboot

  ds-identify would then not recognize this system as config drive even
  though the datasource would recognize it was.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1680116/+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 1681005] Re: install hooks fail because enable-os-upgrade/refresh-update ignored

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2854

** Bug watch added: github.com/canonical/cloud-init/issues #2854
   https://github.com/canonical/cloud-init/issues/2854

** Changed in: cloud-init
   Status: Incomplete => Expired

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

Title:
  install hooks fail because enable-os-upgrade/refresh-update ignored

Status in cloud-images:
  New
Status in cloud-init:
  Expired
Status in Canonical Juju:
  Invalid

Bug description:
  As seen at
 http://reports.vapour.ws/releases/issue/5553b279749a56508ba88b45

  There is a dramatic rise in hook failures since March 24. This is
  because juju is not running apt-get update or upgrade.

  Joyent dominates, but rackspace and GCE have had spots of failures.
  The unit logs show apt fails to find packages. Joyent tends to have
  stale images so Juju CI tests always run with os-enable-refresh-update
  to have the correct list of packages.

  Today I deployed the landscape bundle in joyent and repeated the
  postgresql install hook failures. The log confirm an apt issue

  E: Failed to fetch
  http://security.ubuntu.com/ubuntu/pool/main/l/linux/linux-libc-
  dev_4.4.0-71.92_amd64.deb  404  Not Found [IP: 91.189.88.149 80]

  juju model-config shows apt should have been updated and the host
  upgraded

  enable-os-refresh-updatedefault  true
  enable-os-upgrade   default  true

  But /var/log/apt/history.log and /var/log/apt/term.log show apt has
  not been touched since the image was made in March.

  I left the model untouched for 3 hours. It remained in error. I ran
  juju ssh 2 -- sudo apt-get update

  3 minutes later the unit was installed.

  This bug is in 2.1 and 2.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1681005/+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 1675571] Re: Cloud-init update renders secondary addresses to be incompatible with standard tools

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2842

** Bug watch added: github.com/canonical/cloud-init/issues #2842
   https://github.com/canonical/cloud-init/issues/2842

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  Cloud-init update renders secondary addresses to be incompatible with
  standard tools

Status in cloud-init:
  Expired
Status in curtin:
  Confirmed
Status in cloud-init package in Ubuntu:
  Confirmed
Status in resolvconf package in Ubuntu:
  New
Status in resolvconf package in Debian:
  Won't Fix

Bug description:
  The change of how cloud-init renders 
/etc/network/interface.d/50-cloud-init.cfg, standard tools no longer work as 
expected:
  * resolvconf will nullify nameservers
  * if* commands ignore secondary addresses

  [ORIGINAL REPORT]

  Regresion from Bug #1657940.

  When provisioning with multiple eth0 addresses, /etc/resolv.conf is
  empty:

  Consider:
  root@tester:~# cat /etc/network/interfaces.d/50-cloud-init.cfg
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet static
  address 138.197.98.102
  dns-nameservers 8.8.8.8 8.8.4.4
  gateway 138.197.96.1
  netmask 255.255.240.0

  # control-alias eth0
  iface eth0 inet static
  address 10.17.0.11
  netmask 255.255.0.0

  Which then yields an empty /etc/resolv.conf:
  root@tester:/run/resolvconf# cat interface/eth0.inet

  root@tester:/run/resolvconf# cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

  The problem is that resolvconfg does pattern matching for eth*.inet.
  The second definition of eth0 has no nameserver and therefore
  overrides the definition.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1675571/+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 1675021] Re: ssh_pwauth: false fails to disable challenge/response authentication

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2837

** Bug watch added: github.com/canonical/cloud-init/issues #2837
   https://github.com/canonical/cloud-init/issues/2837

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  ssh_pwauth: false fails to disable challenge/response authentication

Status in cloud-init:
  Expired

Bug description:
  cc_set_passwords.py interprets the ssh_pwauth boolean configuration
  option, and depending on its setting will either enable, disable, or
  not touch the PasswordAuthentication option in sshd_config.

  This neglects to also set ChallengeResponseAuthentication. It defaults
  to yes upstream, but many distributions, including Ubuntu, ship a
  default sshd_config that sets this to no. On a system with
  "ChallengeResponseAuthentication yes" however, "ssh_pwauth: false" has
  no real effect — and this poses a security problem for users of those
  systems, as they will most likely inadvertently leave password
  authentication enabled.

  How to best address this is tricky. Obviously, "ssh_pwauth: false"
  should disable both PasswordAuthentication and
  ChallengeResponseAuthentication. What "ssh_pwauth: true" should do is
  debatable.

  What complicates matters still is that one of the affected systems
  that ship with "ChallengeResponseAuthentication yes" is SLES,
  including the official JeOS OpenStack image, and SLES ships its own
  fork of cloud-init. So even if this does gets fixed in upstream cloud-
  init, someone still has to remind the SUSE folks to merge the patch
  (or update their default image).

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1675021/+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 1673853] Re: do not write ifcfg-lo when rendering syscfg

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2831

** Bug watch added: github.com/canonical/cloud-init/issues #2831
   https://github.com/canonical/cloud-init/issues/2831

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  do not write ifcfg-lo when rendering syscfg

Status in cloud-init:
  Expired

Bug description:
  As discussed some in merge proposal at [1].
  The sysconfig renderer could use some work.

  a.) seems like we should not be rendering ifcfg-lo at least in the case that 
it already exists.
  b.) we should be able to now replace _write_network with something that uses 
eni.convert_eni_data
  like http://paste.ubuntu.com/24196078/
  --
  [1] 
https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/319943

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1673853/+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 1667878] Re: fstab entries with x-systemd.requires=cloud-init.service mean cloud-init will always run.

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2815

** Bug watch added: github.com/canonical/cloud-init/issues #2815
   https://github.com/canonical/cloud-init/issues/2815

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  fstab entries with x-systemd.requires=cloud-init.service mean cloud-
  init will always run.

Status in cloud-init:
  Expired

Bug description:
  when cloud-init writes mount entries into /etc/fstab, it adds:
   x-systemd.requires=cloud-init.service

  This is because a subsequent boot of cloud-init may need to remove
  that entry (a new instance for example).

  cloud-init has a feature where it can be disabled by:
sudo touch /etc/cloud/cloud-init.disabled

  The generator for cloud-init then says that the cloud-init.target does
  not need to run.

  However, due to the (possibly stale) x-systemd.requires=cloud-
  init.service entries, cloud-init will still run.

  I think what I'd like is a:
x-systemd.after=cloud-init.service

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1667878/+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 1664384] Re: [2.1] Support configuring components and disabling deb-src

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2806

** Bug watch added: github.com/canonical/cloud-init/issues #2806
   https://github.com/canonical/cloud-init/issues/2806

** Changed in: cloud-init
   Status: Triaged => Expired

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

Title:
  [2.1] Support configuring components and disabling deb-src

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

Bug description:
  MAAS supports adding additional repositories but it does not support
  disabling components or sources:

  Components are [main, universe, multiverse, restricted]
  deb source packages = deb-src

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1664384/+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 1664712] Re: Add support for setting log level on webhook reporter

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2807

** Bug watch added: github.com/canonical/cloud-init/issues #2807
   https://github.com/canonical/cloud-init/issues/2807

** Changed in: cloud-init
   Status: Triaged => Expired

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

Title:
  Add support for setting log level on webhook reporter

Status in cloud-init:
  Expired

Bug description:
  example config:

  'reporting': {
  'maas': {
  'type': 'webhook',
  'endpoint': absolute_reverse(
  'metadata-status', args=[node.system_id],
  base_url=base_url),
  'consumer_key': token.consumer.key,
  'token_key': token.key,
  'token_secret': token.secret,
  'level': 'INFO',  # <--- breaks cloud-init
  }
  }

  [   22.612772] cloud-init[987]: 2017-02-14 20:34:37,062 - util.py[WARNING]: 
failed stage init
  [   22.619693] cloud-init[987]: failed run of stage init
  [   22.620822] cloud-init[987]: 

  [   22.621872] cloud-init[987]: Traceback (most recent call last):
  [   22.624257] cloud-init[987]:   File 
"/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 524, in 
status_wrapper
  [   22.625446] cloud-init[987]: ret = functor(name, args)
  [   22.628192] cloud-init[987]:   File 
"/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 197, in main_init
  [   22.629186] cloud-init[987]: apply_reporting_cfg(init.cfg)
  [   22.632254] cloud-init[987]:   File 
"/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 140, in 
apply_reporting_cfg
  [   22.633267] cloud-init[987]: 
reporting.update_configuration(cfg.get('reporting'))
  [   22.636398] cloud-init[987]:   File 
"/usr/lib/python3/dist-packages/cloudinit/reporting/__init__.py", line 35, in 
update_configuration
  [   22.637576] cloud-init[987]: instance = cls(**handler_config)
  [   22.640352] cloud-init[987]: TypeError: __init__() got an unexpected 
keyword argument 'level'
  [   22.641405] cloud-init[987]: 


To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1664712/+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 1658734] Re: DNS queries of does-not-exist.example.com and example.invalid

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2794

** Bug watch added: github.com/canonical/cloud-init/issues #2794
   https://github.com/canonical/cloud-init/issues/2794

** Changed in: cloud-init
   Status: Triaged => Expired

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

Title:
  DNS queries of does-not-exist.example.com and example.invalid

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

Bug description:
  cloud-init makes several DNS queries for does-not-exist.example.com
  and example.invalid (and also some random names).
  https://git.launchpad.net/cloud-init/tree/cloudinit/util.py#n1100

  We understand that it does this to detect the kind of DNS redirection
  that's done an many universities, some ISPs, and services like OpenDNS
  (when used for filtering or typo correction).

  However, it can be problematic in an environment where an intrusion
  detection system might flag these queries as potentially malicious,
  and in a system where DNS redirection is not used it unnecessarily
  increases boot time.

  It looks like the feature was written to make it possible to disable
  it or provide specific redirection IPs, but that it never gained a
  config option to control it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1658734/+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 1663304] Re: identify openstack kvm platform on arm64

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2803

** Bug watch added: github.com/canonical/cloud-init/issues #2803
   https://github.com/canonical/cloud-init/issues/2803

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  identify openstack kvm platform on arm64

Status in cloud-init:
  Expired
Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  On i386 and amd64, openstack puts 'OpenStack Nova', into the dmi platform
  information.  OpenStack using kvm on arm64, does not identify itself to the
  guest in any way.

  The result is that OpenStack nodes will not attempt to reach the metadata
  service and will be unusable.

  We need two things
   a.) change openstack to provide that information through libvirt on arm.
   b.) fix qemu bug 1662345 that prevents the information from getting to the 
guest.

  Related bugs:
   bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
   bug 1662345: [qemu] smbios parameter settings not visible in guest
   https://bugs.launchpad.net/cloud-init/+bugs?field.tag=dsid-nova

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1663304/+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 1663315] Re: identify openstack kvm platform on ppc64

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2804

** Bug watch added: github.com/canonical/cloud-init/issues #2804
   https://github.com/canonical/cloud-init/issues/2804

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
   identify openstack kvm platform on ppc64

Status in cloud-init:
  Expired
Status in OpenStack Compute (nova):
  Opinion

Bug description:
  On i386 and amd64, openstack puts 'OpenStack Nova', into the dmi platform
  information. OpenStack using kvm on ppc64el or ppc64, does not identify 
itself to the guest in any way.

  The result is that cloud-init cannot identify it is running on
  openstack.

  We need two things
   a.) change openstack to provide that information through libvirt on ppc64
   in some way.
   b.) possibly changes in qemu to pass information through that the guest
   can see.  Some options here might include putting information in
   the device tree or possibly on the attached disk (model of the disk 
could be 'OpenStack disk ').

  Related bugs:
   bug 1660385: Alert user of Ec2 Datasource on lookalike cloud
   https://bugs.launchpad.net/cloud-init/+bugs?field.tag=dsid-nova

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1663315/+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 1643043] Re: random seed command output not captured

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2765

** Bug watch added: github.com/canonical/cloud-init/issues #2765
   https://github.com/canonical/cloud-init/issues/2765

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  random seed command output not captured

Status in cloud-init:
  Expired

Bug description:
  [description]
  While using a 16.04 (Xenial) lxd cloud image, trying to create random seed 
data with a command does not get put into a specified file.

  [cloud-config]
  #cloud-config
  random_seed:
command: ["cat", "/proc/sys/kernel/random/uuid"]
command_required: true
file: /root/seed

  [steps to reproduce]
  Image used: b9cba741ef62 ubuntu 16.04 LTS amd64 (release) (20161115)
  cloud-init: 0.7.8-1-g3705bb5-0ubuntu1~16.04.3

  lxc init ubuntu:xenial/amd64 xenial
  lxc config set xenial user.user-data - < cloud-config.yaml
  lxc start xenial

  [actual result]
  There is no file called /root/seed and no error messages even though the 
command is marked as required.

  [expected result]
  I would have expected the file /root/seed to exist with a uuid in it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1643043/+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 1645118] Re: Document how to install npm/pip or other package managers

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2773

** Bug watch added: github.com/canonical/cloud-init/issues #2773
   https://github.com/canonical/cloud-init/issues/2773

** Changed in: cloud-init
   Status: Triaged => Expired

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

Title:
  Document how to install npm/pip or other package managers

Status in cloud-init:
  Expired

Bug description:
  It would be very interesting if cloud-init had clear docs on how to
  run other package managers beside the distro pm. Examples with both
  python pip and npm would be awesome. By reading the docs for some
  minutes I couldn't figure out if I should use runcmd or if there is a
  more structured aproach to it. Also maybe documenting if packages
  installed through the yaml formated config run before/after the runcmd
  is interesting.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1645118/+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 2004555] Re: [OSSA-2023-003] Unauthorized volume access through deleted volume attachments (CVE-2023-2088)

[OpenStack Infra]

Reviewed:  https://review.opendev.org/c/openstack/glance_store/+/882834
Committed: 
https://opendev.org/openstack/glance_store/commit/1d8033e54e009bbc4408f6e16aec4f6c01687c91
Submitter: "Zuul (22348)"
Branch:master

commit 1d8033e54e009bbc4408f6e16aec4f6c01687c91
Author: Brian Rosmaita 
Date:   Tue Apr 18 11:22:27 2023 -0400

Add force to os-brick disconnect

In order to be sure that devices are being removed from the host,
we should be using the 'force' parameter with os-brick's
disconnect_volume() method.

Closes-bug: #2004555
Change-Id: I63d09ad9ef465bc154c85a9ea125449c039d1b90


** Changed in: glance-store
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/2004555

Title:
  [OSSA-2023-003] Unauthorized volume access through deleted volume
  attachments (CVE-2023-2088)

Status in Cinder:
  In Progress
Status in glance_store:
  Fix Released
Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Compute (nova) antelope series:
  In Progress
Status in OpenStack Compute (nova) wallaby series:
  In Progress
Status in OpenStack Compute (nova) xena series:
  In Progress
Status in OpenStack Compute (nova) yoga series:
  In Progress
Status in OpenStack Compute (nova) zed series:
  In Progress
Status in os-brick:
  In Progress
Status in OpenStack Security Advisory:
  Fix Released
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  Hello OpenStack Security Team,

  I’m writing to you, as we faced a serious security breach in OpenStack
  functionality(correlated a bit with libvirt, iscsi and huawei driver).
  I was going through OSSA documents and correlated libvirt notes, but I
  couldn't find something similar. It is not related to
  https://security.openstack.org/ossa/OSSA-2020-006.html

  In short: we observed that newly created cinder volume(1GB size) was
  attached to compute node instance, but an instance recognized it as a
  115GB volume, which(this 115GB volume) in fact was connected to
  another instance on the same compute node.

  [1. Test environment]
  Compute node: OpenStack Ussuri configured with Huawei dorado as a storage 
backend(configuration driver is available here: 
https://docs.openstack.org/cinder/rocky/configuration/block-storage/drivers/huawei-storage-driver.html)
  Packages:
  v# dpkg -l | grep libvirt
  ii  libvirt-clients   6.0.0-0ubuntu8.16   
 amd64Programs for the libvirt library
  ii  libvirt-daemon6.0.0-0ubuntu8.16   
 amd64Virtualization daemon
  ii  libvirt-daemon-driver-qemu6.0.0-0ubuntu8.16   
 amd64Virtualization daemon QEMU connection driver
  ii  libvirt-daemon-driver-storage-rbd 6.0.0-0ubuntu8.16   
 amd64Virtualization daemon RBD storage driver
  ii  libvirt-daemon-system 6.0.0-0ubuntu8.16   
 amd64Libvirt daemon configuration files
  ii  libvirt-daemon-system-systemd 6.0.0-0ubuntu8.16   
 amd64Libvirt daemon configuration files (systemd)
  ii  libvirt0:amd646.0.0-0ubuntu8.16   
 amd64library for interfacing with different 
virtualization systems
  ii  nova-compute-libvirt  2:21.2.4-0ubuntu1   
 all  OpenStack Compute - compute node libvirt support
  ii  python3-libvirt   6.1.0-1 
 amd64libvirt Python 3 bindings

  # dpkg -l | grep qemu
  ii  ipxe-qemu 
1.0.0+git-20190109.133f4c4-0ubuntu3.2all  PXE boot 
firmware - ROM images for qemu
  ii  ipxe-qemu-256k-compat-efi-roms1.0.0+git-20150424.a25a16d-0ubuntu4 
 all  PXE boot firmware - Compat EFI ROM images for qemu
  ii  libvirt-daemon-driver-qemu6.0.0-0ubuntu8.16   
 amd64Virtualization daemon QEMU connection driver
  ii  qemu  1:4.2-3ubuntu6.23   
 amd64fast processor emulator, dummy package
  ii  qemu-block-extra:amd641:4.2-3ubuntu6.23   
 amd64extra block backend modules for qemu-system and 
qemu-utils
  ii  qemu-kvm  1:4.2-3ubuntu6.23   
 amd64QEMU Full virtualization on x86 hardware
  ii  qemu-system-common1:4.2-3ubuntu6.23   
 amd64QEMU full system emulation binaries (common files)
  ii  qemu-syst

[Yahoo-eng-team] [Bug 2004555] Re: [OSSA-2023-003] Unauthorized volume access through deleted volume attachments (CVE-2023-2088)

[Jeremy Stanley]

** Changed in: ossn
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/2004555

Title:
  [OSSA-2023-003] Unauthorized volume access through deleted volume
  attachments (CVE-2023-2088)

Status in Cinder:
  In Progress
Status in glance_store:
  In Progress
Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Compute (nova) antelope series:
  In Progress
Status in OpenStack Compute (nova) wallaby series:
  In Progress
Status in OpenStack Compute (nova) xena series:
  In Progress
Status in OpenStack Compute (nova) yoga series:
  In Progress
Status in OpenStack Compute (nova) zed series:
  In Progress
Status in os-brick:
  In Progress
Status in OpenStack Security Advisory:
  Fix Released
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  Hello OpenStack Security Team,

  I’m writing to you, as we faced a serious security breach in OpenStack
  functionality(correlated a bit with libvirt, iscsi and huawei driver).
  I was going through OSSA documents and correlated libvirt notes, but I
  couldn't find something similar. It is not related to
  https://security.openstack.org/ossa/OSSA-2020-006.html

  In short: we observed that newly created cinder volume(1GB size) was
  attached to compute node instance, but an instance recognized it as a
  115GB volume, which(this 115GB volume) in fact was connected to
  another instance on the same compute node.

  [1. Test environment]
  Compute node: OpenStack Ussuri configured with Huawei dorado as a storage 
backend(configuration driver is available here: 
https://docs.openstack.org/cinder/rocky/configuration/block-storage/drivers/huawei-storage-driver.html)
  Packages:
  v# dpkg -l | grep libvirt
  ii  libvirt-clients   6.0.0-0ubuntu8.16   
 amd64Programs for the libvirt library
  ii  libvirt-daemon6.0.0-0ubuntu8.16   
 amd64Virtualization daemon
  ii  libvirt-daemon-driver-qemu6.0.0-0ubuntu8.16   
 amd64Virtualization daemon QEMU connection driver
  ii  libvirt-daemon-driver-storage-rbd 6.0.0-0ubuntu8.16   
 amd64Virtualization daemon RBD storage driver
  ii  libvirt-daemon-system 6.0.0-0ubuntu8.16   
 amd64Libvirt daemon configuration files
  ii  libvirt-daemon-system-systemd 6.0.0-0ubuntu8.16   
 amd64Libvirt daemon configuration files (systemd)
  ii  libvirt0:amd646.0.0-0ubuntu8.16   
 amd64library for interfacing with different 
virtualization systems
  ii  nova-compute-libvirt  2:21.2.4-0ubuntu1   
 all  OpenStack Compute - compute node libvirt support
  ii  python3-libvirt   6.1.0-1 
 amd64libvirt Python 3 bindings

  # dpkg -l | grep qemu
  ii  ipxe-qemu 
1.0.0+git-20190109.133f4c4-0ubuntu3.2all  PXE boot 
firmware - ROM images for qemu
  ii  ipxe-qemu-256k-compat-efi-roms1.0.0+git-20150424.a25a16d-0ubuntu4 
 all  PXE boot firmware - Compat EFI ROM images for qemu
  ii  libvirt-daemon-driver-qemu6.0.0-0ubuntu8.16   
 amd64Virtualization daemon QEMU connection driver
  ii  qemu  1:4.2-3ubuntu6.23   
 amd64fast processor emulator, dummy package
  ii  qemu-block-extra:amd641:4.2-3ubuntu6.23   
 amd64extra block backend modules for qemu-system and 
qemu-utils
  ii  qemu-kvm  1:4.2-3ubuntu6.23   
 amd64QEMU Full virtualization on x86 hardware
  ii  qemu-system-common1:4.2-3ubuntu6.23   
 amd64QEMU full system emulation binaries (common files)
  ii  qemu-system-data  1:4.2-3ubuntu6.23   
 all  QEMU full system emulation (data files)
  ii  qemu-system-gui:amd64 1:4.2-3ubuntu6.23   
 amd64QEMU full system emulation binaries (user 
interface and audio support)
  ii  qemu-system-x86   1:4.2-3ubuntu6.23   
 amd64QEMU full system emulation binaries (x86)
  ii  qemu-utils1:4.2-3ubuntu6.23   
 amd64QEMU utilities

  # dpkg -l | grep nova
  ii  nova-c

[Yahoo-eng-team] [Bug 2004555] Re: [OSSA-2023-003] Unauthorized volume access through deleted volume attachments (CVE-2023-2088)

[OpenStack Infra]

Reviewed:  https://review.opendev.org/c/openstack/ossa/+/882879
Committed: 
https://opendev.org/openstack/ossa/commit/d62fe374e42538e11abc9b34f5c38258e8279f40
Submitter: "Zuul (22348)"
Branch:master

commit d62fe374e42538e11abc9b34f5c38258e8279f40
Author: Jeremy Stanley 
Date:   Wed May 10 14:39:22 2023 +

Add OSSA-2023-003 (CVE-2023-2088)

Change-Id: Iab9cca074c2928dbecbe512f813fe421a744c592
Closes-Bug: #2004555


** Changed in: ossa
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/2004555

Title:
  [OSSA-2023-003] Unauthorized volume access through deleted volume
  attachments (CVE-2023-2088)

Status in Cinder:
  In Progress
Status in glance_store:
  In Progress
Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Compute (nova) antelope series:
  In Progress
Status in OpenStack Compute (nova) wallaby series:
  In Progress
Status in OpenStack Compute (nova) xena series:
  In Progress
Status in OpenStack Compute (nova) yoga series:
  In Progress
Status in OpenStack Compute (nova) zed series:
  In Progress
Status in os-brick:
  In Progress
Status in OpenStack Security Advisory:
  Fix Released
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  Hello OpenStack Security Team,

  I’m writing to you, as we faced a serious security breach in OpenStack
  functionality(correlated a bit with libvirt, iscsi and huawei driver).
  I was going through OSSA documents and correlated libvirt notes, but I
  couldn't find something similar. It is not related to
  https://security.openstack.org/ossa/OSSA-2020-006.html

  In short: we observed that newly created cinder volume(1GB size) was
  attached to compute node instance, but an instance recognized it as a
  115GB volume, which(this 115GB volume) in fact was connected to
  another instance on the same compute node.

  [1. Test environment]
  Compute node: OpenStack Ussuri configured with Huawei dorado as a storage 
backend(configuration driver is available here: 
https://docs.openstack.org/cinder/rocky/configuration/block-storage/drivers/huawei-storage-driver.html)
  Packages:
  v# dpkg -l | grep libvirt
  ii  libvirt-clients   6.0.0-0ubuntu8.16   
 amd64Programs for the libvirt library
  ii  libvirt-daemon6.0.0-0ubuntu8.16   
 amd64Virtualization daemon
  ii  libvirt-daemon-driver-qemu6.0.0-0ubuntu8.16   
 amd64Virtualization daemon QEMU connection driver
  ii  libvirt-daemon-driver-storage-rbd 6.0.0-0ubuntu8.16   
 amd64Virtualization daemon RBD storage driver
  ii  libvirt-daemon-system 6.0.0-0ubuntu8.16   
 amd64Libvirt daemon configuration files
  ii  libvirt-daemon-system-systemd 6.0.0-0ubuntu8.16   
 amd64Libvirt daemon configuration files (systemd)
  ii  libvirt0:amd646.0.0-0ubuntu8.16   
 amd64library for interfacing with different 
virtualization systems
  ii  nova-compute-libvirt  2:21.2.4-0ubuntu1   
 all  OpenStack Compute - compute node libvirt support
  ii  python3-libvirt   6.1.0-1 
 amd64libvirt Python 3 bindings

  # dpkg -l | grep qemu
  ii  ipxe-qemu 
1.0.0+git-20190109.133f4c4-0ubuntu3.2all  PXE boot 
firmware - ROM images for qemu
  ii  ipxe-qemu-256k-compat-efi-roms1.0.0+git-20150424.a25a16d-0ubuntu4 
 all  PXE boot firmware - Compat EFI ROM images for qemu
  ii  libvirt-daemon-driver-qemu6.0.0-0ubuntu8.16   
 amd64Virtualization daemon QEMU connection driver
  ii  qemu  1:4.2-3ubuntu6.23   
 amd64fast processor emulator, dummy package
  ii  qemu-block-extra:amd641:4.2-3ubuntu6.23   
 amd64extra block backend modules for qemu-system and 
qemu-utils
  ii  qemu-kvm  1:4.2-3ubuntu6.23   
 amd64QEMU Full virtualization on x86 hardware
  ii  qemu-system-common1:4.2-3ubuntu6.23   
 amd64QEMU full system emulation binaries (common files)
  ii  qemu-system-data  1:4.2-3ubuntu6.23   
 all  QEMU full system emulation (data files)
  ii  qemu-system-gui:amd64 1:4.2-3ubunt

[Yahoo-eng-team] [Bug 1633453] Re: ssh is started before cloud-init completed

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2739

** Bug watch added: github.com/canonical/cloud-init/issues #2739
   https://github.com/canonical/cloud-init/issues/2739

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  ssh is started before cloud-init completed

Status in cloud-init:
  Expired
Status in cloud-init package in Ubuntu:
  Triaged

Bug description:
  Hello,

  Previously, ssh was only started after cloud-init finished configuring
  the host. In Yakkety, it is quite easy to log into a machine with SSH
  while cloud-init is still running. This enables to log as root or to
  run apt-get update while cloud-init is still finishing to write system
  configuration. This is annoying with automation.

  With Xenial, this never happens, but with Yakkety, this happens all
  the time.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1633453/+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 1620796] Re: Don't fail if attempting to add more resolvers (RHEL 7/CentOS 7)

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2718

** Bug watch added: github.com/canonical/cloud-init/issues #2718
   https://github.com/canonical/cloud-init/issues/2718

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  Don't fail if attempting to add more resolvers (RHEL 7/CentOS 7)

Status in cloud-init:
  Expired

Bug description:
  I have multiple network interfaces in OpenStack. Each defines 2
  resolvers. This goes over 3 resolvers and on RHEL that leads to the
  following traceback:

  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: [CLOUDINIT] 
util.py[DEBUG]: Read 140 bytes from /etc/resolv.conf
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: [CLOUDINIT] 
util.py[WARNING]: failed stage init-local
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: 2016-09-06 13:26:03,786 
- util.py[WARNING]: failed stage init-local
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: [CLOUDINIT] 
util.py[DEBUG]: failed stage init-local
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: failed run of stage 
init-local
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: 

  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: Traceback (most recent 
call last):
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: File 
"/usr/lib/python2.7/site-packages/cloud_init-0.7.7-py2.7.egg/cloudinit/cmd/main.py",
 line 530, in status_wrapper
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: ret = functor(name, args)
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: File 
"/usr/lib/python2.7/site-packages/cloud_init-0.7.7-py2.7.egg/cloudinit/cmd/main.py",
 line 277, in main_init
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: 
init.apply_network_config(bring_up=bool(mode != sources.DSMODE_LOCAL))
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: File 
"/usr/lib/python2.7/site-packages/cloud_init-0.7.7-py2.7.egg/cloudinit/stages.py",
 line 652, in apply_network_config
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: return 
self.distro.apply_network_config(netcfg, bring_up=bring_up)
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: File 
"/usr/lib/python2.7/site-packages/cloud_init-0.7.7-py2.7.egg/cloudinit/distros/__init__.py",
 line 162, in apply_network_config
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: dev_names = 
self._write_network_config(netconfig)
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: File 
"/usr/lib/python2.7/site-packages/cloud_init-0.7.7-py2.7.egg/cloudinit/distros/rhel.py",
 line 71, in _write_network_config
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: 
self._net_renderer.render_network_state("/", ns)
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: File 
"/usr/lib/python2.7/site-packages/cloud_init-0.7.7-py2.7.egg/cloudinit/net/sysconfig.py",
 line 395, in render_network_state
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: 
existing_dns_path=dns_path)
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: File 
"/usr/lib/python2.7/site-packages/cloud_init-0.7.7-py2.7.egg/cloudinit/net/sysconfig.py",
 line 338, in _render_dns
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: 
content.add_nameserver(nameserver)
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: File 
"/usr/lib/python2.7/site-packages/cloud_init-0.7.7-py2.7.egg/cloudinit/distros/parsers/resolv_conf.py",
 line 96, in add_nameserver
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: "'3' maximum name 
servers") % (ns))
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: ValueError: Adding 
u'172.17.48.4' would go beyond the '3' maximum name servers
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: 

  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: [CLOUDINIT] 
util.py[DEBUG]: Reading from /proc/uptime (quiet=False)
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: [CLOUDINIT] 
util.py[DEBUG]: Read 10 bytes from /proc/uptime
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: [CLOUDINIT] 
util.py[DEBUG]: cloud-init mode 'init' took 0.509 seconds (0.51)
  Sep 06 13:26:03 testing02.novalocal cloud-init[362]: [CLOUDINIT] 
handlers.py[DEBUG]: finish: init-local: SUCCESS: searching for local datasources
  Sep 06 13:26:03 testing02.novalocal systemd[1]: cloud-init-local.service: 
main process exited, code=exited, status=1/FAILURE
  Sep 06 13:26:03 testing02.novalocal systemd[1]: Failed to start Initial 
cloud-init job (pre-networking).
  Sep 06 13:26:03 testing02.novalocal systemd[1]: Unit cloud-init-local.service 
entered failed state.
  Sep 06 13:26:03 testing02.novalocal systemd[1]: cloud-init-local.service 
failed.

  On Ubuntu the name servers are added to
  /etc/network/inte

[Yahoo-eng-team] [Bug 1620807] Re: resolv.conf on CentOS 7/RHEL 7 is NetworkManager managed

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2719

** Bug watch added: github.com/canonical/cloud-init/issues #2719
   https://github.com/canonical/cloud-init/issues/2719

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  resolv.conf on CentOS 7/RHEL 7 is NetworkManager managed

Status in cloud-init:
  Expired

Bug description:
  Related to https://bugs.launchpad.net/cloud-init/+bug/1620796 I have
  found that even when I have fixed cloud-init to properly write
  resolv.conf it gets overwritten as soon as network is started because
  NetworkManager takes over control:

  /etc/resolv.conf

  # Generated by NetworkManager
  search novalocal

  
  # No nameservers found; try putting DNS servers into your
  # ifcfg files in /etc/sysconfig/network-scripts like so:
  #
  # DNS1=xxx.xxx.xxx.xxx
  # DNS2=xxx.xxx.xxx.xxx
  # DOMAIN=lab.foo.com bar.foo.com

  instead any DNS entries should be added directly to the ifcfg-eth*
  files that are generated, then let NM figure out what DNS resolvers it
  wants to add to /etc/resolv.conf.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1620807/+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 1616616] Re: shows only one ipv6 address per interface

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2710

** Bug watch added: github.com/canonical/cloud-init/issues #2710
   https://github.com/canonical/cloud-init/issues/2710

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  shows only one ipv6 address per interface

Status in cloud-init:
  Expired
Status in cloud-init package in Ubuntu:
  Confirmed

Bug description:
  With (self reported) version 0.7.7, when cloud-init displays the "Net
  device info", it only reports 1 each IPv4 and IPv6 address per
  interface, even if a second subnet has been configured on the
  interface (via ens3:1, for example).  This can be confusing to someone
  working on network configuration related issues.

  At the very minimum, it should show 1 IP per subnet, I expect.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1616616/+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 1618467] Re: cloud-init does not take into consideration proxy when adding PPA's.

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2713

** Bug watch added: github.com/canonical/cloud-init/issues #2713
   https://github.com/canonical/cloud-init/issues/2713

** Changed in: cloud-init
   Status: Incomplete => Expired

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

Title:
  cloud-init does not take into consideration proxy when adding PPA's.

Status in cloud-init:
  Expired
Status in MAAS:
  Opinion

Bug description:
  In an environment behind a proxy, I've noticed that cloud-init fails
  to add a PPA because it fails to use the proxy to add such PPA. For
  example, in this environment we are adding a PPA APT source & defining
  the proxy for APT. See below:

  
  2017-06-08 19:50:26,126 - cc_apt_configure.py[DEBUG]: apt config: convert V2 
to V3 format for keys 'apt_proxy'
  2017-06-08 19:50:26,126 - cc_apt_configure.py[DEBUG]: apt config: V1/2 and V3 
format specified, preferring V3
  2017-06-08 19:50:26,126 - cc_apt_configure.py[DEBUG]: debconf_selections was 
not set in config
  2017-06-08 19:50:26,126 - cc_apt_configure.py[DEBUG]: handling apt config: 
{'sources': {'hardware_cert_3': {'source': 
'ppa:hardware-certification/public'}}, 'proxy': 'http://10.90.90.1:8000/', 
'preserve_sources_list': False, 'security': [{'uri': 
'http://archive.ubuntu.com/ubuntu', 'arches': ['default']}], 'primary': 
[{'uri': 'http://archive.ubuntu.com/ubuntu', 'arches': ['default']}]}

  
  However, this fails to add with the following:

  
  2017-06-08 19:50:26,301 - util.py[DEBUG]: Running command 
['add-apt-repository', 'ppa:hardware-certification/public'] with allowed return 
codes [0] (shell=False, capture=True)
  2017-06-08 19:50:37,110 - cc_apt_configure.py[ERROR]: add-apt-repository 
failed.
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_apt_configure.py", 
line 609, in add_apt_sources
  util.subp(["add-apt-repository", source], target=target)
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 1814, in subp
  cmd=args)
  cloudinit.util.ProcessExecutionError: Unexpected error while running command.
  Command: ['add-apt-repository', 'ppa:hardware-certification/public']
  Exit code: 1
  Reason: -
  Stdout: Cannot add PPA: 'ppa:~hardware-certification/ubuntu/public'.
  ERROR: '~hardware-certification' user or team does not exist.
  Stderr: -

  
  cloud-init should be using the provided proxy to attempt to add the PPA, 
provided that cloud-init is being told about a proxy that APT should use. In 
other words, since we are defining the proxy for APT, it makes sense we use the 
proxy to PPA add repositories as well.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1618467/+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 2019132] [NEW] [OVN] ``OVNClient._add_router_ext_gw`` should use the context passed by the API call

[Rodolfo Alonso]

Public bug reported:

``OVNClient._add_router_ext_gw`` should use the context passed by the
API call. Instead of this, now is generating an admin context.

** Affects: neutron
 Importance: Medium
 Assignee: Rodolfo Alonso (rodolfo-alonso-hernandez)
 Status: In Progress

** Changed in: neutron
   Importance: Undecided => Medium

** Changed in: neutron
 Assignee: (unassigned) => Rodolfo Alonso (rodolfo-alonso-hernandez)

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

Title:
  [OVN] ``OVNClient._add_router_ext_gw`` should use the context passed
  by the API call

Status in neutron:
  In Progress

Bug description:
  ``OVNClient._add_router_ext_gw`` should use the context passed by the
  API call. Instead of this, now is generating an admin context.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2019132/+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 1607345] Re: Collect all logs needed to debug curtin/cloud-init for each deployment

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2701

** Bug watch added: github.com/canonical/cloud-init/issues #2701
   https://github.com/canonical/cloud-init/issues/2701

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  Collect all logs needed to debug curtin/cloud-init for each deployment

Status in cloud-init:
  Expired
Status in MAAS:
  Expired
Status in cloud-init package in Ubuntu:
  Confirmed
Status in cloud-init source package in Xenial:
  Confirmed
Status in cloud-init source package in Zesty:
  Won't Fix

Bug description:
  Re-opening this bug as confirmed because the previous SRU content
  released only provided only 'cloud-init collect-logs'. A command line
  tool which tars all cloud-init install logs and artifacts for triage.

  However, those fixes did not provide any configuration options for
  MAAS to request that those logs are automatically published to MAAS
  upon error.

  
  Cloud-init should provide cloud-config which allows consumers to specify an 
endpoint and oauth credentials to which cloud-init will automatically POST all 
compressed cloud-init log artifacts.

  
  === Original Description ===
  According to https://bugs.launchpad.net/maas/+bug/1604962/comments/12, these 
logs are needed to debug curtin/cloud-init issues but aren't collected 
automatically by MAAS:

  - /var/log/cloud-init*
  - /run/cloud-init*
  - /var/log/cloud
  - /tmp/install.log

  We need these to be automatically collected by MAAS so we can
  automatically collect them as artifacts in the case of failures in
  OIL.  curtin/cloud-init issues can be race conditions that are
  difficult to reproduce manually, so we need to grab the logs required
  to debug the first time it happens.

  === Begin SRU Template ===
  [Impact]
  ubuntu-bug cloud-init now collects cloud-init-related information for a 
bug-report

  [Test Case]

  # Launch instance under test
  $ for release in xenial zesty;
    do
  ref=$release-proposed;
  lxc-proposed-snapshot --proposed --publish $release $ref;
  lxc launch $ref $name;
  sleep 10;
  lxc exec $name ubuntu-bug cloud-init  # And follow the prompts to report 
a bogus bug
    done

  [Regression Potential]
  Worst case scenario is the apport wrapper doesn't work and the developer has 
to file a bug manually instead.

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

  === End SRU Template ===

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1607345/+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 1599694] Re: RFE: make ca-certs work on Fedora

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2689

** Bug watch added: github.com/canonical/cloud-init/issues #2689
   https://github.com/canonical/cloud-init/issues/2689

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  RFE:  make ca-certs work on Fedora

Status in cloud-init:
  Expired

Bug description:
  The ca-certs module uses debconf to manage the system's certificates,
  which means it doesn't work on non-Debian systems.  To make this work
  on Fedora we would need to write to /etc/pki/ca-
  trust/source/anchors/ca.crt and then run ``update-ca-trust''.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1599694/+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 2004555] Re: Unauthorized volume access through deleted volume attachments (CVE-2023-2088)

[Jeremy Stanley]

Since we have a lot of patches to get pushed for this, I've gone ahead
and opened the bug up about 30 minutes early. Please begin pushing the
fixes/backports to Gerrit at your earliest opportunity so I can include
the links for them in our advisory publication. Thanks!

** Description changed:

- This issue is being treated as a potential security risk under
- embargo. Please do not make any public mention of embargoed
- (private) security vulnerabilities before their coordinated
- publication by the OpenStack Vulnerability Management Team in the
- form of an official OpenStack Security Advisory. This includes
- discussion of the bug or associated fixes in public forums such as
- mailing lists, code review systems and bug trackers. Please also
- avoid private disclosure to other individuals not already approved
- for access to this information, and provide this same reminder to
- those who are made aware of the issue prior to publication. All
- discussion should remain confined to this private bug report, and
- any proposed fixes should be added to the bug as attachments. This
- embargo shall not extend past 2023-05-10 and will be made
- public by or on that date even if no fix is identified.
- 
  Hello OpenStack Security Team,
  
  I’m writing to you, as we faced a serious security breach in OpenStack
  functionality(correlated a bit with libvirt, iscsi and huawei driver). I
  was going through OSSA documents and correlated libvirt notes, but I
  couldn't find something similar. It is not related to
  https://security.openstack.org/ossa/OSSA-2020-006.html
  
  In short: we observed that newly created cinder volume(1GB size) was
  attached to compute node instance, but an instance recognized it as a
  115GB volume, which(this 115GB volume) in fact was connected to another
  instance on the same compute node.
  
  [1. Test environment]
  Compute node: OpenStack Ussuri configured with Huawei dorado as a storage 
backend(configuration driver is available here: 
https://docs.openstack.org/cinder/rocky/configuration/block-storage/drivers/huawei-storage-driver.html)
  Packages:
  v# dpkg -l | grep libvirt
  ii  libvirt-clients   6.0.0-0ubuntu8.16   
 amd64Programs for the libvirt library
  ii  libvirt-daemon6.0.0-0ubuntu8.16   
 amd64Virtualization daemon
  ii  libvirt-daemon-driver-qemu6.0.0-0ubuntu8.16   
 amd64Virtualization daemon QEMU connection driver
  ii  libvirt-daemon-driver-storage-rbd 6.0.0-0ubuntu8.16   
 amd64Virtualization daemon RBD storage driver
  ii  libvirt-daemon-system 6.0.0-0ubuntu8.16   
 amd64Libvirt daemon configuration files
  ii  libvirt-daemon-system-systemd 6.0.0-0ubuntu8.16   
 amd64Libvirt daemon configuration files (systemd)
  ii  libvirt0:amd646.0.0-0ubuntu8.16   
 amd64library for interfacing with different 
virtualization systems
  ii  nova-compute-libvirt  2:21.2.4-0ubuntu1   
 all  OpenStack Compute - compute node libvirt support
  ii  python3-libvirt   6.1.0-1 
 amd64libvirt Python 3 bindings
  
  # dpkg -l | grep qemu
  ii  ipxe-qemu 
1.0.0+git-20190109.133f4c4-0ubuntu3.2all  PXE boot 
firmware - ROM images for qemu
  ii  ipxe-qemu-256k-compat-efi-roms1.0.0+git-20150424.a25a16d-0ubuntu4 
 all  PXE boot firmware - Compat EFI ROM images for qemu
  ii  libvirt-daemon-driver-qemu6.0.0-0ubuntu8.16   
 amd64Virtualization daemon QEMU connection driver
  ii  qemu  1:4.2-3ubuntu6.23   
 amd64fast processor emulator, dummy package
  ii  qemu-block-extra:amd641:4.2-3ubuntu6.23   
 amd64extra block backend modules for qemu-system and 
qemu-utils
  ii  qemu-kvm  1:4.2-3ubuntu6.23   
 amd64QEMU Full virtualization on x86 hardware
  ii  qemu-system-common1:4.2-3ubuntu6.23   
 amd64QEMU full system emulation binaries (common files)
  ii  qemu-system-data  1:4.2-3ubuntu6.23   
 all  QEMU full system emulation (data files)
  ii  qemu-system-gui:amd64 1:4.2-3ubuntu6.23   
 amd64QEMU full system emulation binaries (user 
interface and audio support)
  ii  qemu-system-x86 

[Yahoo-eng-team] [Bug 2019119] [NEW] [sqlalchemy-20] Add the corresponding context to the upgrade checks methods

[Rodolfo Alonso]

Public bug reported:

In ``cmd.upgrade_checks.checks``, there are some methods that access to
the database. The queries are not inside a database context (reader or
writer depending on the query).

** Affects: neutron
 Importance: Undecided
 Status: New

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

Title:
  [sqlalchemy-20] Add the corresponding context to the upgrade checks
  methods

Status in neutron:
  New

Bug description:
  In ``cmd.upgrade_checks.checks``, there are some methods that access
  to the database. The queries are not inside a database context (reader
  or writer depending on the query).

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2019119/+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 1589174] Re: fix apt-source test cases to run (or skip) in buildd environment

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2674

** Bug watch added: github.com/canonical/cloud-init/issues #2674
   https://github.com/canonical/cloud-init/issues/2674

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  fix apt-source test cases to run (or skip) in buildd environment

Status in cloud-init:
  Expired

Bug description:
  Christian added a bunch of tests under
  https://code.launchpad.net/~paelzer/cloud-init/test-apt-
  source/+merge/294521 .

  Those failed to buidl first at [1] and then i patched a few of them
  under revno 1226 which made them work in my local sbuild environment.
  But they still failed in buildd environment at [2].

  I'm going to just skip the last failing test so i can get an upload,
  but want to fix these tests to either mock more or disable/skip
  conditionally if that is right.


  [1] https://launchpad.net/ubuntu/+source/cloud-init/0.7.7~bzr1225-0ubuntu1
  [2] 
https://launchpad.net/ubuntu/+source/cloud-init/0.7.7~bzr1226-0ubuntu1/+build/

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1589174/+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 1589998] Re: cloud-init runs in single user mode

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2675

** Bug watch added: github.com/canonical/cloud-init/issues #2675
   https://github.com/canonical/cloud-init/issues/2675

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  cloud-init runs in single user mode

Status in cloud-init:
  Expired
Status in cloud-init package in Ubuntu:
  Fix Released

Bug description:
  When I choose single user mode by editing the boot params and adding
  single, I would expect cloud-init and all the other cloud* services to
  see that fact and not run.

  I consider this a bug.

  Is there a work-around to make it not run.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1589998/+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 1594576] Re: cc_salt_minion behaves badly if apt-get update fails

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2680

** Bug watch added: github.com/canonical/cloud-init/issues #2680
   https://github.com/canonical/cloud-init/issues/2680

** Changed in: cloud-init
   Status: Triaged => Expired

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

Title:
  cc_salt_minion behaves badly if apt-get update fails

Status in cloud-init:
  Expired

Bug description:
  I'm using cloud-init to setup some salt-minion config like so:

   #cloud-config
   salt_minion:
 conf:
   grains:
 my_grain_1: a
 my_grain_2: b

  cc_salt_minion.py triggers apt-get update.  If apt-get update fails,
  then cc_salt_minion does not update /etc/salt/minion, but nonetheless
  continues.  My automation depends on finding these grains, and salt-
  minion is already built in.

  Please consider the attached patch, which will skip the install if a
  flag is included.  Alternatively, cc_salt_minion could write out
  /etc/salt/minion even if apt-get fails.

  Ross

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1594576/+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 1596013] Re: interfaces file regenerated on each boot for some datasources

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2683

** Bug watch added: github.com/canonical/cloud-init/issues #2683
   https://github.com/canonical/cloud-init/issues/2683

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  interfaces file regenerated on each boot for some datasources

Status in cloud-init:
  Expired

Bug description:
  cloud-init will re-write /etc/network/interfaces.d/50-cloud-init.cfg
  in cloud-init local mode when it does not find a valid datasource and
  the previous datasource did not implement check_instance_id.

  -- original bug --
  On xenial (using daily images from today), if I create a new VM:

  sudo uvt-kvm create --cpu 4 --memory 2000 --disk 30 --bridge virbr0
  --password ubuntu tester release=xenial

  and make some changes to the /etc/network/interfaces.d/50-cloud-
  init.cfg file, when I reboot, those changes are gone.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1596013/+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 2018232] Re: qos and trunks does not show any entries

[OpenStack Infra]

Reviewed:  https://review.opendev.org/c/openstack/horizon/+/882744
Committed: 
https://opendev.org/openstack/horizon/commit/c770785dcf6cb9d79ae26986ce5156e4ddc0f534
Submitter: "Zuul (22348)"
Branch:master

commit c770785dcf6cb9d79ae26986ce5156e4ddc0f534
Author: Tatiana Ovchinnikova 
Date:   Tue May 9 14:04:35 2023 -0500

Fix qos and trunks tables

When replacing deprecated custom callback methods success()/error()
with then()/catch(), we need to keep in mind that methods' signatures
and return values are different, so we need to explicitly return the
response value when using then(function onSuccess(response){}).

Closes-Bug: #2018232

Change-Id: I9d6d769075753c6395db2530a8d60ec28cafdc3d


** Changed in: horizon
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/2018232

Title:
  qos and trunks does not show any entries

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  Horizon Zed does not show any entries in "network/network qos" and
  "network/trunks" it just shows "No items to display" and there is an
  error in the browser console:

  TypeError: Cannot read properties of undefined (reading 'data')
  at modifyResponse (output.2f23aa85dea9.js:868:63)
  at processQueue (output.c0c52d1d8fb8.js:1581:786)
  at output.c0c52d1d8fb8.js:1585:110
  at Scope.$digest (output.c0c52d1d8fb8.js:1636:200)
  at Scope.$apply (output.c0c52d1d8fb8.js:1643:269)
  at done (output.c0c52d1d8fb8.js:1356:123)
  at completeRequest (output.c0c52d1d8fb8.js:1375:20)
  at XMLHttpRequest.requestLoaded (output.c0c52d1d8fb8.js:1368:1) 'Possibly 
unhandled rejection: {}'
  (

  TypeError: Cannot read properties of undefined (reading 'data')
  at addTrackBy (output.5e3096d425c4.js:1114:59)
  at processQueue (output.989d06bb6631.js:1469:260)
  at output.989d06bb6631.js:1470:135
  at Scope.$eval (output.989d06bb6631.js:1516:549)
  at Scope.$digest (output.989d06bb6631.js:1510:200)
  at Scope.$apply (output.989d06bb6631.js:1517:277)
  at done (output.989d06bb6631.js:1244:123)
  at completeRequest (output.989d06bb6631.js:1259:20)
  at XMLHttpRequest.requestLoaded (output.989d06bb6631.js:1253:1)
  (

  With CLI everything works just fine:

  $ openstack network qos policy list
  
+--+-++-+--+
  | ID   | Name| Shared | Default | Project 
 |
  
+--+-++-+--+
  | 01d40d01-45b0-404f-8064-06d502baaeae | test01 | False  | False   | 
f5b9d6bf68184e3da8aaebef2d4804be |
  | 549420b8-9562-474c-a02c-3910866eb145 | test02 | True   | False   | 
f5b9d6bf68184e3da8aaebef2d4804be |
  | 5f5194c2-4b98-4d26-8021-74a5c8a93e27 | test03 | False  | False   | 
f5b9d6bf68184e3da8aaebef2d4804be |
  
+--+-++-+--+

  Tested on kolla-asible Zed (Ubuntu 22.04) and packstack Zed (CentOS
  Stream 9) both with the same result.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/2018232/+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 1583841] Re: cc_chef fails when using 'gems' installer because Ubuntu 16.04 no longer includes Ruby 1.8

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2670

** Bug watch added: github.com/canonical/cloud-init/issues #2670
   https://github.com/canonical/cloud-init/issues/2670

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  cc_chef fails when using 'gems' installer because Ubuntu 16.04 no
  longer includes Ruby 1.8

Status in cloud-init:
  Expired
Status in cloud-init package in Ubuntu:
  Confirmed

Bug description:
  Ubuntu 16.04

  # dpkg -l | grep cloud-init
  ii  cloud-init   0.7.7~bzr1212-0ubuntu1  all  
Init scripts for cloud instances
  ii  cloud-initramfs-copymods 0.27ubuntu1 all  
copy initramfs modules into root filesystem for later use
  ii  cloud-initramfs-dyn-netconf  0.27ubuntu1 all  
write a network interface file in /run for BOOTIF

  Minimum Ruby version supported in Ubuntu 16.04 is Ruby 2.3.

  Syslog output:

  May 19 23:41:38 ubuntu [CLOUDINIT] util.py[DEBUG]: apt-update [eatmydata 
apt-get --option=Dpkg::Options::=--force-confold 
--option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet update] took 
20.50
  1 seconds
  May 19 23:41:38 ubuntu [CLOUDINIT] util.py[DEBUG]: Running command 
['eatmydata', 'apt-get', '--option=Dpkg::Options::=--force-confold', 
'--option=Dpkg::options::=--force-unsafe-io', '--assume-yes', '--qui
  et', 'install', 'ruby1.8', 'ruby1.8-dev', 'libopenssl-ruby1.8', 
'rubygems1.8'] with allowed return codes [0] (shell=False, capture=False)
  May 19 23:41:39 ubuntu [CLOUDINIT] util.py[DEBUG]: apt-install [eatmydata 
apt-get --option=Dpkg::Options::=--force-confold 
--option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet install ruby1.8 
r
  uby1.8-dev libopenssl-ruby1.8 rubygems1.8] took 0.295 seconds
  May 19 23:41:39 ubuntu [CLOUDINIT] handlers.py[DEBUG]: finish: 
modules-config/config-chef: FAIL: running config-chef with frequency 
once-per-instance
  May 19 23:41:39 ubuntu [CLOUDINIT] util.py[WARNING]: Running module chef 
() failed
  May 19 23:41:39 ubuntu [CLOUDINIT] util.py[DEBUG]: Running module chef 
() 
failed#012Traceback (most rec
  ent call last):#012  File 
"/usr/lib/python3/dist-packages/cloudinit/stages.py", line 739, in 
_run_modules#012freq=freq)#012  File 
"/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 70, in run#0
  12return self._runners.run(name, functor, args, freq, clear_on_fail)#012  
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 199, in 
run#012results = functor(*args)#012  File "/usr/l
  ib/python3/dist-packages/cloudinit/config/cc_chef.py", line 257, in 
handle#012run = install_chef(cloud, chef_cfg, log)#012  File 
"/usr/lib/python3/dist-packages/cloudinit/config/cc_chef.py", line 296,
   in install_chef#012install_chef_from_gems(ruby_version, chef_version, 
cloud.distro)#012  File 
"/usr/lib/python3/dist-packages/cloudinit/config/cc_chef.py", line 330, in 
install_chef_from_gems#012
  distro.install_packages(get_ruby_packages(ruby_version))#012  File 
"/usr/lib/python3/dist-packages/cloudinit/distros/debian.py", line 75, in 
install_packages#012self.package_command('install', pkgs=pk
  glist)#012  File 
"/usr/lib/python3/dist-packages/cloudinit/distros/debian.py", line 176, in 
package_command#012args=(cmd,), kwargs={'env': e, 'capture': False})#012  
File "/usr/lib/python3/dist-packag
  es/cloudinit/util.py", line 2040, in log_time#012ret = func(*args, 
**kwargs)#012  File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 
1704, in subp#012cmd=args)#012cloudinit.util.Process
  ExecutionError: Unexpected error while running command.#012Command: 
['eatmydata', 'apt-get', '--option=Dpkg::Options::=--force-confold', 
'--option=Dpkg::options::=--force-unsafe-io', '--assume-yes', '--qu
  iet', 'install', 'ruby1.8', 'ruby1.8-dev', 'libopenssl-ruby1.8', 
'rubygems1.8']#012Exit code: 100#012Reason: -#012Stdout: ''#012Stderr: ''



  # apt-cache policy ruby
  ruby:
Installed: (none)
Candidate: 1:2.3.0+1
Version table:
   1:2.3.0+1 500
  500 http://us-west-2.ec2.archive.ubuntu.com/ubuntu xenial/main amd64 
Packages

  # apt-cache search ^ruby
  rake - ruby make-like utility
  ruby - Interpreter of object-oriented scripting language Ruby (default 
version)
  ruby-all-dev - Ruby development environment (all versions supported in Debian)
  ruby-dev - Header files for compiling extension modules for Ruby (default 
version)
  ruby-did-you-mean - smart error messages for Ruby > 2.3
  ruby-minitest - Ruby test tools supporting TDD, BDD, mocking, and benchmarking
  ruby-net-telnet - telnet client library
  ruby-power-assert - library showing values of variables and method calls in 
an expression
  ruby-rrd - time-series data st

[Yahoo-eng-team] [Bug 1571629] Re: Azure data source contains hardcoded distribution-specific paths

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2655

** Bug watch added: github.com/canonical/cloud-init/issues #2655
   https://github.com/canonical/cloud-init/issues/2655

** Changed in: cloud-init
   Status: In Progress => Expired

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

Title:
  Azure data source contains hardcoded distribution-specific paths

Status in cloud-init:
  Expired

Bug description:
  The Azure data source (in sources/helpers/azure.py) attempts to read
  the current DHCP lease from /var/lib/dhcp/dhclient.eth0.leases, but
  that path does not exist on, for example, RHEL/Fedora/CentOS
  environments (which appear to use /var/lib/dhclient/dhclient--
  eth0.lease).

  The location of the lease file should probably be part of the Distro
  object.

  A secondary problem is that the WALinuxAgentShim class does not have
  any access to the Distro object, so that code needs some fiddling to
  implement this fix.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1571629/+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 1568940] Re: validation_key in client.rb should be filepath not actual validation key content

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2645

** Bug watch added: github.com/canonical/cloud-init/issues #2645
   https://github.com/canonical/cloud-init/issues/2645

** Changed in: cloud-init
   Status: Triaged => Expired

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

Title:
  validation_key in client.rb should be filepath not actual validation
  key content

Status in cloud-init:
  Expired

Bug description:
  The chef example shows that you need to pass validation key content in
  user data
  (http://cloudinit.readthedocs.org/en/latest/topics/examples.html#install-
  and-run-chef-recipes) which will populate /etc/chef/validation.pem.
  This populates /etc/chef/validation.pem correctly on your vm but
  unfortunately puts this content as the value of validation_key in
  /etc/chef/client.rb. This value should be a file path as per
  documentation: https://docs.chef.io/config_rb_client.html.

  validation_key
  The location of the file that contains the key used when a chef-client is 
registered with a Chef server. A validation key is signed using the 
validation_client_name for authentication. Default value: 
/etc/chef/validation.pem.

  When you try to run chef-client on this node you will get the
  following error:

  Creating a new client identity for poliva-bescloud-
  admin.poliva.dev.altus.bblabs using the validator key.

  

  Chef encountered an error attempting to create the client 
"poliva-bescloud-admin.poliva.dev.altus.bblabs"
  


  Private Key Not Found:
  --
  Your private key could not be loaded. If the key file exists, ensure that it 
is
  readable by chef-client.

  Relevant Config Settings:
  -
  validation_key "-BEGIN RSA PRIVATE KEY-
  
  -END RSA PRIVATE KEY-"

  I have noticed that when running chef-client as daemon though you do
  not hit this problem (not sure why). But in my case I didn't want to
  run in daemon mode.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1568940/+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 1569469] Re: smartos datasource stacktrace if no system-product-name in dmi data

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2647

** Bug watch added: github.com/canonical/cloud-init/issues #2647
   https://github.com/canonical/cloud-init/issues/2647

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  smartos datasource stacktrace if no system-product-name in dmi data

Status in cloud-init:
  Expired
Status in cloud-init package in Ubuntu:
  Fix Released

Bug description:
  if there is no product name in dmi data, cloud-init log will show

  DataSourceCloudSigma.py[WARNING]: failed to get hypervisor product name via 
dmi data
  util.py[WARNING]: Getting data from  failed
  util.py[DEBUG]: Getting data from  failed#
  Traceback (most recent call last):#
File "/usr/lib/python3/dist-packages/cloudinit/sources/__init__.py", line 
266, in find_source#
  if s.get_data():#
File 
"/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceSmartOS.py", line 
250, in get_data#
  if 'smartdc' not in system_type.lower():#
  AttributeError: 'NoneType' object has no attribute 'lower'

  
  Fix is simple enough.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1569469/+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 1556260] Re: cloud-init fails to grow disk on physical servers with multipath.

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2630

** Bug watch added: github.com/canonical/cloud-init/issues #2630
   https://github.com/canonical/cloud-init/issues/2630

** Changed in: cloud-init
   Status: Triaged => Expired

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

Title:
  cloud-init fails to grow disk on physical servers with multipath.

Status in cloud-init:
  Expired
Status in cloud-init package in Ubuntu:
  Triaged

Bug description:
  for provisioning ubuntu trusty on  baremetal, cloud-init fails to grow root 
partition,  below is the error.
  physical server is  HP bl460c blade , booting from SAN and using  multipath ,

  
   - cc_growpart.py[DEBUG]: No 'growpart' entry in cfg.  Using default: 
{'ignore_growroot_disabled': False, 'mode': 'auto', 'devices': ['/']}
   - util.py[DEBUG]: Running command ['growpart', '--help'] with allowed return 
codes [0] (shell=False, capture=True)
   - util.py[DEBUG]: Reading from /proc/1005/mountinfo (quiet=False)
  - util.py[DEBUG]: Read 1121 bytes from /proc/1005/mountinfo
  - util.py[DEBUG]: resize_devices took 0.003 seconds
   - cc_growpart.py[DEBUG]: '/' SKIPPED: 
device_part_info(/dev/disk/by-label/cloudimg-rootfs) failed: 
/dev/disk/by-label/cloudimg-rootfs not a partition
  

  upon checking seems like  cc_growpart.py script is relying on
  "/sys/class/block/device-name/partition" file to check number of
  partitions.

  but for dm multipath devices , there is no such "partition" attribute
  exists, hence script error out saying "not a partition".

  
  I do not have any solution for now,  but trying to find how to map  multipath 
device like  /dev/dm-1  to  it's real scsi disk /dev/sda1  .. if that's figured 
out then we can put some logic to say if  base name is  dm-x  then find mapped 
sdx  and use that device to find a partition etc.

  is this just me or someone else also has this issue with cloud-init
  failing on multipath disks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1556260/+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 1556100] Re: Naïvely assumes package upgrade command is "upgrade"; breaks package_upgrade on SLES

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2629

** Bug watch added: github.com/canonical/cloud-init/issues #2629
   https://github.com/canonical/cloud-init/issues/2629

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  Naïvely assumes package upgrade command is "upgrade"; breaks
  package_upgrade on SLES

Status in cloud-init:
  Expired

Bug description:
  cc_package_update_upgrade_install.py assumes that for a package
  upgrade, it can simply append the literal "upgrade" to the
  package_command in order to effect a system package upgrade.

  On SLES, this causes zypper to be invoked as "zypper --non-interactive
  upgrade"; but zypper doesn't have an "upgrade" option. It's called
  "update" instead, and for this to work, zypper would have to be called
  as "zypper --non-interactive update".

  In other words, given a cloud-config of

  # cloud-config
  package_update: true
  package_upgrade: true

  ... the former will succeed and the latter will fail, which is not
  only broken functionality but also highly unintuitive.

  Suggestion: define a per-distro method named upgrade_packages, akin to
  update_package_sources, and invoke that method rather than naïvely
  appending "upgrade" to whatever the package_command has been
  determined to be.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1556100/+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 1565711] Re: vlan configuration/unconfigured interfaces creates slow boot time

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2639

** Bug watch added: github.com/canonical/cloud-init/issues #2639
   https://github.com/canonical/cloud-init/issues/2639

** Changed in: cloud-init
   Status: Incomplete => Expired

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

Title:
  vlan configuration/unconfigured interfaces creates slow boot time

Status in cloud-init:
  Expired
Status in curtin:
  Triaged
Status in ifupdown:
  New
Status in MAAS:
  Won't Fix

Bug description:
  maas: 1.9.1+bzr4543-0ubuntu1~trusty1 (from proposed PPA)

  Deploying juju bootstrap node on Ubuntu 14.04 with the following
  network configuration:

  eth0
  static assigned IP address, default VLAN (no trunking)

  eth1
 static assigned IP address, secondary VLAN

 eth1.2667
 static assigned IP address, VLAN 2667

 eth1.2668
 static assigned IP address, VLAN 2668

 eth1.2669
 static assigned IP address, VLAN 2669

 eth1.2670
 static assigned IP address, VLAN 2670

  eth2
unconfigured

  eth3
unconfigured

  
  MAAS generates a /e/n/i which auto stanzas for the VLAN devices and the 
unconfigured network interfaces; the upstart process which checks that network 
configuration is complete waits for /var/run/ifup. to exists for all auto 
interfaces; these will never appear for either the VLAN interfaces or the 
unconfigured network interfaces.

  As a result, boot time if very long as cloud-init and networking both
  take 2 minutes to timeout waiting for network interfaces that will
  never appear to be configured.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1565711/+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 1543459] Re: login available before cloud-init completed

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2620

** Bug watch added: github.com/canonical/cloud-init/issues #2620
   https://github.com/canonical/cloud-init/issues/2620

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  login available before cloud-init completed

Status in cloud-init:
  Expired
Status in cloud-init package in Ubuntu:
  Confirmed

Bug description:
  serial console login, is available before cloud init finished setting
  up the user (e.g. password).

  This is with nocloud provider, in libvirt / qemu.

  console log is here:

  https://pastebin.canonical.com/149365/

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1543459/+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 1531233] Re: improve oauth skew to base off uptime

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2607

** Bug watch added: github.com/canonical/cloud-init/issues #2607
   https://github.com/canonical/cloud-init/issues/2607

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  improve oauth skew to base off uptime

Status in cloud-init:
  Expired
Status in curtin:
  Confirmed

Bug description:
  when doing oauth, each request needs to include a timestamp that matches a 
window of the host's clock.
  So, if our local clock is broken we need to adjust it.  Cloud-init and curtin 
handle this by adding a 'skew', and recently store that skew in a dictionary 
for later reference.  The issue though is that currently we store the skew off 
the current local time.  This works fine until the local time is updated, and 
then it would result in us having a *bad* offset where using none would work.

  During boot, ntp or systemd-network-timed might update the clock, so
  we have to be aware of that.

  My plan for a fix is to use uptime as an always increasing/stable
  clock.

  To address the fact that a clock could be wildly inaccurate, we can
  discard the stored skew if it is older than 10 minutes or some
  reasonably large value.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1531233/+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 1536706] Re: rh_subscription plugin attemps connection even when no config is provided

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2613

** Bug watch added: github.com/canonical/cloud-init/issues #2613
   https://github.com/canonical/cloud-init/issues/2613

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  rh_subscription plugin attemps connection even when no config is
  provided

Status in cloud-init:
  Expired

Bug description:
  The rh_subscription plugin attempts to connect to the RHN servers even
  when no config is provided.  This can introduce a large delay in the
  boot process if the local environment is dropping outbound packets.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1536706/+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 1533899] Re: Add support for proxies

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2612

** Bug watch added: github.com/canonical/cloud-init/issues #2612
   https://github.com/canonical/cloud-init/issues/2612

** Changed in: cloud-init
   Status: Incomplete => Expired

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

Title:
  Add support for proxies

Status in cloud-init:
  Expired
Status in Snap Layer:
  Fix Released
Status in Snapcraft:
  Invalid
Status in Snappy:
  Fix Released
Status in snapweb:
  Invalid
Status in snapd package in Ubuntu:
  Fix Released
Status in snapd source package in Trusty:
  Fix Released

Bug description:
  Actually ubuntu-core do not support proxy configuration, that is a problem 
for example for run correctly "webdm": "Error: Get 
https://search.apps.ubuntu.com/api/v1/search? read: connection refused".
  I can configure proxy with export http_proxy="http://x.x.x.x.x"; but only 
affects the session not the wide system.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1533899/+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 1532234] Re: Merging with data in /etc/cloud/cloud.cfg does not work as expected

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2611

** Bug watch added: github.com/canonical/cloud-init/issues #2611
   https://github.com/canonical/cloud-init/issues/2611

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  Merging with data in /etc/cloud/cloud.cfg does not work as expected

Status in cloud-init:
  Expired

Bug description:
  Given the following user-data:

    #cloud-config
    merge_how: 'list(append)+dict(recurse_array)+str()'
    disable_root: 0
    users:
  - name: foobar
    gecos: Foo B. Bar
    lock-passwd: false
    passwd: secret
  - name: barfoo
    gecos: Bar B. Foo
    lock-passwd: true

    cloud_config_modules:
  - yum-add-repo

    runcmd:
  - https://yourrxpills.com

  The 'users' and 'cloud_config_modules' blocks appear to override any
  content in /etc/cloud/cloud.cfg, rather than appending as one would
  expect.  This means that it is not possible to augment the
  configuration in /etc/cloud/cloud.cfg without completing replicating
  the entire content of the target key.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1532234/+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 1508543] Re: AuthorizedKeysFile in match block will prevent default user login

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2591

** Bug watch added: github.com/canonical/cloud-init/issues #2591
   https://github.com/canonical/cloud-init/issues/2591

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  AuthorizedKeysFile in match block will prevent default user login

Status in cloud-init:
  Expired

Bug description:
  Hi.

  Consider the following sshd_config which is pretty standard with only
  an added "Match" block.

  -8<
  <...>
  Port 22
  AuthorizedKeysFile%h/.ssh/authorized_keys
  <...>
  Match group foobar
  AuthorizedKeysFile /etc/ssh/authorizedkeys/%u
  -8<

  
  When starting an instance pre-configured with the above sshd_config (in my 
case AWS EC2), cloud-init will parse /etc/ssh/sshd_config to know where it 
should put the public key of the default "ubuntu" user. The problem is that 
cloud-init is not an sshd_config parser and looking at the code it just do a 
line-by-line parsing.

  In this case, it will pick up the AuthorizedKeysFile value that is in
  the Match block because it's the last one in the file and will end up
  putting the default user key under /etc/ssh/authorizedkeys/ubuntu,
  preventing login into the instance because from the sshd point of
  view, the correct key location for that user (which is *not* part of
  the "foobar" group) is $HOMEDIR/.ssh/authorized_keys.

  The obvious workaround is to append the default AuthorizedKeysFile at the end 
of the file but it would have been nice to know it beforehand ;-)
  I understand that line-by-line parsing is the easy way, but in the case of 
ssh it is very error-prone and can lead to unexpected behaviour...

  Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1508543/+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 1511589] Re: maas provider, hwclock out of sync means juju will not work

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2593

** Bug watch added: github.com/canonical/cloud-init/issues #2593
   https://github.com/canonical/cloud-init/issues/2593

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  maas provider, hwclock out of sync means juju will not work

Status in cloud-init:
  Expired
Status in curtin:
  Triaged
Status in falkor:
  Fix Released
Status in juju-core:
  Invalid
Status in MAAS:
  Fix Released

Bug description:
  MAAS provides no means to ensure the hardware clock is set, and juju
  relies on accurate clocks.

  Leading to errors like this when you bootstrap on machines that
  otherwise works fine:

  "ERROR juju.cmd supercommand.go:430 gomaasapi: got error back from server:
  401 OK (Authorization Error: \'Expired timestamp: given 1446087606 and now
  1446094822 has a greater difference than threshold 300\')\nERROR failed to
  bootstrap environment: subprocess encountered error code 1\n\')'), 1),
  (u'waiting', 179), (u'succeeded', 10)]"

  The only thing a user can do is touch each machine, sometimes booting
  them into an OS to fix their hwclock (which can still drift from that
  point, of course).

  This error path is exposed when the stock 'ntpdate' from ubuntu does
  not work, for instance, if your lab is behind a proxy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1511589/+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 1513142] Re: cloud-init ignores configured cloud_dir for status.json and result.json data

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2595

** Bug watch added: github.com/canonical/cloud-init/issues #2595
   https://github.com/canonical/cloud-init/issues/2595

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  cloud-init ignores configured cloud_dir for status.json and
  result.json data

Status in cloud-init:
  Expired

Bug description:
  Somewhere between cloud-init-0.7.4 and cloud-init-0.7.5, the cloud-
  init runtime was refactored a bit so that certain cloud-init data is
  dropped statically into certain locations (/var/lib/cloud/data and
  /run/cloud-init) rather than locations in the configured cloud_dir.

  The particular problem crops up in the 'status_wrapper' function in
  the cloud-init runtime -- although the function accepts arguments for
  the 'data dir' and the 'link dir' (/var/lib/cloud/data and /run/cloud-
  init respectively), the actual CLI does not pass any arguments (nor
  does it allow the user to pass arguments either via the CLI or read
  from the cloud.cfg).

  Thus, cloud-init data is scattered in all of the following locations:

  * The configured cloud_dir
  * /var/lib/cloud/data
  * /run/cloud-init

  ...which is contrary to the previous behavior (0.7.4 and prior), where
  everything is co-located in the cloud_dir.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1513142/+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 1513109] Re: Ephemeral w/o FS gets added to fstab

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2594

** Bug watch added: github.com/canonical/cloud-init/issues #2594
   https://github.com/canonical/cloud-init/issues/2594

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  Ephemeral w/o FS gets added to fstab

Status in cloud-init:
  Expired

Bug description:
  Using a DS that includes ec2 metadata with an ephemeral disk, even if
  the ephemeral disk is not formatted with a filesystem, cc_mounts adds
  an fstab entry that is likely invalid and potentially breaking reboot
  in some cases.  I've seen this affect Debian based images and if
  needing to reproduce, Rax OnMetal I/O flavor is a good candidate.  We
  are adjusting the base images cloud config to avoid hitting this but,
  any other cloud providers that provision non-formatted ephemeral disks
  would likely have similar issues.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1513109/+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 1517180] Re: No support for adding custom certificate chains

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2600

** Bug watch added: github.com/canonical/cloud-init/issues #2600
   https://github.com/canonical/cloud-init/issues/2600

** Changed in: cloud-init
   Status: Triaged => Expired

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

Title:
  No support for adding custom certificate chains

Status in cloud-init:
  Expired
Status in curtin:
  Triaged
Status in MAAS:
  Invalid

Bug description:
  In a MAAS behind a proxy that uses a self-signed certificate, when
  machines provisioned using maas attempt to contact e.g.
  https://entropy.ubuntu.com, they fail to validate the cert chain and
  fail.

  Suggested solution borrowed from an email from kirkland:

  On the MAAS administrative configuration page, we should add a small
  section where the MAAS admin can copy/paste/edit any certificate
  chains that they want to add to machines provisioned by MAAS.  These
  certs should then be inserted into /etc/ssl/certs by cloud-init or
  curtin on initial install (depending on the earliest point at which
  the cert might be needed).

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1517180/+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 1518864] Re: Reproducibility: remove timestamps in generated files.

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2601

** Bug watch added: github.com/canonical/cloud-init/issues #2601
   https://github.com/canonical/cloud-init/issues/2601

** Changed in: cloud-init
   Status: Triaged => Expired

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

Title:
  Reproducibility: remove timestamps in generated files.

Status in cloud-init:
  Expired

Bug description:
  Hi Scott,

  in , it was suggested to avoid
  timestamps in generated files such as `/etc/sudoers.d/90-cloud-init-
  users`, in order to enhance reproducibility in installed systems.
  Would you consider doing so ?

  Have a nice day,

  -- 
  Charles

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1518864/+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 1521554] Re: lock_passwd (default_user) vs lock-passwd (normal user)

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2604

** Bug watch added: github.com/canonical/cloud-init/issues #2604
   https://github.com/canonical/cloud-init/issues/2604

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  lock_passwd  (default_user) vs lock-passwd (normal user)

Status in cloud-init:
  Expired

Bug description:
  In our use case we only have one user we create with the cloud-init
  configuration file. We need a password set for this user so we
  configured him as the default_user as follows:

  system_info:
default_user:
 name: demo
   passwd: PASSWORDHASH
   shell: /bin/bash
   lock-passwd: False

  But the password was always locked over and over again.

  After some troubleshooting I figured the lock param was wrong.
  Apparently for a normal user it's lock-passwd (with a hyphen) but for
  the default user it's lock_passwd (with an underscore)

  To me this was very confusing and I lost a lot of time on this little
  difference. Is there any particular reason why the differ? Wouldn't it
  be a better idea to streamline them using only one of the two options
  for both?

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1521554/+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 2019097] [NEW] CI tests neutron-dynamic-routing broken

[Felix Huettner]

Public bug reported:

The unittests of neutron-dynamic-routing are broken if using the latest neutron 
master branch.
The issue starts appearing once  670cc383e0345063c0bf9022f8829d5817457e00 is 
part of neutron (switch to new rbac defaults).

This happens without any modifications of neutron-dynamic-routing by just using 
the master branch
Output of the failed tests is attached.

** Affects: neutron
 Importance: Undecided
 Assignee: Felix Huettner (felix.huettner)
 Status: New

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

Title:
  CI tests neutron-dynamic-routing broken

Status in neutron:
  New

Bug description:
  The unittests of neutron-dynamic-routing are broken if using the latest 
neutron master branch.
  The issue starts appearing once  670cc383e0345063c0bf9022f8829d5817457e00 is 
part of neutron (switch to new rbac defaults).

  This happens without any modifications of neutron-dynamic-routing by just 
using the master branch
  Output of the failed tests is attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2019097/+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 1479988] Re: AttributeError: 'ResolvConf' object has no attribute 'encode'

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2572

** Bug watch added: github.com/canonical/cloud-init/issues #2572
   https://github.com/canonical/cloud-init/issues/2572

** Changed in: cloud-init
   Status: Incomplete => Expired

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

Title:
  AttributeError: 'ResolvConf' object has no attribute 'encode'

Status in cloud-init:
  Expired

Bug description:
  Seeing the following on a rhel6 rpm build of cloud-init:

  Probably due to encoding tweaks recently done,

  2015-07-30 21:17:28,151 - util.py[DEBUG]: Getting data from  failed
  Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/cloudinit/sources/_init_.py", line 
255, in find_source
  if s.get_data():
  File 
"/usr/lib/python2.6/site-packages/cloudinit/sources/DataSourceConfigDrive.py", 
line 120, in get_data
  on_first_boot(results, distro=self.distro)
  File 
"/usr/lib/python2.6/site-packages/cloudinit/sources/DataSourceConfigDrive.py", 
line 215, in on_first_boot
  distro.apply_network(net_conf)
  File "/usr/lib/python2.6/site-packages/cloudinit/distros/_init_.py", line 
122, in apply_network
  dev_names = self._write_network(settings)
  File "/usr/lib/python2.6/site-packages/cloudinit/distros/rhel.py", line 102, 
in _write_network
  nameservers, searchservers)
  File "/usr/lib/python2.6/site-packages/cloudinit/distros/rhel_util.py", line 
84, in update_resolve_conf_file
  util.write_file(fn, r_conf, 0o644)
  File "/usr/lib/python2.6/site-packages/cloudinit/util.py", line 1625, in 
write_file
  content = encode_text(content)
  File "/usr/lib/python2.6/site-packages/cloudinit/util.py", line 93, in 
encode_text
  return text.encode(encoding)
  AttributeError: 'ResolvConf' object has no attribute 'encode'

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1479988/+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 1477944] Re: Azure data source should handle more than one ProvisioningSection

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2570

** Bug watch added: github.com/canonical/cloud-init/issues #2570
   https://github.com/canonical/cloud-init/issues/2570

** Changed in: cloud-init
   Status: Incomplete => Expired

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

Title:
  Azure data source should handle more than one ProvisioningSection

Status in cloud-init:
  Expired

Bug description:
  Azure have informed us that they will be introducing a second format
  for metadata in ovf-env.xml, which will be done using multiple
  versioned ProvisioningSections.

  At the moment, cloud-init chokes if there is more than a single
  ProvisioningSection. We should, instead, be looking for the version
  1.0 ProvisioningSection and ignoring all others.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1477944/+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 1461201] Re: Check for systemd (in distros/rhel.py) is fragile

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2557

** Bug watch added: github.com/canonical/cloud-init/issues #2557
   https://github.com/canonical/cloud-init/issues/2557

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  Check for systemd (in distros/rhel.py) is fragile

Status in cloud-init:
  Expired

Bug description:
  The existing cloud-init code determines if systemd is in use by
  looking at the distribution name and version.  This is prone to error
  because:

  - RHEL derivatives other than CentOS (e.g., Scientific Linux) will fail this 
test, and
  - Distributions that are not derived from RHEL also use systemd

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1461201/+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 1459464] Re: fs_config fails to set force flag

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2554

** Bug watch added: github.com/canonical/cloud-init/issues #2554
   https://github.com/canonical/cloud-init/issues/2554

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  fs_config fails to set force flag

Status in cloud-init:
  Expired

Bug description:
  It looks like the force flag is never appended because fs_cmd is
  always set:

  http://bazaar.launchpad.net/~cloud-init-dev/cloud-
  init/trunk/view/head:/cloudinit/config/cc_disk_setup.py#L843

  It is probably safe to change
  if not fs_cmd and (overwrite or device_type(device) == "disk"):
  to
  if overwrite:

  (not sure how the device_type(device) == disk helps us here- maybe
  this should be an and instead of or?).

  Thanks,

  Kevin

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1459464/+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 2019078] [NEW] cleanup up dangling volume attachment

[Amit Uniyal]

Public bug reported:

A live migration failure created a scenario when the volume is deleted
from the system but its BDM is present in Nova DB.


Nova does not support deleting a volume that is attached to a VM.

On rebooting Nova failed to find the volume listed as attached in DB and
the instance ended up going to an error state.

In order to remove the volume that has already been deleted, operator
has to shutdown Vm and then delete the bdm from DB manually.


Environment
===
Train release


Logs & Configs
==
https://paste.opendev.org/show/bnGkFSsConbbLpynbdfp/


@gibi filed a blueprint for same 
https://blueprints.launchpad.net/nova/+spec/nova-manage-cleanup-dangling-volume-attachments

** Affects: nova
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/2019078

Title:
  cleanup up dangling volume attachment

Status in OpenStack Compute (nova):
  New

Bug description:
  A live migration failure created a scenario when the volume is deleted
  from the system but its BDM is present in Nova DB.

  
  Nova does not support deleting a volume that is attached to a VM.

  On rebooting Nova failed to find the volume listed as attached in DB
  and the instance ended up going to an error state.

  In order to remove the volume that has already been deleted, operator
  has to shutdown Vm and then delete the bdm from DB manually.

  
  Environment
  ===
  Train release

  
  Logs & Configs
  ==
  https://paste.opendev.org/show/bnGkFSsConbbLpynbdfp/

  
  @gibi filed a blueprint for same 
https://blueprints.launchpad.net/nova/+spec/nova-manage-cleanup-dangling-volume-attachments

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/2019078/+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 1455651] Re: re-enable test_cli in package builds

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2548

** Bug watch added: github.com/canonical/cloud-init/issues #2548
   https://github.com/canonical/cloud-init/issues/2548

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  re-enable test_cli in package builds

Status in cloud-init:
  Expired

Bug description:
  revision 1106 made tests in test_cli.py get skipped if there was no
  bin/cloud-init.

  that was because package builds would fail, like:

  ==
  ERROR: test_no_arguments_shows_error_message (unittests.test_cli.TestCLI)
  --
  Traceback (most recent call last):
File 
"/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.4/build/tests/unittests/test_cli.py", line 
46, in test_no_arguments_shows_error_message
  self._call_main()
File 
"/«PKGBUILDDIR»/.pybuild/pythonX.Y_3.4/build/tests/unittests/test_cli.py", line 
28, in _call_main
  'cli', open('bin/cloud-init'), '', ('', 'r', imp.PY_SOURCE))
  FileNotFoundError: [Errno 2] No such file or directory: 'bin/cloud-init'

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1455651/+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 1440265] Re: CloudStack sshkey reset

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2537

** Bug watch added: github.com/canonical/cloud-init/issues #2537
   https://github.com/canonical/cloud-init/issues/2537

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  CloudStack sshkey reset

Status in cloud-init:
  Expired
Status in cloud-init package in Ubuntu:
  Confirmed

Bug description:
  CloudStack provide capability to reset SSH keys for an existing VM
  with the API: resetSSHKeyForVirtualMachine [1]

  creating an Instance with SSHkey currently work with cloud-init. But,
  CloudStack have the capability to reset it, the VM must be shutdown,
  sshkey replaced then the vm restart, current cloud-init does not
  update the user sshkey using the new one available from the dhcp
  server.

  tested with cloud-init-0.7.7

  current method to mitigate this behavior is to use cloudstack scripts
  into the /var/lib/cloud/scripts/per-boot/  which does not benefit from
  cloud-init configuration capabilities.

  
  [1] 
http://cloudstack.apache.org/docs/api/apidocs-4.5/root_admin/resetSSHKeyForVirtualMachine.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1440265/+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 1443689] Re: Add a pure sfdisk resizer for cc_growpart

[James Falcon]

Tracked in Github Issues as https://github.com/canonical/cloud-
init/issues/2538

** Bug watch added: github.com/canonical/cloud-init/issues #2538
   https://github.com/canonical/cloud-init/issues/2538

** Changed in: cloud-init
   Status: Confirmed => Expired

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

Title:
  Add a pure sfdisk resizer for cc_growpart

Status in cloud-init:
  Expired

Bug description:
  The 'growpart' tool itself is actually replicating functionality
  sfdisk already has. When editing a partition, the size can be
  specified as '+' to indicate 'make this partition as large as
  possible'.

  sfdisk < 2.26 would fail when attempting to do this on a GPT-labelled
  disk (which is a reasonable enough justification for growpart's
  existence, I guess), but from 2.26 onwards it works (in my testing,
  anyway) for both MBR- and GPT-labelled disks.

  I've written a patch that introduces a new resizer (using
  cc_growpart's existing support for multiple resizer backends) which
  uses sfdisk directly instead of growpart. The new resizer is only
  considered to be 'available' if the util-linux version appears to be
  2.26 or higher.

  The effect should be that native sfdisk resizing will be used if util-
  linux is new enough, but growpart will be used if it's older.

  I would envisage that at some point we could decide that everyone's
  had enough of a chance to update util-linux and growpart could shuffle
  off this mortal coil, and the code could probably then be
  substantially simplified.

  I'm going to try and tag a launchpad branch which has the patch
  applied, hope I get it right, my first time trying this...

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1443689/+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