[Yahoo-eng-team] [Bug 1819453] Re: keystone-ldap TypeError: cannot concatenate 'str' and 'NoneType' object
Ubuntu 18.10 (Cosmic Cuttlefish) has reached end of life, so this bug
will not be fixed for that specific release.
** Changed in: keystone (Ubuntu Cosmic)
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1819453
Title:
keystone-ldap TypeError: cannot concatenate 'str' and 'NoneType'
object
Status in Ubuntu Cloud Archive:
New
Status in Ubuntu Cloud Archive mitaka series:
New
Status in Ubuntu Cloud Archive ocata series:
New
Status in Ubuntu Cloud Archive pike series:
New
Status in Ubuntu Cloud Archive queens series:
New
Status in Ubuntu Cloud Archive rocky series:
New
Status in Ubuntu Cloud Archive stein series:
New
Status in OpenStack Identity (keystone):
Incomplete
Status in keystone package in Ubuntu:
New
Status in keystone source package in Xenial:
New
Status in keystone source package in Bionic:
New
Status in keystone source package in Cosmic:
Won't Fix
Status in keystone source package in Disco:
Won't Fix
Bug description:
Proposed action:
=
Key / value failed check error.
Should check key exists and warn user of bad users / continue
Bug presented by:
=
openstack user list --domain customerdata
cannot concatenate 'str' and 'NoneType' objects (HTTP 400) (Request-ID:
req-cc0e225d-d033-4dfa-aff8-7311389d4f58)
Trace:
==
(keystone.common.wsgi): 2019-03-11 12:30:47,154 ERROR cannot concatenate
'str' and 'NoneType' objects
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/keystone/common/wsgi.py", line 228,
in __call__
result = method(req, **params)
File "/usr/lib/python2.7/dist-packages/keystone/common/controller.py", line
235, in wrapper
return f(self, request, filters, **kwargs)
File "/usr/lib/python2.7/dist-packages/keystone/identity/controllers.py",
line 233, in list_users
return UserV3.wrap_collection(request.context_dict, refs, hints=hints)
File "/usr/lib/python2.7/dist-packages/keystone/common/controller.py", line
499, in wrap_collection
cls.wrap_member(context, ref)
File "/usr/lib/python2.7/dist-packages/keystone/common/controller.py", line
468, in wrap_member
cls._add_self_referential_link(context, ref)
File "/usr/lib/python2.7/dist-packages/keystone/common/controller.py", line
464, in _add_self_referential_link
ref['links']['self'] = cls.base_url(context) + '/' + ref['id']
TypeError: cannot concatenate 'str' and 'NoneType' objects
Offending Data:
===
@ line 233 i put LOG.debug( pprint.pformat( refs ) )
grep -b 2 "'id': None," /varlog/keystone/keystone.log
{'domain_id': u'8ce102de5ac644288f61838f5e0f46e7',
'email': u'customerd...@cusomter.com',
'id': None,
--
{'domain_id': u'8ce102de5ac644288f61838f5e0f46e7',
'email': u'customerd...@cusomter.com',
'id': None,
--
{'domain_id': u'8ce102de5ac644288f61838f5e0f46e7',
'email': u'customerd...@cusomter.com',
'id': None,
Platform:
=
cat /etc/*-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.5 LTS"
NAME="Ubuntu"
VERSION="16.04.5 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.5 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/;
SUPPORT_URL="http://help.ubuntu.com/;
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/;
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial
verions:
dpkg --list | grep keystone
ii keystone 2:11.0.3-0ubuntu1~cloud0
all OpenStack identity service - Daemons
ii python-keystone 2:11.0.3-0ubuntu1~cloud0
all OpenStack identity service - Python library
ii python-keystoneauth1 2.18.0-0ubuntu2~cloud0
all authentication library for OpenStack Identity - Python 2.7
ii python-keystoneclient1:3.10.0-0ubuntu1~cloud0
all client library for the OpenStack Keystone API - Python 2.x
ii python-keystonemiddleware4.14.0-0ubuntu1.2~cloud0
all Middleware for OpenStack Identity (Keystone) - Python 2.x
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1819453/+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 1767166] Re: IBMCloud datasource does not recognize provisioning in debug mode.
Ubuntu 18.10 (Cosmic Cuttlefish) has reached end of life, so this bug
will not be fixed for that specific release.
** Changed in: cloud-init (Ubuntu Cosmic)
Status: Fix Committed => Won't Fix
--
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/1767166
Title:
IBMCloud datasource does not recognize provisioning in debug mode.
Status in cloud-init:
Fix Released
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Xenial:
Fix Released
Status in cloud-init source package in Artful:
Fix Released
Status in cloud-init source package in Bionic:
Fix Released
Status in cloud-init source package in Cosmic:
Won't Fix
Bug description:
=== Begin SRU Template ===
[Impact]
Cloud-init is disabled in the provisioning state. If provisioning
artifacts are left around after debug mode, cloud-init remains disabled
and doesn't properly configure the instance.
This issue only affects images that are being tested by IBM before official
publication. Once officially published, the images will have a 'production'
tag, and bug does not reproduce.
As such, it is believed that a regular end user is not really able to
produce.
[Test Case]
cat > sethostname.yaml < /run/runcmd-ran.txt']
EOF
VM_IP=`launch-softlayer --pubkey-file ~/.ssh/id_rsa.pub -u
sethostname.yaml -i os:xenial | awk '/primary ip/{printf "root@%s",
$3}'`
ssh root@$VM_IP -- dpkg-query --show cloud-init;
ssh root@$VM_IP -- cloud-init status --long;
ssh root@$VM_IP -- cloud-init analyze show;
ssh root@$VM_IP -- sh -c '
mirror=http://archive.ubuntu.com/ubuntu
echo deb $mirror $(lsb_release -sc)-proposed main | tee
/etc/apt/sources.list.d/proposed.list
apt-get update -q
apt-get install -qy cloud-init';
ssh root@$VM_IP -- DEBUG_LEVEL=2 DI_LOG=stderr
/usr/lib/cloud-init/ds-identify --force 2>&1 | grep provision
ssh root@$VM_IP -- cloud-init clean --logs --reboot;
ssh root@$VM_IP -- egrep 'provisioning|swinstall' /var/log/cloud-init.log
ssh root@$VM_IP -- grep provision /run/cloud-init/ds-identify.log
[Regression Potential]
Regression will still be limited to softlayer instances as code changes are
limited to softlayer datasource detection in ds-identify and
DataSourceIBMCloud.
[Other Info]
Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=44a44ae18
This bug is currently fixed in bionic-proposed version
(18.2-27-g6ef92c98-0ubuntu1~18.04.1) and
cloud-init trunk, so first upload to ubuntu 'cc' will have it fixed.
=== End SRU Template ===
When IBMCloud deploys from a template, artifacts from the
provisioning stage are normally cleaned up. Cloud-init relied'
on that behavior to determine the provisioning boot from the subsequent
post-provisioning boot.
However, when testing, the provisioning stage will leave artifacts
in place (/root/provisioningConfiguration.cfg). This caused cloud-init
to permenantly believe that it was in the provisioning stage.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1767166/+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 1799779] Re: LXD module installs the wrong ZFS package if it's missing
Ubuntu 18.10 (Cosmic Cuttlefish) has reached end of life, so this bug will not be fixed for that specific release. ** Changed in: cloud-init (Ubuntu Cosmic) Status: Fix Committed => Won't Fix -- 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/1799779 Title: LXD module installs the wrong ZFS package if it's missing Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Status in cloud-init source package in Bionic: Fix Committed Status in cloud-init source package in Cosmic: Won't Fix Status in cloud-init source package in Disco: Fix Released Bug description: When using the LXD module cloud-init will attempt to install ZFS if it does not exist on the target system. However instead of installing the `zfsutils-linux` package it attempts to install `zfs` resulting in an error. This was captured from a MAAS deployed server however the bug is platform agnostic. ### ubuntu@node10ob68:~$ cloud-init --version /usr/bin/cloud-init 18.3-9-g2e62cb8a-0ubuntu1~18.04.2 ### less /var/log/cloud-init.log ... 2018-10-24 19:23:54,255 - util.py[DEBUG]: apt-install [eatmydata apt-get --option=Dpkg::Options::=--force-confold --option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet install zfs] took 0.302 seconds 2018-10-24 19:23:54,255 - cc_lxd.py[WARNING]: failed to install packages ['zfs']: Unexpected error while running command. Command: ['eatmydata', 'apt-get', '--option=Dpkg::Options::=--force-confold', '--option=Dpkg::options::=--force-unsafe-io', '--assume-yes', '--quiet', 'install', 'zfs'] Exit code: 100 ... To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1799779/+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 1851438] Re: cloud-init disk_setup fails to partition disk for Ubuntu18
Ubuntu 19.10 (Eoan Ermine) has reached end of life, so this bug will not be fixed for that specific release. ** Changed in: util-linux (Ubuntu Eoan) Status: New => Won't Fix -- 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/1851438 Title: cloud-init disk_setup fails to partition disk for Ubuntu18 Status in cloud-init: Fix Released Status in util-linux package in Ubuntu: New Status in util-linux source package in Xenial: New Status in util-linux source package in Bionic: New Status in util-linux source package in Eoan: Won't Fix Status in util-linux source package in Focal: New Bug description: Pasting disk_setup for cloud-config: disk_setup: /dev/xvde: layout: True overwrite: False type: mbr fs_setup: -device: /dev/xvde filesystem: ext4 label: data overwrite: false partition: auto I want to attach and mount a /data disk on the VM using cloud-init so I just want to single partition 100% of the disk. Error while running the sfdisk command for partitioning the disk (please see attached file). OS: Ubuntu18 How I repro-ed it outside cloud-init environment: 1. Open XenCenter, add a new disk, say /dev/xvdc 2. Run `/sbin/sfdisk --Linux --unit=S --force /dev/xvdc` and specify start sector as 0. Because from the cloud-init logs and source code, I figured that it was picking start sector as 0. Save it and see the error. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1851438/+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 1863021] Re: [SRU] eventlet monkey patch results in assert len(_active) == 1 AssertionError
** No longer affects: swift (Ubuntu Groovy) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1863021 Title: [SRU] eventlet monkey patch results in assert len(_active) == 1 AssertionError Status in Cinder: Fix Released Status in Designate: Fix Released Status in Glance: Fix Released Status in OpenStack Shared File Systems Service (Manila): Fix Released Status in masakari: Fix Released Status in Mistral: Fix Released Status in Murano: Fix Released Status in BaGPipe: Fix Released Status in networking-hyperv: Fix Released Status in networking-l2gw: Fix Released Status in Mellanox backend integration with Neutron (networking-mlnx): Fix Released Status in networking-sfc: Fix Released Status in neutron: Fix Released Status in OpenStack Compute (nova): Fix Released Status in oslo.service: Fix Released Status in senlin: Fix Released Status in OpenStack Object Storage (swift): In Progress Status in OpenStack DBaaS (Trove): Fix Released Status in watcher: Fix Released Status in barbican package in Ubuntu: Fix Released Status in cinder package in Ubuntu: Fix Released Status in designate package in Ubuntu: Fix Released Status in glance package in Ubuntu: Fix Released Status in heat package in Ubuntu: Fix Released Status in ironic package in Ubuntu: Fix Released Status in ironic-inspector package in Ubuntu: Fix Released Status in magnum package in Ubuntu: Fix Released Status in manila package in Ubuntu: Fix Released Status in masakari package in Ubuntu: Fix Released Status in mistral package in Ubuntu: Fix Released Status in murano package in Ubuntu: Fix Released Status in murano-agent package in Ubuntu: Fix Released Status in networking-bagpipe package in Ubuntu: Fix Released Status in networking-hyperv package in Ubuntu: Fix Released Status in networking-l2gw package in Ubuntu: Fix Released Status in networking-mlnx package in Ubuntu: Fix Released Status in networking-sfc package in Ubuntu: Fix Released Status in neutron package in Ubuntu: Fix Released Status in neutron-dynamic-routing package in Ubuntu: Fix Released Status in nova package in Ubuntu: Fix Released Status in openstack-trove package in Ubuntu: Fix Released Status in python-os-ken package in Ubuntu: Fix Released Status in python-oslo.service package in Ubuntu: Fix Released Status in sahara package in Ubuntu: Fix Released Status in senlin package in Ubuntu: Fix Released Status in swift package in Ubuntu: Triaged Status in watcher package in Ubuntu: Fix Released Status in barbican source package in Focal: Fix Released Status in cinder source package in Focal: Fix Released Status in designate source package in Focal: Fix Released Status in glance source package in Focal: Fix Released Status in heat source package in Focal: Fix Released Status in ironic source package in Focal: Fix Released Status in ironic-inspector source package in Focal: Fix Released Status in magnum source package in Focal: Fix Released Status in manila source package in Focal: Fix Released Status in masakari source package in Focal: Fix Released Status in mistral source package in Focal: Fix Released Status in murano source package in Focal: Fix Released Status in murano-agent source package in Focal: Fix Released Status in networking-bagpipe source package in Focal: Fix Released Status in networking-hyperv source package in Focal: Fix Released Status in networking-l2gw source package in Focal: Fix Released Status in networking-mlnx source package in Focal: Fix Released Status in networking-sfc source package in Focal: Fix Released Status in neutron source package in Focal: Fix Released Status in neutron-dynamic-routing source package in Focal: Fix Released Status in nova source package in Focal: Fix Released Status in openstack-trove source package in Focal: Fix Released Status in python-os-ken source package in Focal: Fix Released Status in python-oslo.service source package in Focal: Fix Released Status in sahara source package in Focal: Fix Released Status in senlin source package in Focal: Fix Released Status in swift source package in Focal: Triaged Status in watcher source package in Focal: Fix Released Status in barbican source package in Groovy: Fix Released Status in cinder source package in Groovy: Fix Released Status in designate source package in Groovy: Fix Released Status in glance source package in Groovy: Fix Released Status in heat source package in Groovy: Fix Released Status in ironic source package in Groovy: Fix Released Status in ironic-inspector source package in Groovy: Fix Released Status in magnum source package in Groovy: Fix Released Status in manila source package in Groovy: Fix Released Status in masakari source package in Groovy: Fix Released Status in mistral source package
[Yahoo-eng-team] [Bug 1951586] Re: Need option to specify wifi regulatory domain
Ubuntu 23.10 (Mantic Minotaur) has reached end of life, so this bug will not be fixed for that specific release. ** Changed in: network-manager (Ubuntu Mantic) Status: Confirmed => Won't Fix -- 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/1951586 Title: Need option to specify wifi regulatory domain Status in cloud-init: Invalid Status in Netplan: Fix Released Status in NetworkManager: New Status in netplan.io package in Ubuntu: Fix Released Status in network-manager package in Ubuntu: Confirmed Status in netplan.io source package in Jammy: Fix Released Status in network-manager source package in Jammy: Confirmed Status in netplan.io source package in Kinetic: Fix Released Status in network-manager source package in Kinetic: Won't Fix Status in netplan.io source package in Lunar: Fix Released Status in network-manager source package in Lunar: Won't Fix Status in netplan.io source package in Mantic: Fix Released Status in network-manager source package in Mantic: Won't Fix Status in netplan.io source package in Noble: Fix Released Status in network-manager source package in Noble: Confirmed Bug description: It would be nice if netplan offered an option to specify the wifi regulatory domain (country code). For devices such as the Raspberry Pi you are currently advertising that users can simply setup Ubuntu Server headless by putting the wifi configuration details in cloudinit/netplan's "network-config" on the FAT partition of the SD card: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#3-wifi-or-ethernet But an option to set the wifi country code there does not seem to exist, so may not work. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1951586/+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 2015090] Re: neutron.agent.dhcp.agent TypeError: 'bool' object is not subscriptable
Ubuntu 23.04 (Lunar Lobster) has reached end of life, so this bug will not be fixed for that specific release. ** Changed in: neutron (Ubuntu Lunar) Status: Fix Committed => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2015090 Title: neutron.agent.dhcp.agent TypeError: 'bool' object is not subscriptable Status in OpenStack Neutron Open vSwitch Charm: Invalid Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive antelope series: Fix Committed Status in neutron: Fix Released Status in neutron package in Ubuntu: Fix Released Status in neutron source package in Lunar: Won't Fix Bug description: In a fresh environment running Antelope (on top of Ubuntu 22.04), with a DVR configuration (neutron-dhcp-agent and neutron-metadata-agent running on compute nodes) the metadata service is not available instances, this is an environment using neutron-openvswitch environment (not OVN), when looking into the logs the stacktrace below indicates an unexpected data type. [Stacktrace] 2023-03-31 19:35:06.093 58625 DEBUG neutron.agent.dhcp.agent [-] Calling driver for network: 6d246d86-11b5-4d5f-aa9c-c2bcbcc28b62/seg=None action: get_metadata_bind_interface _call_driver /usr/lib/python3/dist-packages/neutron/agent/dhcp/agent.py:242 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent [-] 'bool' object is not subscriptable: TypeError: 'bool' object is not subscriptable 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent Traceback (most recent call last): 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent File "/usr/lib/python3/dist-packages/neutron/common/utils.py", line 182, in call 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent return func(*args, **kwargs) 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent File "/usr/lib/python3/dist-packages/neutron/agent/dhcp/agent.py", line 434, in safe_configure_dhcp_for_network 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent self.configure_dhcp_for_network(network) 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent File "/usr/lib/python3/dist-packages/osprofiler/profiler.py", line 159, in wrapper 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent result = f(*args, **kwargs) 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent File "/usr/lib/python3/dist-packages/neutron/agent/dhcp/agent.py", line 447, in configure_dhcp_for_network 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent self.update_isolated_metadata_proxy(network) 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent File "/usr/lib/python3/dist-packages/osprofiler/profiler.py", line 159, in wrapper 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent result = f(*args, **kwargs) 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent File "/usr/lib/python3/dist-packages/neutron/agent/dhcp/agent.py", line 763, in update_isolated_metadata_proxy 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent self.enable_isolated_metadata_proxy(network) 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent File "/usr/lib/python3/dist-packages/osprofiler/profiler.py", line 159, in wrapper 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent result = f(*args, **kwargs) 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent File "/usr/lib/python3/dist-packages/neutron/agent/dhcp/agent.py", line 819, in enable_isolated_metadata_proxy 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent metadata_driver.MetadataDriver.spawn_monitored_metadata_proxy( 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent File "/usr/lib/python3/dist-packages/neutron/agent/metadata/driver.py", line 244, in spawn_monitored_metadata_proxy 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent ip_lib.IpAddrCommand( 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent File "/usr/lib/python3/dist-packages/neutron/agent/linux/ip_lib.py", line 609, in wait_until_address_ready 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent common_utils.wait_until_true( 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent File "/usr/lib/python3/dist-packages/neutron/common/utils.py", line 744, in wait_until_true 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent while not predicate(): 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent File "/usr/lib/python3/dist-packages/neutron/agent/linux/ip_lib.py", line 594, in is_address_ready 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent addr_info = self.list(to=address)[0] 2023-03-31 19:35:06.095 58625 ERROR neutron.agent.dhcp.agent File
[Yahoo-eng-team] [Bug 1931696] Re: ovs offload broken from neutron 16.3.0 onwards
Ubuntu 21.10 (Impish Indri) has reached end of life, so this bug will not be fixed for that specific release. ** Changed in: neutron (Ubuntu Impish) Status: New => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1931696 Title: ovs offload broken from neutron 16.3.0 onwards Status in OpenStack Neutron Open vSwitch Charm: Fix Released Status in Ubuntu Cloud Archive: New Status in Ubuntu Cloud Archive queens series: New Status in Ubuntu Cloud Archive rocky series: New Status in Ubuntu Cloud Archive stein series: New Status in Ubuntu Cloud Archive train series: New Status in Ubuntu Cloud Archive ussuri series: New Status in Ubuntu Cloud Archive victoria series: New Status in Ubuntu Cloud Archive wallaby series: New Status in Ubuntu Cloud Archive xena series: New Status in neutron: In Progress Status in neutron package in Ubuntu: New Status in neutron source package in Bionic: New Status in neutron source package in Focal: New Status in neutron source package in Hirsute: Won't Fix Status in neutron source package in Impish: Won't Fix Bug description: The 16.3.0 release of neutron introduced patch [1] which breaks the use of non-offloaded ports on a node that has ovs offload enabled. Our setup is as follows: * single tenant network (vxlan) * two vms with one port each where one port has offload enabled and the other does not * from non-offloaded vm I am unable to ping my gateway and I see the following: # grep dropping /var/log/openvswitch/ovs-vswitchd.log 2021-06-11T09:37:16.271Z|00553|ofproto_dpif_xlate(handler150)|WARN|dropping VLAN 1 tagged packet received on port qr-446b3a35-d0 configured as VLAN 1 access port on bridge br-int while processing recirc_id=0x1a,ct_state=est|rpl|trk,ct_zone=1,ct_nw_src=172.16.0.126,ct_nw_dst=172.16.0.1,ct_nw_proto=1,ct_tp_src=8,ct_tp_dst=0,eth,icmp,in_port=3,vlan_tci=0x,dl_src=fa:16:3e:66:e8:2f,dl_dst=fa:16:3e:3c:50:c1,nw_src=172.16.0.1,nw_dst=172.16.0.126,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=0,icmp_code=0 which is from [2]. The patch [1] is configurable by settig explicitly_egress_direct=True in /etc/neutron/plugins/ml2/openvswitch_agent.ini and that has fixed connectivity for me so I am going to submit a patch to make this configurable via the charm. [1] https://opendev.org/openstack/neutron/commit/d865165cc8cbd50a3e79a25065ef9a310d7c9396 [2] https://github.com/openvswitch/ovs/blob/branch-2.13/ofproto/ofproto-dpif-xlate.c#L2220 To manage notifications about this bug go to: https://bugs.launchpad.net/charm-neutron-openvswitch/+bug/1931696/+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 1965297] Re: l3ha don't set backup qg ports down
Ubuntu 21.10 (Impish Indri) has reached end of life, so this bug will not be fixed for that specific release. ** Changed in: neutron (Ubuntu Impish) Status: Fix Committed => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1965297 Title: l3ha don't set backup qg ports down Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive ussuri series: Fix Committed Status in Ubuntu Cloud Archive victoria series: Fix Committed Status in Ubuntu Cloud Archive wallaby series: Fix Committed Status in Ubuntu Cloud Archive xena series: Fix Released Status in Ubuntu Cloud Archive yoga series: Fix Released Status in Ubuntu Cloud Archive zed series: Fix Released Status in neutron: Fix Released Status in neutron package in Ubuntu: Fix Released Status in neutron source package in Focal: Fix Committed Status in neutron source package in Impish: Won't Fix Status in neutron source package in Jammy: Fix Released Status in neutron source package in Kinetic: Fix Released Bug description: The history to this request is as follows; bug 1916024 fixed an issue that subsequently had to be reverted due to a regression that it introduced (see bug 1927868) and the original issue can once again present itself in that keepalived is unable to send GARP on the qg port until the port is marked as UP by neutron which in loaded environments can sometimes take longer than keepalived will wait (e.g. when an l3-agent is restarted on a host that has hundreds of routers). The reason why qg- ports are marked as DOWN is because of the patch landed as part of bug 1859832 and as I understand it there is now consensus from upstream [1] to revert that patch as well and a better solution is needed to fix that particular issue. I have not found a bug open yet for the revert hence why I am opening this one. [1] https://meetings.opendev.org/meetings/neutron_drivers/2022/neutron_drivers.2022-03-04-14.03.log.txt [Impact] Please see LP bug description for full details but in short, this patch is a revert of a patch that has show instability in the field for users of Neutron L3HA. [Test Plan] * Deploy Openstack with Neutron L3 HA enabled * Create a number of HA routers * Check all qrouter namespaces and ensure that the qg- port is UP in all [Regression Potential] Since the original patch was intended to address issues with MLDv2 it is possible that reverting it will re-introduce those issues and a new patch will need to be proposed to address that. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1965297/+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 1931696] Re: ovs offload broken from neutron 16.3.0 onwards
The Hirsute Hippo has reached End of Life, so this bug will not be fixed for that release. ** Changed in: neutron (Ubuntu Hirsute) Status: New => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1931696 Title: ovs offload broken from neutron 16.3.0 onwards Status in OpenStack Neutron Open vSwitch Charm: Fix Released Status in Ubuntu Cloud Archive: New Status in Ubuntu Cloud Archive queens series: New Status in Ubuntu Cloud Archive rocky series: New Status in Ubuntu Cloud Archive stein series: New Status in Ubuntu Cloud Archive train series: New Status in Ubuntu Cloud Archive ussuri series: New Status in Ubuntu Cloud Archive victoria series: New Status in Ubuntu Cloud Archive wallaby series: New Status in Ubuntu Cloud Archive xena series: New Status in neutron: In Progress Status in neutron package in Ubuntu: New Status in neutron source package in Bionic: New Status in neutron source package in Focal: New Status in neutron source package in Hirsute: Won't Fix Status in neutron source package in Impish: New Bug description: The 16.3.0 release of neutron introduced patch [1] which breaks the use of non-offloaded ports on a node that has ovs offload enabled. Our setup is as follows: * single tenant network (vxlan) * two vms with one port each where one port has offload enabled and the other does not * from non-offloaded vm I am unable to ping my gateway and I see the following: # grep dropping /var/log/openvswitch/ovs-vswitchd.log 2021-06-11T09:37:16.271Z|00553|ofproto_dpif_xlate(handler150)|WARN|dropping VLAN 1 tagged packet received on port qr-446b3a35-d0 configured as VLAN 1 access port on bridge br-int while processing recirc_id=0x1a,ct_state=est|rpl|trk,ct_zone=1,ct_nw_src=172.16.0.126,ct_nw_dst=172.16.0.1,ct_nw_proto=1,ct_tp_src=8,ct_tp_dst=0,eth,icmp,in_port=3,vlan_tci=0x,dl_src=fa:16:3e:66:e8:2f,dl_dst=fa:16:3e:3c:50:c1,nw_src=172.16.0.1,nw_dst=172.16.0.126,nw_tos=0,nw_ecn=0,nw_ttl=64,icmp_type=0,icmp_code=0 which is from [2]. The patch [1] is configurable by settig explicitly_egress_direct=True in /etc/neutron/plugins/ml2/openvswitch_agent.ini and that has fixed connectivity for me so I am going to submit a patch to make this configurable via the charm. [1] https://opendev.org/openstack/neutron/commit/d865165cc8cbd50a3e79a25065ef9a310d7c9396 [2] https://github.com/openvswitch/ovs/blob/branch-2.13/ofproto/ofproto-dpif-xlate.c#L2220 To manage notifications about this bug go to: https://bugs.launchpad.net/charm-neutron-openvswitch/+bug/1931696/+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 1939733] Re: [OSSA-2021-005] Arbitrary dnsmasq reconfiguration via extra_dhcp_opts (CVE-2021-40085)
The Hirsute Hippo has reached End of Life, so this bug will not be fixed
for that release.
** Changed in: neutron (Ubuntu Hirsute)
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1939733
Title:
[OSSA-2021-005] Arbitrary dnsmasq reconfiguration via extra_dhcp_opts
(CVE-2021-40085)
Status in Ubuntu Cloud Archive:
New
Status in Ubuntu Cloud Archive queens series:
Fix Committed
Status in Ubuntu Cloud Archive rocky series:
Fix Committed
Status in Ubuntu Cloud Archive stein series:
Fix Committed
Status in Ubuntu Cloud Archive train series:
Fix Committed
Status in Ubuntu Cloud Archive ussuri series:
Fix Committed
Status in Ubuntu Cloud Archive victoria series:
Fix Committed
Status in Ubuntu Cloud Archive wallaby series:
Fix Committed
Status in Ubuntu Cloud Archive xena series:
New
Status in neutron:
Fix Released
Status in OpenStack Security Advisory:
Fix Released
Status in neutron package in Ubuntu:
New
Status in neutron source package in Bionic:
New
Status in neutron source package in Focal:
New
Status in neutron source package in Hirsute:
Won't Fix
Status in neutron source package in Impish:
New
Bug description:
Application doesnt check the input values for extra_dhcp_opts port
parameter allowing user to use a newline character. The values from
extra_dhcp_opts are used in rendering of opts file which is passed to
dnsmasq as a dhcp-optsfile. Considering this, an attacker can inject
any options to that file.
The main direct impact in my opinion is that attacker can push
arbitrary dhcp options to another instances connected to the same
network. And due to we are able to modify our own port connected to
external network, it is possible to push dhcp options to the instances
of another tennants using the same external network.
If we go further, there is an known buffer overflow vulnerability in
dnsmasq
(https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=7d04e17444793a840f98a0283968b96502b112dc)
which was not considered as a security issue due to attacker cannot
control dhcp opts in most cases and therefore this vulnerability is
still exists in most distributives (e.g Ubuntu 20.04.1). In our case
dhcp opts is exactly what attacker can modify, so we can trigger
buffer overflow there. I even managed to write an exploit which lead
to a remote code execution using this buffer overflow vulnerability.
Here the payload to crash dnsmasq as a proof of concept:
```
PUT /v2.0/ports/9db67e0f-537c-494a-a655-c8a0c518d57e HTTP/1.1
Host: openstack
X-Auth-Token: TOKEN
Content-Type: application/json
Content-Length: 170
{"port":{
"extra_dhcp_opts":[{"opt_name":"zzz",
"opt_value":"xxx\n128,aa:bb\n120,aa.cc\n128,:"
}]}}
```
Tested on ocata, train and victoria versions.
Vulnerability was found by Pavel Toporkov
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1939733/+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 1951586] Re: Need option to specify wifi regulatory domain
** Also affects: netplan.io (Ubuntu) Importance: Undecided Status: New ** Tags removed: rls-jj-incoming ** Also affects: netplan.io (Ubuntu Jammy) Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1951586 Title: Need option to specify wifi regulatory domain Status in cloud-init: Invalid Status in netplan: New Status in netplan.io package in Ubuntu: New Status in netplan.io source package in Jammy: New Bug description: It would be nice if netplan offered an option to specify the wifi regulatory domain (country code). For devices such as the Raspberry Pi you are currently advertising that users can simply setup Ubuntu Server headless by putting the wifi configuration details in cloudinit/netplan's "network-config" on the FAT partition of the SD card: https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi#3-wifi-or-ethernet But an option to set the wifi country code there does not seem to exist, so may not work. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1951586/+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 1915480] Re: DeviceManager's fill_dhcp_udp_checksums assumes IPv6 available
16.4.1 is included in focal-updates and hirsute has 18.0 so I'm setting this to Fix Released. $ rmadison neutron neutron | 1:2014.1-0ubuntu1 | trusty | source neutron | 1:2014.1.3-0ubuntu1.1 | trusty-security | source neutron | 1:2014.1.5-0ubuntu8 | trusty-updates | source neutron | 2:8.0.0-0ubuntu1 | xenial | source neutron | 2:8.4.0-0ubuntu7.4| xenial-security | source neutron | 2:8.4.0-0ubuntu7.5| xenial-updates | source neutron | 2:12.0.1-0ubuntu1 | bionic | source neutron | 2:12.1.1-0ubuntu8 | bionic-updates | source neutron | 2:16.0.0~b3~git2020041516.5f42488a9a-0ubuntu2 | focal | source neutron | 2:16.4.1-0ubuntu2 | focal-updates | source neutron | 2:18.0.0-0ubuntu2 | hirsute | source neutron | 2:18.1.1-0ubuntu2 | hirsute-updates | source neutron | 2:19.0.0-0ubuntu1 | impish | source neutron | 2:19.0.0-0ubuntu1 | jammy | source ** Changed in: neutron (Ubuntu) Status: New => Fix Released ** Changed in: neutron (Ubuntu Focal) Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1915480 Title: DeviceManager's fill_dhcp_udp_checksums assumes IPv6 available Status in Ubuntu Cloud Archive: New Status in Ubuntu Cloud Archive ussuri series: New Status in Ubuntu Cloud Archive victoria series: New Status in neutron: Fix Committed Status in neutron package in Ubuntu: Fix Released Status in neutron source package in Focal: Fix Released Bug description: The following code in DeviceManager's fill_dhcp_udp_checksums assumes IPv6 is always enabled: iptables_mgr = iptables_manager.IptablesManager(use_ipv6=True, namespace=namespace) When iptables_mgr.apply() is later called, an attempt to add the UDP checksum rule for DHCP is done via iptables-save/iptables-restore and if IPv6 has been disabled on a hypervisor (eg, by setting `ipv6.disable=1` on the kernel command line) then an many-line error occurs in the DHCP agent logfile. There should be a way of telling the agent that IPv6 is disabled and as such, it should ignore trying to set up the UDP checksum rule for IPv6. This can be easily achieved given that IptablesManager already has support for disabling it. We've seen this on Rocky on Ubuntu Bionic but it appears the issue still exists on the master branch. = Ubuntu SRU details: [Impact] See above [Test Plan] Disable IPv6 on a hypervisor. sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1 sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1 sudo sysctl -w net.ipv6.conf.lo.disable_ipv6=1 Deploy Openstack Ussuri or Victoria with one compute node, using the hypervisor which has IPv6 disabled as a neutron gateway. Create a network which has a subnetwork with DHCP enabled. Eg: openstack network create net1 openstack subnet create subnet1 --network net1 --subnet-range 192.0.2.0/24 --dhcp Search the `/var/log/neutron/neutron-dhcp-agent.log` (with debug log enabled) and check if there are any `ip6tables-restore` commands. Eg: sudo grep ip6tables-restore /var/log/neutron/neutron-dhcp-agent.log [Where problems could occur] Users which were relying on the setting to always be true could be affected. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1915480/+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 1946003] Re: hotplug causing cloud-init to spike CPU usage
** Also affects: cloud-init (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1946003 Title: hotplug causing cloud-init to spike CPU usage Status in cloud-init: Triaged Status in cloud-init package in Ubuntu: New Bug description: In 21.3, we added udev rules to enable the cloud-init hotplug functionality. If a new device is detected, we call into cloud-init to see if hotplug is supported/enabled, then proceed accordingly based on the results. There are cloud users that are creating and disposing docker containers at a very high rate. This causes many virtual ethernet adapters to be created and disposed. This is triggering cloud-init events at a high volume, consuming significant CPU. Even with the hotplug functionality being disabled, the act of checking if hotplug is enabled is causing the spikes in CPU. The path taken is: https://github.com/canonical/cloud-init/blob/main/udev/10-cloud-init-hook-hotplug.rules to https://github.com/canonical/cloud-init/blob/main/tools/hook-hotplug to https://github.com/canonical/cloud-init/blob/main/cloudinit/cmd/devel/hotplug_hook.py#L158 For more context, see IRC conversations from 10/1/2021 and 10/4/2021: https://irclogs.ubuntu.com/2021/10/01/%23cloud-init.html https://irclogs.ubuntu.com/2021/10/04/%23cloud-init.html To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1946003/+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 1896734] Re: A privsep daemon spawned by neutron-openvswitch-agent hangs when debug logging is enabled (large number of registered NICs) - an RPC response is too large for msgpac
The Groovy Gorilla has reached end of life, so this bug will not be fixed for that release ** Changed in: python-oslo.privsep (Ubuntu Groovy) Status: New => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1896734 Title: A privsep daemon spawned by neutron-openvswitch-agent hangs when debug logging is enabled (large number of registered NICs) - an RPC response is too large for msgpack Status in OpenStack neutron-openvswitch charm: Invalid Status in Ubuntu Cloud Archive: Fix Released Status in Ubuntu Cloud Archive ussuri series: Fix Released Status in Ubuntu Cloud Archive victoria series: Fix Released Status in neutron: Fix Released Status in oslo.privsep: New Status in neutron package in Ubuntu: Fix Released Status in python-oslo.privsep package in Ubuntu: New Status in neutron source package in Focal: Fix Released Status in python-oslo.privsep source package in Focal: New Status in neutron source package in Groovy: Fix Released Status in python-oslo.privsep source package in Groovy: Won't Fix Status in neutron source package in Hirsute: Fix Released Status in python-oslo.privsep source package in Hirsute: New Bug description: [Impact] When there is a large amount of netdevs registered in the kernel and debug logging is enabled, neutron-openvswitch-agent and the privsep daemon spawned by it hang since the RPC call result sent by the privsep daemon over a unix socket exceeds the message sizes that the msgpack library can handle. The impact of this is that enabling debug logging on the cloud completely stalls neutron-openvswitch-agents and makes them "dead" from the Neutron server perspective. The issue is summarized in detail in comment #5 https://bugs.launchpad.net/oslo.privsep/+bug/1896734/comments/5 [Test Plan] * deploy Openstack Train/Ussuri/Victoria * need at least one compute host * enable neutron debug logging * create a load of interfaces on your compute host to create a large 'ip addr show' output * for ((i=0;i<400;i++)); do ip tuntap add mode tap tap-`uuidgen| cut -c1-11`; done * create a single vm * add floating ip * ping fip * create 20 ports and attach them to the vm * for ((i=0;i<20;i++)); do id=`uuidgen`; openstack port create --network private --security-group __SG__ X-$id; openstack server add port __VM__ X-$id; done * attaching ports should not result in errors [Where problems could occur] No problems anticipated this patchset. When there is a large amount of netdevs registered in the kernel and debug logging is enabled, neutron-openvswitch-agent and the privsep daemon spawned by it hang since the RPC call result sent by the privsep daemon over a unix socket exceeds the message sizes that the msgpack library can handle. The impact of this is that enabling debug logging on the cloud completely stalls neutron-openvswitch-agents and makes them "dead" from the Neutron server perspective. The issue is summarized in detail in comment #5 https://bugs.launchpad.net/oslo.privsep/+bug/1896734/comments/5 Old Description While trying to debug a different issue, I encountered a situation where privsep hangs in the process of handling a request from neutron- openvswitch-agent when debug logging is enabled (juju debug-log neutron-openvswitch=true): https://bugs.launchpad.net/charm-neutron-openvswitch/+bug/1895652/comments/11 https://bugs.launchpad.net/charm-neutron-openvswitch/+bug/1895652/comments/12 The issue gets reproduced reliably in the environment where I encountered it on all units. As a result, neutron-openvswitch-agent services hang while waiting for a response from the privsep daemon and do not progress past basic initialization. They never post any state back to the Neutron server and thus are marked dead by it. The processes though are shown as "active (running)" by systemd which adds to the confusion since they do indeed start from the systemd's perspective. systemctl --no-pager status neutron-openvswitch-agent.service ● neutron-openvswitch-agent.service - Openstack Neutron Open vSwitch Plugin Agent Loaded: loaded (/lib/systemd/system/neutron-openvswitch-agent.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2020-09-23 08:28:41 UTC; 25min ago Main PID: 247772 (/usr/bin/python) Tasks: 4 (limit: 9830) CGroup: /system.slice/neutron-openvswitch-agent.service ├─247772 /usr/bin/python3 /usr/bin/neutron-openvswitch-agent --config-file=/etc/neutron/neutron.conf --config-file=/etc/neutron/plugins/ml2/openvswitch_…og └─248272 /usr/bin/python3 /usr/bin/privsep-helper
[Yahoo-eng-team] [Bug 1906266] Re: After upgrade: "libvirt.libvirtError: Requested operation is not valid: format of backing image %s of image %s was not specified"
The Groovy Gorilla has reached end of life, so this bug will not be
fixed for that release
** Changed in: nova (Ubuntu Groovy)
Status: New => Won't Fix
--
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/1906266
Title:
After upgrade: "libvirt.libvirtError: Requested operation is not
valid: format of backing image %s of image %s was not specified"
Status in Ubuntu Cloud Archive:
New
Status in Ubuntu Cloud Archive ussuri series:
Fix Committed
Status in OpenStack Compute (nova):
Won't Fix
Status in libvirt package in Ubuntu:
Fix Released
Status in nova package in Ubuntu:
New
Status in libvirt source package in Focal:
Fix Released
Status in nova source package in Focal:
New
Status in libvirt source package in Groovy:
Fix Released
Status in nova source package in Groovy:
Won't Fix
Bug description:
[Impact]
* New libvirt got more strict in regard to file format specification.
While this is generally the right approach it causes some issues for
upgraders that have old image chains now failing.
* Upstream has added code to relax those checks under a set of conditions
which will allow to go forward with stricter conditions as planned but
at the same time not break/block upgrades.
[Test Plan]
* Thanks to Brett Milford for sharing his test steps for this
sudo apt-get update
sudo apt-get install libvirt-daemon-system cloud-image-utils virtinst -y
IMG="focal-server-cloudimg-amd64.img"
IMG_PATH="/var/lib/libvirt/images/base/$IMG"
INSTANCE_NAME=testinst
[ -f $IMG_PATH ] || {
sudo mkdir -p /var/lib/libvirt/images/base
sudo wget
https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64.img \
-O $IMG_PATH
}
sudo mkdir -p /var/lib/libvirt/images/$INSTANCE_NAME
sudo qemu-img convert -O raw $IMG_PATH ${IMG_PATH%.*}
sudo qemu-img create -f qcow2 -o backing_file=${IMG_PATH%.*}
/var/lib/libvirt/images/$INSTANCE_NAME/root.img
sudo qemu-img resize /var/lib/libvirt/images/$INSTANCE_NAME/root.img 5G
virt-install --connect qemu:///system --name $INSTANCE_NAME --cpu host
--os-type linux --os-variant generic --graphics vnc --console
pty,target_type=serial --disk
path=/var/lib/libvirt/images/$INSTANCE_NAME/root.img,bus=virtio,format=qcow2
--network default,model=virtio --noautoconsole --vcpus 1 --memory 1024
--import
[Where problems could occur]
* Of the many things that qemu/libvirt do this changes only the format
probing. So issues (hopefully not) would be expected to appear mostly
around complex scenarios of image files.
We've had a look at image files and image file chains, and so far all
were good. But there are more obscure (and not supported) cases like
image backed by real-disk that might misbehave. But still it would
fix Focal to be the outlier as the past was ok (didn't care) and the
future (relaxed check) and only focal is left broken in between.
[Other Info]
* A lot has changes in that area, but instead of pulling in a vast set
of changes a smaller set was identified to suite the SRU needs. It
was so far found not found regressing anything and OTOH fixed the issue
(tested form PPA) for affected people.
In a site upgraded to Ussuri we are getting faults starting instances
2020-11-30 13:41:40.586 232871 ERROR oslo_messaging.rpc.server
libvirt.libvirtError: Requested operation is not valid: format of
backing image '/var/lib/nova/instances/_base/xxx' of image
'/var/lib/nova/instances/xxx' was not specified in the image metadata
(See https://libvirt.org/kbase/backing_chains.html for
troubleshooting)
Bug #1864020 reports similar symptoms, where due to an upstream change
in Libvirt v6.0.0+ images need the backing format specified.
The fix for Bug #1864020 handles the case for new instances. However,
for upgraded instances we're hitting the same problem, as those still
don't have backing format specified.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1906266/+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 1918303] Re: Randomly set credentials written in cleartext to world-readable file
cloud-init (21.1-19-gbad84ad4-0ubuntu1) hirsute; urgency=medium * d/cloud-init.postinst: Change output log permissions on upgrade (LP: #1918303) ** Also affects: cloud-init (Ubuntu) Importance: Undecided Status: New ** Changed in: cloud-init (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1918303 Title: Randomly set credentials written in cleartext to world-readable file Status in cloud-init: Fix Committed Status in cloud-init package in Ubuntu: Fix Released Bug description: ## Summary cloud-init allows administrators to set passwords for user accounts via the chpasswd configuration module. Administrators can instruct cloud-init to set a random password generated at runtime using the 'R' or 'RANDOM' keywords. However, cloud-init appears to write all randomly generated passwords in cleartext to stderr. Cloud-init's default logging configuration, in file /etc/cloud/cloud.cfg.d/05_logging.cfg, redirects both stdout and stderr to the log file /var/log/cloud-init-output.log. The file /var/log/cloud-init-output.log is world readable. Thus, any unprivileged account on the system can view the cleartext password for any account which had a random password generated at runtime. The credentials are not redacted in the log. ## Reproduction Pre-requisites: A device with Ubuntu Server 20.04 installed. Ubuntu Server comes with cloud-init pre-installed out of the box, but the latest release of cloud-init as of this report (21.1) is not available in 20.04's apt repositories. You may need to install v21.1 manually. You will also need an exsiting admin account with root privileges. 1. Login as admin. 2. Create an unprivileged user account, bob, and set a password. We will use this account to demonstrate unprivileged account access to generated passwords. sudo adduser bob 3. Create another unprivileged user account, alice, and set a password. We will change this account's password with cloud-init. sudo adduser alice 4. Create and open configuration file /etc/cloud/cloud.cfg.d/95_chpasswd.cfg using vim or other editor of your choice. sudo vim /etc/cloud/cloud.cfg.d/95_chpasswd.cfg 5. Add the following chpasswd configuration content to the file then save and exit. chpasswd: list: | alice:RANDOM 6. cloud-init only runs the chpasswd function on first boot of the OS that cloud-init knows about. For proof of concept purposes, we need to simulate a new instance. Run: sudo cloud-init clean to reset cloud-init's state. 7. Reboot the system. sudo reboot 8. Login as unprivileged user bob. 9. View the password by runnnig cat /var/log/cloud-init-output.log | grep alice 10. Alice's temporary password should appear on terminal in the form alice: 11. Logout and log back in to the system as alice using the temporary password. You should get access and prompted to set a new password, which confirms the password bob retrieved from the logs is the actual password for alice's account. ## Impact Any unprivileged user on the system can retrieve all cloud-init randomly set credentials. These could potentially be used to access other accounts. # Notes If 'expire: false' is added to the chpasswd config, then leaked passwords remain valid until manually changed and increases the risk of unauthorized account access. Otherwise, the default behaviour prompts accounts to set a new password at next login, reducing the time window for unauthorized access. Accounts not used for interactive login might not get passwords changed or accounts might get a password set but then not authenticate for some time. The precise impact and duration of valid exposed credentials appears dependent somewhat on each cloud-init customer's environment and how they use cloud-init to set credentials. I'm not sure the best approach to patch this but perhaps the credentials could be written to cloud-init's protected directories or files which restrict access to root users only, such as /var/run /cloud-init/instance-data-sensitive.json? Line 214 of https://github.com/canonical/cloud- init/blob/master/cloudinit/config/cc_set_passwords.py checks if any random passwords were set and if so prints each one to stderror. This might be the root cause. Tested on Ubuntu Server 20.04.02, cloud-init latest release 21.1 as of report time. If I can provide any further information please let me know. Thanks! -Carl To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1918303/+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 1853613] Re: VMs don't get ip from dhcp after compute restart
** Also affects: neutron (Ubuntu) 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/1853613 Title: VMs don't get ip from dhcp after compute restart Status in neutron: Fix Released Status in neutron package in Ubuntu: Incomplete Bug description: Env: pike + ovs + vxlan + l2pop + iptables_hybrid. Dhcp agent on differnt node than compute. Steps: 1. Boot 4 or more vms to same compute and same vxlan net. 2. Wait until they are fully running and reboot compute node. 3. After boot the vms are in status SHUTOFF. Start the vms. Vms don't get an ip address from neutron dhcp. The flood to tunnels flow (br-tun table 22) for the network is missing, so broadcasts like dhcp requests don't get on a tunnel to the node with dhcp agent. Neutron server did not send the flooding entry to the agent. It only does that for the first or second active port, or if the agent is restarted. After the compute boots, neutron-ovs-cleanup runs first and deletes the qvo ports from br-int [4]. Then the ovs-agent starts and nova- compute after it. Nova-compute destroys the domains and moves the vms to SHUTOFF status. It also (for some reason) recreates the qbr linux bridges and qvb/qvo veths connected to br-int. So neutron continues to see the ports as ACTIVE even though the vms are SHUTOFF, and agent_active_ports [1] never drops below 3. Also nova-compute might start a short time after the ovs-agent and the new ports are not detected in first iteration of the ovs agent loop, so agent_restarted will be false here [2]. Before [3] agent_restarted was true if the agent was running for less than agent_boot_time (default 180 sec) and the problem did not show. It does not happen if neutron-ovs-cleanup is disabled. Then the ovs agent first treats them as skipped_devices and they get status DOWN. [1] https://github.com/openstack/neutron/blob/21a52f7ae597f7992f32ff41cedff0c31e35c762/neutron/plugins/ml2/drivers/l2pop/mech_driver.py#L306 [2] https://github.com/openstack/neutron/blob/21a52f7ae597f7992f32ff41cedff0c31e35c762/neutron/plugins/ml2/drivers/l2pop/mech_driver.py#L310 [3] https://opendev.org/openstack/neutron/commit/62fe7852bbd70a24174853997096c52ee015e269 [4] https://bugs.launchpad.net/neutron/+bug/1853582 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1853613/+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 1864822] Re: Openvswitch Agent - Connexion openvswitch DB Broken
** Also affects: neutron (Ubuntu) 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/1864822 Title: Openvswitch Agent - Connexion openvswitch DB Broken Status in neutron: Fix Released Status in neutron package in Ubuntu: Incomplete Bug description: Hi all, We have deployed more OpenStack plateform in my company. We used kolla ansible to deploy our plateforms. Here is the configuration that we applied : kolla_base_distro: "centos" kolla_install_type : "binary" openstack_version : "stein" Neutron architecture : HA l3 enable DVR enable SNAT Enabled multiple vlan provider : True Note: Our plateforms are multi-region Recently, we have upgraded a master region from rocky to stein with kolla ansible upgrade procedure. Since ugrade, sometimes openvswitch agent lost connexion to ovsdb. We have found this error in neutron-openvswitch-agent.log : "tcp:127.0.0.1:6640: send error: Broken pipe". And we have found this errors in ovsdb-server.log : 2020-02-24T23:13:22.644Z|9|reconnect|ERR|tcp:127.0.0.1:50260: no response to inactivity probe after 5 seconds, disconnecting 2020-02-25T04:10:55.893Z|00010|reconnect|ERR|tcp:127.0.0.1:58544: no response to inactivity probe after 5 seconds, disconnecting 2020-02-25T07:21:12.301Z|00011|reconnect|ERR|tcp:127.0.0.1:34918: no response to inactivity probe after 5 seconds, disconnecting 2020-02-25T09:21:45.533Z|00012|reconnect|ERR|tcp:127.0.0.1:37782: no response to inactivity probe after 5 seconds, disconnecting When we experience this issue, all "NORMAL" type flows inside br-ex doesn't get out. Example of flows stuck: (neutron-openvswitch-agent)[root@cnp69s12p07 /]# ovs-ofctl dump-flows br-ex | grep NORMAL cookie=0x7adbd675f988912b, duration=72705.077s, table=0, n_packets=185, n_bytes=16024, idle_age=65534, hard_age=65534, priority=0 actions=NORMAL cookie=0x7adbd675f988912b, duration=72695.007s, table=2, n_packets=11835702, n_bytes=5166123797, idle_age=0, hard_age=65534, priority=4,in_port=5,dl_vlan=1 actions=mod_vlan_vid:12,NORMAL cookie=0x7adbd675f988912b, duration=72694.928s, table=2, n_packets=4133243, n_bytes=349654412, idle_age=0, hard_age=65534, priority=4,in_port=5,dl_vlan=9 actions=mod_vlan_vid:18,NORMAL Workaround to solve this issue: - stop openvswitch_db openvswitch_vswitchd neutron_openvswitch_agent neutron_l3_agent (containers) - start containers: openvswitch_db openvswitch_vswitchd - start neutron_l3_agent neutron_openvswitch_agent Note: we have keep ovs connection timeout options by default : - of_connect_timeout: 300 - of_request_timeout: 300 - of_inactivity_probe: 10 Thank you in advance for your help. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1864822/+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 1862343] Re: compiled messages not shipped in packaging resulting in missing translations
The Eoan Ermine has reached end of life, so this bug will not be fixed
for that release
** Changed in: horizon (Ubuntu Eoan)
Status: New => Won't Fix
--
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/1862343
Title:
compiled messages not shipped in packaging resulting in missing
translations
Status in OpenStack openstack-dashboard charm:
Invalid
Status in Ubuntu Cloud Archive:
Fix Released
Status in Ubuntu Cloud Archive rocky series:
New
Status in Ubuntu Cloud Archive stein series:
New
Status in Ubuntu Cloud Archive train series:
New
Status in Ubuntu Cloud Archive ussuri series:
Fix Released
Status in OpenStack Dashboard (Horizon):
Invalid
Status in horizon package in Ubuntu:
Fix Released
Status in horizon source package in Eoan:
Won't Fix
Status in horizon source package in Focal:
Fix Released
Bug description:
I changed the language in GUI to French but interface stays mostly
English. Just a few strings are displayed in French, e.g.:
- "Password" ("Mot de passe") on the login screen,
- units "GB", "TB" as "Gio" and "Tio" in Compute Overview,
- "New password" ("Noveau mot de passe") in User Settings.
All other strings are in English.
See screenshots attached.
This is the Stein on Ubuntu Bionic deployment.
To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-openstack-dashboard/+bug/1862343/+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 1872836] Re: Swap file creation broken due to incorrect format specifiers
** Also affects: cloud-init (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1872836 Title: Swap file creation broken due to incorrect format specifiers Status in cloud-init: New Status in cloud-init package in Ubuntu: New Bug description: Swap file creation currently fails with the following error: cc_mounts.py[WARNING]: failed to setup swap: %d format: a number is required, not str This appears to be fallout from changes from this commit: https://github.com/canonical/cloud-init/commit/6603706 https://github.com/canonical/cloud-init/pull/70 It appears several '%d' format specifiers are being incorrectly paired with a string type variable instead of number type variable. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1872836/+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 1840686] Re: Xenial images won't reboot if disk size is > 2TB when using GPT
This is fixed in the version of grub2 in Eoan which will become Ubuntu 19.10. ** Changed in: grub (Ubuntu) Status: New => Fix Released ** Changed in: grub (Ubuntu Xenial) Status: New => Triaged ** Changed in: grub (Ubuntu Xenial) Importance: Undecided => High -- 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/1840686 Title: Xenial images won't reboot if disk size is > 2TB when using GPT Status in cloud-init: Won't Fix Status in grub package in Ubuntu: Fix Released Status in grub source package in Xenial: Triaged Bug description: CPC team has recently converted Xenial images to use GPT instead of MBR. However, after booting an instance that has a disk size of 2049 GB or higher, we hang on the next subsequent boot (Logs indicate it hanging on "Booting Hard Disk 0". This works on Bionic, but what makes it strange is that they have the same kernel revision - 4.15.0-1-37. patrick_viafore@patviafore-test-3072-xenial:~$ lsb_release -rd Description:Ubuntu 16.04.6 LTS Release:16.04 patrick_viafore@patviafore-test-3072-xenial:~$ sudo dpkg -l | grep linux-gcp ii linux-gcp4.15.0.1037.51 amd64Complete Google Cloud Platform (GCP) Linux kernel and headers ii linux-gcp-headers-4.15.0-10374.15.0-1037.39~16.04.1 amd64Header files related to Linux kernel version 4.15.0 To reproduce: 1) Create an image with a disk size of 3072 using a serial that has GPT gcloud compute instances create test-3072-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 3072 Reboot the instance 2) It will hang on reboot and you cannot connect 3) Please note that later serials have the GPT change reverted. You can replace xenial with bionic in the above commands to get a bionic instance instead. To test this out in a more slower fashion: 1) Create an image with a disk size of 2048 using a serial that has GPT gcloud compute instances create test-2048-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 2048 2) Resize the disk to 3072 3) Issue growpart /dev/sda 1 4) Issue resize2fs /dev/sda1 5) Issue rsize2fs /dev/sda1 again On the second resize2fs, it tries to resize again, but on a working instance, it says there's nothing to resize. I've tried starting from a Xenial instance and doing a do-release- upgrade to get to bionic and then doing the growpart/resize2fs, but the issue still shows up. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1840686/+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
This bug is missing the SRU template but I believe this is just adding an apport hook so I'll let it in without one. However, we should have one before accepting the package into -updates. ** Also affects: cloud-init (Ubuntu) Importance: Undecided Status: New ** Changed in: cloud-init (Ubuntu Zesty) Status: New => Fix Committed ** Tags added: verification-needed verification-needed-zesty -- 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: Fix Released Status in MAAS: Triaged Status in cloud-init package in Ubuntu: New Status in cloud-init source package in Xenial: Fix Committed Status in cloud-init source package in Zesty: Fix Committed Bug 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. 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 1691772] Re: provide a way to seed NoCloud from network without image modification.
** Changed in: cloud-init
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1691772
Title:
provide a way to seed NoCloud from network without image modification.
Status in cloud-init:
Fix Released
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Xenial:
Confirmed
Status in cloud-init source package in Zesty:
Confirmed
Bug description:
=== Begin SRU Template ===
[Impact]
In bug 1660385, we made imitating the EC2 datasource more difficult.
By design, that broke some users or platforms who have done so in the past.
The change here gives users who were using the Ubuntu images in a low-tech
"No Cloud" fashion an easier way to regain that functionality.
The solution was to read the 'system-serial-number' field in DMI data and
consider it as as input to the nocloud datasource in a similar way to
what we had done in the past with the kernel command line.
[Test Case]
a.) download a cloud image, update its cloud-init
# see below for 'get-proposed-cloudimg'
$ release=xenial
$ get-proposed-cloudimg $release
b.) boot that image with command line pointing at a 'seed'
$ img=${release}-server-cloudimg-amd64-proposed.img
# url has to provide '/user-data' and '/meta-data'
$
url=https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bugs/lp-1691772/
$ qemu-system-x86_64 -snapshot -enable-kvm -m 512 \
-device virtio-net-pci,netdev=net00 -netdev type=user,id=net00 \
-drive "file=$img,if=virtio" \
-smbios "type=1,serial=ds=nocloud-net;seedfrom=$url" \
-nographic
# note, you can hit 'ctrl-a c' to toggle between the qemu monitor
# and the serial console in '-nographic' mode.
c.) Log in with 'ubuntu:passw0rd' and check hostname.
If the above url was correctly used, then:
* you can log in with 'ubuntu:passw0rd'
* the hostname will be set to 'nocloud-guest'
* /run/cloud-init/result.json will show that the url has been used.
ubuntu@nocloud-guest:~$ hostname
nocloud-guest
ubuntu@nocloud-guest$ cat /run/cloud-init/result.json
{
"v1": {
"datasource": "DataSourceNoCloudNet
[seed=dmi,https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bugs/lp-1691772/][dsmode=net];,
"errors": []
}
}
[Regression Potential]
The code attempts to parse the 'system-serial-number' entry in dmi data as a
string with data in it. If that field had the string 'ds=nocloud' that was
not intended as consumable for cloud-init, a false positive could occur and
an exception cause the NoCloud datasource to not read data from another
location.
This seems somewhat unlikely and other paths should result in simply no
new action being taken.
[Other Info]
Upstream commit at
https://git.launchpad.net/cloud-init/commit/?id=802e7cb2da8
get-proposed-cloudimg is available at [1], it basically downloads an
ubuntu cloud image, enables -proposed and upgrade/installs cloud-init.
--
[1]
https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/tree/bin/get-proposed-cloudimg
=== End SRU Template ===
Vladimir suggested this in bug 1660385 comment 12 [1].
The idea would be to have a supported way that you could seed images with
cloud-init using Nocloud without any tinkering in the image. That would mean
a.) no second block device
b.) no usage of kernel command line.
--
[1] https://bugs.launchpad.net/cloud-init/+bug/1660385/comments/12
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1691772/+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 1692916] Re: Cloudinit modules should provide schema validation to better alert consumers to unsupported config
** Changed in: cloud-init Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1692916 Title: Cloudinit modules should provide schema validation to better alert consumers to unsupported config Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: New Status in cloud-init source package in Zesty: New Bug description: === Begin SRU Template === [Impact] New feature to validate and log invalid schema warnings from cc_ntp cloud-config module. [Test Case] if [ ! -f lxc-proposed-snapshot ]; then wget https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bin/lxc-proposed-snapshot chmod 755 lxc-proposed-snapshot fi cat < 1.conf #cloud-config ntp: EOF for release in xenial zesty; do ref=$release-proposed; echo "$release START --"; ./lxc-proposed-snapshot --proposed --publish $release $ref; lxc start test-$release; lxc file push 1.conf test-$release/1.conf lxc exec test-$release -- python3 /usr/lib/python3/dist-packages/cloudinit/config/schema.py -c /1.conf | grep Valid lxc exec test-$release -- apt-cache depends cloud-init | grep jsonschema # should be empty done [Regression Potential] We don't want to introduce a mandatory jsonschema dependency in older series. Validate that older releases can run without errors when jsonschema is *not* installed. [Other Info] Upstream commit at https://git.launchpad.net/cloud-init/commit/?id=0a448dd034 === End SRU Template === cloudinit needs a mechanism to parse and validate a strict schema definition for modules that parse user created #cloud-config yaml files. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1692916/+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 1691489] Re: fstab entries written by cloud-config may not be mounted
** Changed in: cloud-init Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1691489 Title: fstab entries written by cloud-config may not be mounted Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Confirmed Status in cloud-init source package in Yakkety: Confirmed Status in cloud-init source package in Zesty: Confirmed Status in cloud-init source package in Artful: Fix Released Bug description: As reported in bug 1686514, sometimes /mnt will not get mounted when re-delpoying or stopping-then-starting a Azure vm of L32S. This is probably a more generic issue, I suspect shown due to the speed of disks on these systems. Related bugs: * bug 1686514: Azure: cloud-init does not handle reformatting GPT partition ephemeral disks To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1691489/+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 1701097] Re: eni rendering of ipv6 gateways fails
** Changed in: cloud-init Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1701097 Title: eni rendering of ipv6 gateways fails Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Confirmed Status in cloud-init source package in Zesty: Confirmed Status in cloud-init source package in Artful: Fix Released Bug description: cloud-init trunk and xenial, yakkety, zesty and artful all fail A network config with a ipv6 gateway route like: subnets: - type: static address: 2001:4800:78ff:1b:be76:4eff:fe06:96b3 netmask: ':::::' routes: - gateway: 2001:4800:78ff:1b::1 netmask: '::' network: '::' For eni rendering, this should create a post-up/post-down route command that generates a default ipv6 route entry, like this: post-up route add -A inet6 default gw 2001:4800:78ff:1b::1 || true pre-down route del -A inet6 default gw 2001:4800:78ff:1b::1 || true However, what is currently generated is this: post-up route add -net :: netmask :: gw 2001:4800:78ff:1b::1 || true pre-down route del -net :: netmask :: gw 2001:4800:78ff:1b::1 || true That does not install the route correctly as a default gateway route. This is fallout from commit d00da2d5b0d45db5670622a66d833d2abb907388 net: normalize data in network_state object This commit removed ipv6 route 'netmask' values, and converted them to prefix length values, but failed to update the eni renderer's check for ipv6 default gateway. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1701097/+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 1692028] Re: duplicate mac address during config-drive configuration with LXD container on openstack
This is fixed in artful: [ 11:48AM 10022 ] [ bdmurray@impulse:/tmp/cloud-init-0.7.9-153-g16a7302f ] $ grep -r "test_duplicates_of_empty_mac" * tests/unittests/test_net.py:def test_duplicates_of_empty_mac_are_ok(self): ** Changed in: cloud-init (Ubuntu Artful) Status: Confirmed => Fix Released ** Changed in: cloud-init (Ubuntu Yakkety) Status: Confirmed => Fix Committed -- 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/1692028 Title: duplicate mac address during config-drive configuration with LXD container on openstack Status in cloud-init: Fix Committed Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Confirmed Status in cloud-init source package in Yakkety: Fix Committed Status in cloud-init source package in Zesty: Fix Committed Status in cloud-init source package in Artful: Fix Released Bug description: === Begin SRU Template === [Impact] When the 'ip_gre' module is loaded, the kernel creates two network devices 'gre0' and 'gretap0' that appear in all network namespaces. (For example, if you create an lxd container, and then load the ip_gre module from outside the container, the container will see 2 new network devices). The hardware address of these devices is 00:00:00:00:00 as seen below. # ( cd /sys/class/net/ && grep . gre*/address ) gre0/address:00:00:00:00 gretap0/address:00:00:00:00:00:00 This "duplicate" mac address caused cloud-init to raise a RuntimeError. The overall impact is that cloudinit's network rendering code will not work if the ip_gre module is loaded on the system. That will happen in some nova-lxd environments, but also anywhere where a user has loaded that module and is running lxc. [Test Case] 1.) load a module on your host sudo modprobe ip_gre 2.) Launch an instance in lxd. $ rel=xenial $ name=x1 $ lxc launch ubuntu-daily:$rel $name 3.) see the stack trace by running 'get_interfaces_by_mac()' in the guest. $ lxc exec $name -- \ python3 -c 'from cloudinit import net; print(net.get_interfaces_by_mac())' 4.) upgrade instance to proposed cloud-init $ lxc exec $name -- sh -c ' mirror=http://archive.ubuntu.com/ubuntu echo deb $mirror $(lsb_release -sc)-proposed main | tee /etc/apt/sources.list.d/proposed.list apt-get update -q apt-get install -qy cloud-init' $ lxc exec $name -- dpkg-query --show cloud-init 5.) see that get_interfaces_by_mac() no longer stack traces. $ lxc exec $name -- \ python3 -c 'from cloudinit import net; print(net.get_interfaces_by_mac())' A more complete test case is to load an image into nova-lxd with gre tunneling loaded on the host, but that is much more involved setup. [Regression Potential] Regression potential should be pretty low. We are simply ignoring network interfaces not named 'lo' that have a mac address of '00:00:00:00:00' [Other Info] Upstream commit at https://git.launchpad.net/cloud-init/commit/?id=2c0655feb9 === End SRU Template === Whilst testing the changes for nova-lxd to resolve issues with use of config-drive, I tripped over this issue; specifically the networking on a config-drive configured LXD instance never starts due to a duplicate MAC address on the lo and greptap0 devices. Cloud-init v. 0.7.9 running 'init' at Fri, 19 May 2017 13:41:00 +. Up 2.0 seconds. ci-info: Net device info+ ci-info: +-+---+--+---+---+-+ ci-info: | Device | Up | Address|Mask | Scope |Hw-Address | ci-info: +-+---+--+---+---+-+ ci-info: | gretap0 | False | . | . | . |00:00:00:00:00:00| ci-info: | eth0 | True | . | . | . |fa:16:3e:1d:aa:ac| ci-info: | eth0 | True | fe80::f816:3eff:fe1d:aaac/64 | . | link |fa:16:3e:1d:aa:ac| ci-info: |lo | True | 127.0.0.1 | 255.0.0.0 | . |.| ci-info: |lo | True | ::1/128| . | host |.| ci-info: | gre0 | False | . | . | . | 00-00-00-00-31-36-3a-33-00-00-00-00-00-00-00-00 | ci-info:
[Yahoo-eng-team] [Bug 1685935] Re: make deb breaks due to missing debuild script
Because I'm a nice guy I added a cloud-init Ubuntu task for this bug so it could be SRU'ed, I also manually verified that this particular fix exists in Artful by downloading the package and checking the Makefile. ** Also affects: cloud-init (Ubuntu) Importance: Undecided Status: New ** Changed in: cloud-init (Ubuntu Zesty) Status: New => Fix Committed ** Tags added: verification-needed -- 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/1685935 Title: make deb breaks due to missing debuild script Status in cloud-init: Fix Committed Status in cloud-init package in Ubuntu: New Status in cloud-init source package in Zesty: Fix Committed Bug description: === Begin SRU Template === [Impact] Minor tweak to Makefile target make deb to announce missing devscripts package dependency in developer environments. [Test Case] No test case as this Makefile and related bddeb script are developer tools and aren't part of cloud-init deb package. [Regression Potential] None [Other Info] === End SRU Template === To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1685935/+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 1647910] Re: hostname is set incorrectly if localhostname is fully qualified
** Also affects: cloud-init (Ubuntu) Importance: Undecided Status: New ** Changed in: cloud-init (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1647910 Title: hostname is set incorrectly if localhostname is fully qualified Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Bug description: If no data source is available and the local hostname is set to "localhost.localdomain", and /etc/hosts looks like: 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 Then in sources/__init__.py in get_hostname: - util.get_hostname() will return 'localhost.localdomain' - util.get_fqdn_from_hosts(hostname) will return 'localhost' - 'toks' will be set to [ 'localhost.localdomain', 'localdomain' And ultimately the system hostname will be set to 'localhost.localdomain.localdomain', which isn't useful to anybody. Also reported in: https://bugzilla.redhat.com/show_bug.cgi?id=1389048 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1647910/+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 1621615] Re: network not configured when ipv6 netbooted into cloud-init
As far as I can tell this doesn't seem to be fixed in cloud-initramfs- tools for Yakkety. Am I missing something? ** Also affects: cloud-initramfs-tools (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1621615 Title: network not configured when ipv6 netbooted into cloud-init Status in cloud-init: In Progress Status in MAAS: New Status in cloud-init package in Ubuntu: Fix Released Status in cloud-initramfs-tools package in Ubuntu: New Status in cloud-init source package in Xenial: Fix Committed Bug description: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1621507 talks of how IPv6 netboot with iscsi root disk doesn't work, blocking IPv6-only MAAS. After I hand-walked busybox through getting an IPv6 address, everything worked just fine until cloud-init couldn't fetch the instance data, because it insisted on bringing up the interface in IPv4, and there is no IPv4 DHCP on that vlan. Please work with initramfs and friends on getting IPv6 netboot to actually configure the interface. This may be as simple as teaching it about "inet6 dhcp" interfaces, and bolting the pieces together. Note that "use radvd" is not really an option for our use case. Related bugs: * bug 1621507: initramfs-tools configure_networking() fails to dhcp IPv6 addresses [Impact] It is not possible to enlist, commmission, or deploy with MAAS in an IPv6-only environment. Anyone wanting to netboot with a network root filesystem in an IPv6-only environment is affected. This upload addresses this by accepting, using, and forwarding any IPV6* variables from the initramfs boot. (See https://launchpad.net/bugs/1621507) [Test Case] See Bug 1229458. Configure radvd, dhcpd, and tftpd for your IPv6-only netbooting world. Pass the boot process an IPv6 address to fetch instance-data from, and see it fail to configure the network. [Regression Potential] 1) If the booting host is in a dual-boot environment, and the instance-dat URL uses a hostname that has both A and RRsets, the booting host may try to talk IPv6 to get instance data. If the instance-data providing host is only allowing that to happen over IPv4, it will fail. (It also represents a configuraiton issue on the providing host...) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1621615/+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 1444532] Re: nova-scheduler doesnt reconnect to databases when started and database is down
** Package changed: ubuntu = nova (Ubuntu)
--
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/1444532
Title:
nova-scheduler doesnt reconnect to databases when started and database
is down
Status in OpenStack Compute (Nova):
New
Status in nova package in Ubuntu:
New
Bug description:
In Juno release (ubuntu packages), when you start nova-scheduler but
database is down, the service never reconnects, the stacktrace is as
follow :
AUDIT nova.service [-] Starting scheduler node (version 2014.2.2)
ERROR nova.openstack.common.threadgroup [-] (OperationalError) (2003, Can't
connect to MySQL server on '10.128.30.11' (111)) None None
TRACE nova.openstack.common.threadgroup Traceback (most recent call last):
TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/openstack/common/threadgroup.py, line
125, in wait
TRACE nova.openstack.common.threadgroup x.wait()
TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/openstack/common/threadgroup.py, line
47, in wait
TRACE nova.openstack.common.threadgroup return self.thread.wait()
TRACE nova.openstack.common.threadgroup File
/usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py, line 173, in
wait
TRACE nova.openstack.common.threadgroup return self._exit_event.wait()
TRACE nova.openstack.common.threadgroup File
/usr/local/lib/python2.7/dist-packages/eventlet/event.py, line 121, in wait
TRACE nova.openstack.common.threadgroup return hubs.get_hub().switch()
TRACE nova.openstack.common.threadgroup File
/usr/local/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 293, in
switch
TRACE nova.openstack.common.threadgroup return self.greenlet.switch()
TRACE nova.openstack.common.threadgroup File
/usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py, line 212, in
main
TRACE nova.openstack.common.threadgroup result = function(*args, **kwargs)
TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/openstack/common/service.py, line 490,
in run_service
TRACE nova.openstack.common.threadgroup service.start()
TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/service.py, line 169, in start
TRACE nova.openstack.common.threadgroup self.host, self.binary)
TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/conductor/api.py, line 161, in
service_get_by_args
TRACE nova.openstack.common.threadgroup binary=binary, topic=None)
TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/utils.py, line 949, in wrapper
TRACE nova.openstack.common.threadgroup return func(*args, **kwargs)
TRACE nova.openstack.common.threadgroup File
/usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/server.py, line
139, in inner
TRACE nova.openstack.common.threadgroup return func(*args, **kwargs)
TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/conductor/manager.py, line 279, in
service_get_all_by
TRACE nova.openstack.common.threadgroup result =
self.db.service_get_by_args(context, host, binary)
TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/db/api.py, line 136, in
service_get_by_args
TRACE nova.openstack.common.threadgroup return
IMPL.service_get_by_args(context, host, binary)
TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py, line 125, in
wrapper
TRACE nova.openstack.common.threadgroup return f(*args, **kwargs)
TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py, line 490, in
service_get_by_args
TRACE nova.openstack.common.threadgroup result = model_query(context,
models.Service).\
TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py, line 213, in
model_query
TRACE nova.openstack.common.threadgroup session = kwargs.get('session')
or get_session(use_slave=use_slave)
TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py, line 101, in
get_session
TRACE nova.openstack.common.threadgroup facade = _create_facade_lazily()
TRACE nova.openstack.common.threadgroup File
/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py, line 91, in
_create_facade_lazily
TRACE nova.openstack.common.threadgroup _ENGINE_FACADE =
db_session.EngineFacade.from_config(CONF)
TRACE nova.openstack.common.threadgroup File
/usr/local/lib/python2.7/dist-packages/oslo/db/sqlalchemy/session.py, line
795, in from_config
TRACE nova.openstack.common.threadgroup
retry_interval=conf.database.retry_interval)
[Yahoo-eng-team] [Bug 1404311] Re: [SRU] gce metadata api doesn't properly stream binary data
Hello Wayne, or anyone else affected, Accepted cloud-init into precise-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/cloud- init/0.6.3-0ubuntu1.16 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! ** Also affects: cloud-init (Ubuntu Precise) Importance: Undecided Status: New ** Changed in: cloud-init (Ubuntu Precise) Status: New = Fix Committed -- 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/1404311 Title: [SRU] gce metadata api doesn't properly stream binary data Status in Init scripts for use on cloud images: Fix Committed Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Precise: Fix Committed Status in cloud-init source package in Trusty: Fix Committed Status in cloud-init source package in Utopic: Fix Committed Status in cloud-init source package in Vivid: Fix Released Bug description: [IMPACT] Due to limitations in GCE, binary user-data is mangled when sent as user-data. [FIX] Allow user to declare binary encoding on user-data. [VERIFICATION] 1. Create pristine image from -proposed 2. For step 6 3. Boot GCE instance w/ normal user-data, i.e.: $ cat user-data #cloud-config ssh_import_id: [utlemming] $ gcloud compute instances create image from step 1 \ --metadata-from-file user-data=user-data 4. Confirm that user-data was parsed properly 5. GZIP user-data, and encode using base64: gzip -c user-data.txt | base64 user-data.b64 6. Boot GCE instance w/ user-data.b64 and character encoding meta-data set: $ gcloud compute instances create image from step 1 \ --metadata-from-file user-data=user-data.b64 \ --metadata user-data-encoding=base64 7. Confirm that user-data was consumed; attach /var/log/cloud-init.log to report. [RISK] If a user sets the user-data-encoding to base64, but does not provide base64 data the instance will fail to provision. However, since the user has to explicitly setup the circumstances, it is low risk. [ORIGINAL REPORT] The GCE datasource uses the long hostname. Hostnames longer than 64 characters can break several tools. While implementing the GCE provider for Juju we found that the metadata API breaks when trying to retrieve certain binary formats. In our case the gz of user-data. The API only streams out the first 5 bytes, encounters what it preceives as a EOF/nil character and truncates the rest of the request. We've opened an issue with Google directly, but in the meantime a work around is to allow an explicit encoding to be set for the user-data field of the GCE metadata. This will allow use to base64 encode the binary blob, which the API returns the entire contents of without issue. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1404311/+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 1244694] Re: [SRU] Creating snapshot fails due to nonexistent temporary directory
Hello Daniel, or anyone else affected, Accepted libvirt into saucy-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/libvirt/1.1.1-0ubuntu8.3 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance! ** Also affects: libvirt (Ubuntu Saucy) Importance: Undecided Status: New ** Changed in: libvirt (Ubuntu Saucy) Importance: Undecided = High ** Changed in: libvirt (Ubuntu Saucy) Status: New = Triaged ** Changed in: libvirt (Ubuntu Saucy) Status: Triaged = Fix Committed ** Tags added: verification-needed -- 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/1244694 Title: [SRU] Creating snapshot fails due to nonexistent temporary directory Status in OpenStack Compute (Nova): New Status in “libvirt” package in Ubuntu: Fix Released Status in “libvirt” source package in Saucy: Fix Committed Bug description: SRU Justification --- [Impact] In a libvirt-based OpenStack deployment, Nova fails to snapshot instances, failing with error: internal error: unable to execute QEMU command 'drive-mirror': Could not open '/var/lib/nova/instances/snapshots/tmp5DdrIO/236df3e170e64fabaeb3c7601e2d6c47.delta' I had originally discovered this bug using the Tempset test suite while verifying an unrelated OpenStack SRU, but other users are experiencing this in the wild. [Test Case] Deploy an OpenStack cloud based on Ubuntu Saucy and OpenStack Havana, then attempt to snapshot a running instance. The Tempest integration test suite contains a snapshot test case: tempest.api.compute.images.test_images_oneserver.ImagesOneServerTestJSON.test_create_delete_image [1] [Regression Potential] The proposed fix is isolated to the libvirt packaging and simply appends an additional directory exception to the packages apparmor configuration, so that libvirt has appropriate access to the directory used during the process of snapshotting an instance. [1]https://github.com/openstack/tempest/blob/master/tempest/api/compute/images/test_images_oneserver.py#L92 --- Original Bug --- In some cases (not for all instances, just for some) the following error prevents creating the snapshot: 2013-10-25 14:49:30.724 22980 AUDIT nova.compute.manager [req-6e9326d7-64df-40f7-bc81-190ec5234de2 657f1aca48d24eaf9655e0b77b2bc6d9 35b2b08cc3f44a538cf3535043793a2a] [instance: db9c8a72-6ce2-41b7-8f7a-be0be8468667] instance snapshotting 2013-10-25 14:49:30.944 22980 INFO nova.virt.libvirt.driver [req-6e9326d7-64df-40f7-bc81-190ec5234de2 657f1aca48d24eaf9655e0b77b2bc6d9 35b2b08cc3f44a538cf3535043793a2a] [instance: db9c8a72-6ce2-41b7-8f7a-be0be8468667] Beginning live snapshot process 2013-10-25 14:49:32.006 22980 INFO nova.virt.libvirt.driver [req-6e9326d7-64df-40f7-bc81-190ec5234de2 657f1aca48d24eaf9655e0b77b2bc6d9 35b2b08cc3f44a538cf3535043793a2a] [instance: db9c8a72-6ce2-41b7-8f7a-be0be8468667] Snapshot extracted, beginning image upload 2013-10-25 14:49:32.329 22980 ERROR nova.openstack.common.rpc.amqp [req-6e9326d7-64df-40f7-bc81-190ec5234de2 657f1aca48d24eaf9655e0b77b2bc6d9 35b2b08cc3f44a538cf3535043793a2a] Exception during message handling 2013-10-25 14:49:32.329 22980 TRACE nova.openstack.common.rpc.amqp Traceback (most recent call last): 2013-10-25 14:49:32.329 22980 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/amqp.py, line 461, in _process_data 2013-10-25 14:49:32.329 22980 TRACE nova.openstack.common.rpc.amqp **args) 2013-10-25 14:49:32.329 22980 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/openstack/common/rpc/dispatcher.py, line 172, in dispatch 2013-10-25 14:49:32.329 22980 TRACE nova.openstack.common.rpc.amqp result = getattr(proxyobj, method)(ctxt, **kwargs) 2013-10-25 14:49:32.329 22980 TRACE nova.openstack.common.rpc.amqp File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 353, in decorated_function 2013-10-25 14:49:32.329 22980 TRACE nova.openstack.common.rpc.amqp return
