[Yahoo-eng-team] [Bug 1999582] Re: vm live migration not working when port is admin down
Hi Rodolfo
Thanks for the heads up. I have verified and it seems correct that
neutron openvswitch agent reports the port correctly as "down:
2022-12-13 18:52:49.053 2955524 INFO
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
[req-149353dc-53f3-48ca-97e1-ec4f47dc56e5 - - - - -] Port
6c167efe-3a55-46d1-baf1-4962b3bc387f is being migrated to host
computeXXX.
2022-12-13 18:52:49.053 2955524 INFO
neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent
[req-149353dc-53f3-48ca-97e1-ec4f47dc56e5 - - - - -] Port
6c167efe-3a55-46d1-baf1-4962b3bc387f updated. Details: {'device':
'6c167efe-3a55-46d1-baf1-4962b3bc387f', 'device_id':
'5d270ee8-76aa-46d8-9ebc-09f51de1b5d9', 'network_id':
'4ea4469f-4791-4483-9b10-6b01a0857989', 'port_id':
'6c167efe-3a55-46d1-baf1-4962b3bc387f', 'mac_address':
'fa:16:3e:8c:5c:b8', 'admin_state_up': False, 'status': 'DOWN',
'network_type': 'vlan', 'segmentation_id': 102, 'physical_network':
'provider', 'fixed_ips': [{'subnet_id':
'a2831e83-8a5a-4f02-ae09-2eb674089026', 'ip_address': '185.XXX.XX.X'}],
'device_owner': 'compute:X', 'allowed_address_pairs': [],
'port_security_enabled': True, 'qos_policy_id': None,
'network_qos_policy_id': None, 'profile': {'os_vif_delegation': True,
'migrating_to': 'computeXXX'}, 'vif_type': 'ovs', 'vnic_type': 'normal',
'security_groups': ['4096f1f0-094a-4f7d-b539-8cb387f70763'],
'migrating_to': 'computeXXX'}
This leads me to think that there is a problem in nova that does not correctly
handle the "admin port down" case when doing live migrations. Therefore i have
added nova as affected project to this bug report. It would be great to have
somebody from nova verify this.
** Also affects: nova
Importance: Undecided
Status: New
** Tags added: live-migration
--
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/1999582
Title:
vm live migration not working when port is admin down
Status in neutron:
Invalid
Status in OpenStack Compute (nova):
New
Bug description:
having a vm with a provider network port that has it's status set to
"admin down" won't let this vm migrate successfully. the source
compute host will abort the migration with the following message:
Timed out waiting for events: [('network-vif-plugged',
'8066f303-a72c-4784-9fc0-de5f7d8a993f'), ('network-vif-plugged',
'6c167efe-3a55-46d1-baf1-4962b3bc387f')]. If these timeouts are a
persistent issue it could mean the networking backend on host
computeXXX does not support sending these events unless there are port
binding host changes which does not happen at this point in the live
migration process. You may need to disable the
live_migration_wait_for_vif_plug option on host computeXXX.:
eventlet.timeout.Timeout: 300 seconds
setting the port admin status up and re-running the life migration let
the vm successfully complete. Therefore the logic for the
live_migration_wait_for_vif_plug settings should be adjusted to take
into consideration if a port should be up or not.
Environment:
- Ubuntu 20.04.5 with Cloud Archive Repositories in version
19.4.0-0ubuntu1~cloud0 on Xena branch
- Using ML2 with OVS on physical provider network
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1999582/+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 1999582] [NEW] vm live migration not working when port is admin down
Public bug reported:
having a vm with a provider network port that has it's status set to
"admin down" won't let this vm migrate successfully. the source compute
host will abort the migration with the following message:
Timed out waiting for events: [('network-vif-plugged',
'8066f303-a72c-4784-9fc0-de5f7d8a993f'), ('network-vif-plugged',
'6c167efe-3a55-46d1-baf1-4962b3bc387f')]. If these timeouts are a
persistent issue it could mean the networking backend on host computeXXX
does not support sending these events unless there are port binding host
changes which does not happen at this point in the live migration
process. You may need to disable the live_migration_wait_for_vif_plug
option on host computeXXX.: eventlet.timeout.Timeout: 300 seconds
setting the port admin status up and re-running the life migration let
the vm successfully complete. Therefore the logic for the
live_migration_wait_for_vif_plug settings should be adjusted to take
into consideration if a port should be up or not.
Environment:
- Ubuntu 20.04.5 with Cloud Archive Repositories in version
19.4.0-0ubuntu1~cloud0 on Xena branch
- Using ML2 with OVS on physical provider network
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1999582
Title:
vm live migration not working when port is admin down
Status in neutron:
New
Bug description:
having a vm with a provider network port that has it's status set to
"admin down" won't let this vm migrate successfully. the source
compute host will abort the migration with the following message:
Timed out waiting for events: [('network-vif-plugged',
'8066f303-a72c-4784-9fc0-de5f7d8a993f'), ('network-vif-plugged',
'6c167efe-3a55-46d1-baf1-4962b3bc387f')]. If these timeouts are a
persistent issue it could mean the networking backend on host
computeXXX does not support sending these events unless there are port
binding host changes which does not happen at this point in the live
migration process. You may need to disable the
live_migration_wait_for_vif_plug option on host computeXXX.:
eventlet.timeout.Timeout: 300 seconds
setting the port admin status up and re-running the life migration let
the vm successfully complete. Therefore the logic for the
live_migration_wait_for_vif_plug settings should be adjusted to take
into consideration if a port should be up or not.
Environment:
- Ubuntu 20.04.5 with Cloud Archive Repositories in version
19.4.0-0ubuntu1~cloud0 on Xena branch
- Using ML2 with OVS on physical provider network
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1999582/+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 1854236] Re: documentation for cc_set_hostname module doesn't mention runs during "init" phase
** 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/1854236 Title: documentation for cc_set_hostname module doesn't mention runs during "init" phase Status in cloud-init: Fix Released Bug description: (I'm using cloud-init 19.2 under Ubuntu Bionic.) The documentation generated for the cc_set_hostname module (as found e.g. at https://cloudinit.readthedocs.io/en/latest/topics/modules.html#set-hostname ) includes the paragraph: Module frequency: per instance However, looking carefully at the /var/log/cloud-init.log log, I see that the module is actually executed during the "init-local" phase on every boot: 2019-11-20 17:08:08,364 - util.py[DEBUG]: Cloud-init v. 19.2-36-g059d049c-0ubuntu2~18.04.1 running 'init-local' at Wed, 20 Nov 2019 17:08:08 +. Up 30.32 seconds. [...] 2019-11-20 17:08:08,411 - handlers.py[DEBUG]: start: init-local/check-cache: attempting to read from cache [check] [...] 2019-11-20 17:08:08,588 - handlers.py[DEBUG]: finish: init-local/check-cache: SUCCESS: restored from checked cache: DataSourceNoCloud [seed=/var/lib/cloud/seed/nocloud-net][dsmode=net] [...] 2019-11-20 17:08:08,849 - cc_set_hostname.py[DEBUG]: Setting the hostname to diggle.doxpop.com (bionic) 2019-11-20 17:08:08,849 - util.py[DEBUG]: Reading from /etc/hostname (quiet=False) 2019-11-20 17:08:08,849 - util.py[DEBUG]: Read 7 bytes from /etc/hostname 2019-11-20 17:08:08,850 - util.py[DEBUG]: Writing to /etc/hostname - wb: [644] 7 bytes 2019-11-20 17:08:08,851 - __init__.py[DEBUG]: Non-persistently setting the system hostname to bionic 2019-11-20 17:08:08,851 - util.py[DEBUG]: Running command ['hostname', 'bionic'] with allowed return codes [0] (shell=False, capture=True) 2019-11-20 17:08:08,908 - atomic_helper.py[DEBUG]: Atomically writing to file /var/lib/cloud/data/set-hostname (via temporary file /var/lib/cloud/data/tmp8p193ijc) - w: [644] 56 bytes/chars with allowed return codes [0] (shell=False, capture=True) [...] 2019-11-20 17:08:08,932 - handlers.py[DEBUG]: finish: init-local: SUCCESS: searching for local datasources This is because cmd/main.py:main_init() calls cc_set_hostname (via the _maybe_set_hostname() function) without checking the per-instance semaphore status. Based on the comments in main_init(), it looks like there are good reasons that the hostname gets updated on every boot... but currently the behavior does not match the cc_set_hostname documentation (and in particular, it overwrites a manually-changed /etc/hostname upon reboot even when the instance id is not changed). I'm not sure exactly how this should be worded, but it would be nice if the documentation included an explanation of exactly when the cc_set_hostname module is called. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1854236/+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 1716868] Re: config file is not read
** Also affects: cloud-archive Importance: Undecided Status: New -- 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/1716868 Title: config file is not read Status in Ubuntu Cloud Archive: New Status in OpenStack Dashboard (Horizon): Invalid Bug description: we are running horizon on an Ubuntu 16 cluster with the official repos for the new pike release and figured out that the configuration file /etc/openstack-dashboard/local_settings.py is no longer read. it seems the symlink /usr/share/openstack- dashboard/openstack_dashboard/local/local_settings.py is no longer working. we removed that symlink and copied the file directly into /usr/share/openstack-dashboard/openstack_dashboard/local/ which seems to help for the moment. installed package: python-django-horizon - 3:12.0.0-0ubuntu1~cloud0 OS: Ubuntu 16.04.3 LTS apache virtual host config: http://paste.openstack.org/show/621008/ file permissions: -rw-r--r-- 1 root horizon 34573 Sep 13 10:01 /etc/openstack-dashboard/local_settings.py To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1716868/+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 1575938] Re: Instance path in / if instance-id starts with '/'
** 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/1575938 Title: Instance path in / if instance-id starts with '/' 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 Bug description: A cloud using the Ec2 datasource has an instance-id metadata value in the form: /Compute-$TENANT/$CLOUDUSERNAME/$UUID The leading '/' causes /var/lib/cloud/instance to link to /Compute-$TENANT/$CLOUDUSERNAME/$UUID rather than /var/lib/cloud/instances/Compute-$TENANT/$CLOUDUSERNAME/$UUID To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1575938/+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 1766856] Re: wrong eni_path for debian
** 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/1766856 Title: wrong eni_path for debian Status in cloud-init: Fix Released Bug description: eni_path for debian is configured as /etc/network/interfaces.d/50 -cloud-init.cfg, but the file doesn't get used by ifupdown. According to the interfaces manpage, the filename has to match ^[a-zA-Z0-9_-]+$. It works when the extension .cfg is removed. I'm using DataSourceNoCloud with a Networking Config Version 1. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1766856/+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 1855432] [NEW] module cc_apt_configure must make sure gnupg is installed
Public bug reported: when using the module cc_apt_configure we need to make sure that gnupg is installed before using apt-key add to add a certain apt key. The most recent debian 10 cloud image from https://cdimage.debian.org/cdimage/openstack/10.2.0/ is for example not really happy when using the below config: #cloud-config apt: http_proxy: http://proxy.hostpoint.internal:3128/ https_proxy: http://proxy.hostpoint.internal:3128/ sources: saltstack: source: "deb http://repo.saltstack.com/py3/debian/10/amd64/latest buster main" key: | -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v2 mQENBFOpvpgBCADkP656H41i8fpplEEB8IeLhugyC2rTEwwSclb8tQNYtUiGdna9 m38kb0OS2DDrEdtdQb2hWCnswxaAkUunb2qq18vd3dBvlnI+C4/xu5ksZZkRj+fW tArNR18V+2jkwcG26m8AxIrT+m4M6/bgnSfHTBtT5adNfVcTHqiT1JtCbQcXmwVw WbqS6v/LhcsBE//SHne4uBCK/GHxZHhQ5jz5h+3vWeV4gvxS3Xu6v1IlIpLDwUts kT1DumfynYnnZmWTGc6SYyIFXTPJLtnoWDb9OBdWgZxXfHEcBsKGha+bXO+m2tHA gNneN9i5f8oNxo5njrL8jkCckOpNpng18BKXABEBAAG0MlNhbHRTdGFjayBQYWNr YWdpbmcgVGVhbSA8cGFja2FnaW5nQHNhbHRzdGFjay5jb20+iQE4BBMBAgAiBQJT qb6YAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAOCKFJ3le/vhkqB/0Q WzELZf4d87WApzolLG+zpsJKtt/ueXL1W1KA7JILhXB1uyvVORt8uA9FjmE083o1 yE66wCya7V8hjNn2lkLXboOUd1UTErlRg1GYbIt++VPscTxHxwpjDGxDB1/fiX2o nK5SEpuj4IeIPJVE/uLNAwZyfX8DArLVJ5h8lknwiHlQLGlnOu9ulEAejwAKt9CU 4oYTszYM4xrbtjB/fR+mPnYh2fBoQO4d/NQiejIEyd9IEEMd/03AJQBuMux62tjA /NwvQ9eqNgLw9NisFNHRWtP4jhAOsshv1WW+zPzu3ozoO+lLHixUIz7fqRk38q8Q 9oNR31KvrkSNrFbA3D89uQENBFOpvpgBCADJ79iH10AfAfpTBEQwa6vzUI3Eltqb 9aZ0xbZV8V/8pnuU7rqM7Z+nJgldibFk4gFG2bHCG1C5aEH/FmcOMvTKDhJSFQUx uhgxttMArXm2c22OSy1hpsnVG68G32Nag/QFEJ++3hNnbyGZpHnPiYgej3FrerQJ zv456wIsxRDMvJ1NZQB3twoCqwapC6FJE2hukSdWB5yCYpWlZJXBKzlYz/gwD/Fr GL578WrLhKw3UvnJmlpqQaDKwmV2s7MsoZogC6wkHE92kGPG2GmoRD3ALjmCvN1E PsIsQGnwpcXsRpYVCoW7e2nW4wUf7IkFZ94yOCmUq6WreWI4NggRcFC5ABEBAAGJ AR8EGAECAAkFAlOpvpgCGwwACgkQDgihSd5Xv74/NggA08kEdBkiWWwJZUZEy7cK WWcgjnRuOHd4rPeT+vQbOWGu6x4bxuVf9aTiYkf7ZjVF2lPn97EXOEGFWPZeZbH4 vdRFH9jMtP+rrLt6+3c9j0M8SIJYwBL1+CNpEC/BuHj/Ra/cmnG5ZNhYebm76h5f T9iPW9fFww36FzFka4VPlvA4oB7ebBtquFg3sdQNU/MmTVV4jPFWXxh4oRDDR+8N 1bcPnbB11b5ary99F/mqr7RgQ+YFF0uKRE3SKa7a+6cIuHEZ7Za+zhPaQlzAOZlx fuBmScum8uQTrEF5+Um5zkwC7EXTdH1co/+/V/fpOtxIg4XO4kcugZefVm5ERfVS MA== =dtMN -END PGP PUBLIC KEY BLOCK- It will then throw the following errors: [ 21.870823] cloud-init[494]: 2019-12-06 11:26:16,967 - cc_apt_configure.py[ERROR]: failed to add apt GPG Key to apt keyring [ 21.875126] cloud-init[494]: Traceback (most recent call last): [ 21.877629] cloud-init[494]: File "/usr/lib/python3/dist-packages/cloudinit/config/cc_apt_configure.py", line 551, in add_apt_key_raw [ 21.881435] cloud-init[494]: util.subp(['apt-key', 'add', '-'], data=key.encode(), target=target) [ 21.884155] cloud-init[494]: File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2027, in subp [ 21.886831] cloud-init[494]: cmd=args) [ 21.888611] cloud-init[494]: cloudinit.util.ProcessExecutionError: Unexpected error while running command. [ 21.891311] cloud-init[494]: Command: ['apt-key', 'add', '-'] [ 21.893090] cloud-init[494]: Exit code: 255 [ 21.894566] cloud-init[494]: Reason: - [ 21.895819] cloud-init[494]: Stdout: [ 21.897109] cloud-init[494]: Stderr: E: gnupg, gnupg2 and gnupg1 do not seem to be installed, but one of them is required for this operation [ 21.899870] cloud-init[494]: 2019-12-06 11:26:16,973 - util.py[WARNING]: Running module apt-configure () failed ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1855432 Title: module cc_apt_configure must make sure gnupg is installed Status in cloud-init: New Bug description: when using the module cc_apt_configure we need to make sure that gnupg is installed before using apt-key add to add a certain apt key. The most recent debian 10 cloud image from https://cdimage.debian.org/cdimage/openstack/10.2.0/ is for example not really happy when using the below config: #cloud-config apt: http_proxy: http://proxy.hostpoint.internal:3128/ https_proxy: http://proxy.hostpoint.internal:3128/ sources: saltstack: source: "deb http://repo.saltstack.com/py3/debian/10/amd64/latest buster main" key: | -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG
[Yahoo-eng-team] [Bug 1380424] Re: Missing Mock in test_simple_write_freebsd
** Tags added: freebsd
** 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/1380424
Title:
Missing Mock in test_simple_write_freebsd
Status in cloud-init:
Fix Released
Bug description:
When running the test suite on a Gentoo box (barebones) the following
failure occurs:
==
FAIL: test_simple_write_freebsd
(tests.unittests.test_distros.test_netconfig.TestNetCfgDistro)
--
Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/mocker.py", line 149, in
test_method_wrapper
result = test_method()
File
"/var/tmp/portage/app-emulation/cloud-init-0.7.6/work/cloud-init-0.7.6/tests/unittests/test_distros/test_netconfig.py",
line 230, in test_simple_write_freebsd
self.assertCfgEquals(expected_buf, str(write_buf))
File
"/var/tmp/portage/app-emulation/cloud-init-0.7.6/work/cloud-init-0.7.6/tests/unittests/test_distros/test_netconfig.py",
line 90, in assertCfgEquals
self.assertEquals(b1, b2)
AssertionError: {'ifconfig_vtnet0': '192.168.1.5 netmask 255.255.255.0',
'ifconfig_vtnet1': 'DHC [truncated]... != {'ifconfig_eth0': '192.168.1.5
netmask 255.255.255.0', 'ifconfig_eth1': 'DHCP', [truncated]...
{'defaultrouter': '192.168.1.254',
- 'ifconfig_vtnet0': '192.168.1.5 netmask 255.255.255.0',
?---
+ 'ifconfig_eth0': '192.168.1.5 netmask 255.255.255.0',
? +
- 'ifconfig_vtnet1': 'DHCP'}
?---
+ 'ifconfig_eth1': 'DHCP'}
? +
>> begin captured logging <<
cloudinit.distros.freebsd: DEBUG: Translating network interface eth1
cloudinit.util: DEBUG: Running command ['ifconfig', '-a'] with allowed return
codes [0] (shell=False, capture=True)
cloudinit.distros.freebsd: DEBUG: Using network interface eth1
cloudinit.distros.freebsd: INFO: Configuring interface eth1
cloudinit.distros.freebsd: DEBUG: Checking /etc/rc.conf for: ifconfig_eth1 =
DHCP
cloudinit.distros.freebsd: DEBUG: Adding key in /etc/rc.conf: ifconfig_eth1 =
DHCP
cloudinit.distros.freebsd: INFO: Writing /etc/rc.conf
cloudinit.distros.freebsd: DEBUG: Translating network interface eth0
cloudinit.util: DEBUG: Running command ['ifconfig', '-a'] with allowed return
codes [0] (shell=False, capture=True)
cloudinit.distros.freebsd: DEBUG: Using network interface eth0
cloudinit.distros.freebsd: INFO: Configuring interface eth0
cloudinit.distros.freebsd: DEBUG: Configuring dev eth0 with 192.168.1.5 /
255.255.255.0
cloudinit.distros.freebsd: DEBUG: Checking /etc/rc.conf for: defaultrouter =
192.168.1.254
cloudinit.distros.freebsd: DEBUG: Adding key in /etc/rc.conf: defaultrouter =
192.168.1.254
cloudinit.distros.freebsd: INFO: Writing /etc/rc.conf
cloudinit.distros.freebsd: DEBUG: Checking /etc/rc.conf for: ifconfig_eth0 =
192.168.1.5 netmask 255.255.255.0
cloudinit.distros.freebsd: DEBUG: Adding key in /etc/rc.conf: ifconfig_eth0 =
192.168.1.5 netmask 255.255.255.0
cloudinit.distros.freebsd: INFO: Writing /etc/rc.conf
cloudinit.distros.freebsd: WARNING: Failed to parse /etc/resolv.conf, use new
empty file
cloudinit.distros.freebsd: DEBUG: Failed to parse /etc/resolv.conf, use new
empty file
Traceback (most recent call last):
File
"/var/tmp/portage/app-emulation/cloud-init-0.7.6/work/cloud-init-0.7.6-python2_7/lib/cloudinit/distros/freebsd.py",
line 309, in _write_network
resolvconf = ResolvConf(util.load_file(self.resolv_conf_fn))
File "/usr/lib64/python2.7/site-packages/mocker.py", line 1223, in __call__
return self.__mocker_act__("call", args, kwargs)
File "/usr/lib64/python2.7/site-packages/mocker.py", line 1184, in
__mocker_act__
return self.__mocker__.act(path)
File "/usr/lib64/python2.7/site-packages/mocker.py", line 847, in act
return event.run(path)
File "/usr/lib64/python2.7/site-packages/mocker.py", line 1694, in run
task_result = task.run(path)
File "/usr/lib64/python2.7/site-packages/mocker.py", line 1962, in run
return self._func(*action.args, **action.kwargs)
File
"/var/tmp/portage/app-emulation/cloud-init-0.7.6/work/cloud-init-0.7.6/tests/unittests/test_distros/test_netconfig.py",
line 206, in replace_read
raise IOError("%s not found" % fname)
IOError: /etc/resolv.conf not found
- >> end captured logging << -
Would it be preferable to mock the interaction with /etc/resolv.conf?
If not, why?
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1380424/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to :
[Yahoo-eng-team] [Bug 1848311] [NEW] trunk + subports not working
Public bug reported: Since upgrading from Rocky to Stein we are experiencing problems live migrating vm's with trunk ports and creating new trunk ports. The live migrations of the vm itself eventually completes but the trunk ports remain in the status "BUILD" or "DOWN". The corresponding subports and/or the parent port are mostly in status "DOWN" too. It looks like not all of the corresponding needed ports get moved from hypervisor host a to host b. Given theses status from the ports it is obvious that the VM is not accessible from the network at all. Most of the time when the migration is about to finish we see such kind of time out messages in the neutron-openvswitch-agent log: 2019-10-14 12:28:56.559 20071 ERROR neutron_lib.rpc [-] Timeout in RPC method trunk.update_subport_bindings. Waiting for 114 seconds before next attempt. If the server is not down, consider increasing the rpc_response_timeout option as Neutron server(s) may be overloaded and unable to respond quickly enough.: oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply to message ID 58a64b2c975143a4bbfd07ab3b10e871 2019-10-14 12:28:56.560 20071 WARNING neutron_lib.rpc [-] Increasing timeout for trunk.update_subport_bindings calls to 240 seconds. Restart the agent to restore it to the default value.: oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply to message ID 58a64b2c975143a4bbfd07ab3b10e871 2019-10-14 12:28:56.562 20071 ERROR neutron_lib.rpc [-] Timeout in RPC method trunk.update_subport_bindings. Waiting for 56 seconds before next attempt. If the server is not down, consider increasing the rpc_response_timeout option as Neutron server(s) may be overloaded and unable to respond quickly enough.: oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply to message ID c1e5f0b50f044c8ea1f40f3e2e959fc0 2019-10-14 12:29:53.021 20071 ERROR neutron.services.trunk.drivers.openvswitch.agent.ovsdb_handler [-] Got messaging error while processing trunk bridge tbr-e4685a7d-2: Timed out waiting for a reply to message ID c1e5f0b50f044c8ea1f40f3e2e959fc0: oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply to message ID c1e5f0b50f044c8ea1f40f3e2e959fc0 2019-10-14 12:30:24.896 20071 ERROR neutron_lib.rpc [req-85c86e08-52a3-4199-a1af-915f4847e9fc cd9715e9b4714bc6b4d77f15f12ba5a9 1e205eb2989a4beb9ef5947abff00b35 - - -] Timeout in RPC method trunk.update_trunk_status. Waiting for 75 seconds before next attempt. If the server is not down, consider increasing the rpc_response_timeout option as Neutron server(s) may be overloaded and unable to respond quickly enough.: oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply to message ID 8093a1090d47426380434e65559875e5 2019-10-14 12:30:24.896 20071 WARNING neutron_lib.rpc [req-85c86e08-52a3-4199-a1af-915f4847e9fc cd9715e9b4714bc6b4d77f15f12ba5a9 1e205eb2989a4beb9ef5947abff00b35 - - -] Increasing timeout for trunk.update_trunk_status calls to 240 seconds. Restart the agent to restore it to the default value.: oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply to message ID 8093a1090d47426380434e65559875e5 2019-10-14 12:30:50.133 20071 ERROR neutron.services.trunk.drivers.openvswitch.agent.ovsdb_handler [-] Got messaging error while processing trunk bridge tbr-b56178af-8: Timed out waiting for a reply to message ID 58a64b2c975143a4bbfd07ab3b10e871: oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply to message ID 58a64b2c975143a4bbfd07ab3b10e871 2019-10-14 12:31:39.851 20071 ERROR neutron.services.trunk.drivers.openvswitch.agent.driver [req-85c86e08-52a3-4199-a1af-915f4847e9fc cd9715e9b4714bc6b4d77f15f12ba5a9 1e205eb2989a4beb9ef5947abff00b35 - - -] Error on event deleted for subports [SubPort(port_id=c048169f-a005-44a3-88e3-03a34d778bb5,segmentation_id=843,segmentation_type='vlan',trunk_id=b56178af-8d6f-4660-ac3b-cc469c3de4ce)]: Timed out waiting for a reply to message ID 8093a1090d47426380434e65559875e5: oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply to message ID 8093a1090d47426380434e65559875e5 2019-10-14 12:35:26.906 20071 ERROR neutron_lib.rpc [req-e7ac3037-3598-4003-90db-d59985cf5326 cd9715e9b4714bc6b4d77f15f12ba5a9 1e205eb2989a4beb9ef5947abff00b35 - - -] Timeout in RPC method trunk.update_subport_bindings. Waiting for 53 seconds before next attempt. If the server is not down, consider increasing the rpc_response_timeout option as Neutron server(s) may be overloaded and unable to respond quickly enough.: oslo_messaging.exceptions.MessagingTimeout: Timed out waiting for a reply to message ID b16fcf72d3284439a06f8383a6d04566 2019-10-14 12:35:26.907 20071 WARNING neutron_lib.rpc [req-e7ac3037-3598-4003-90db-d59985cf5326 cd9715e9b4714bc6b4d77f15f12ba5a9 1e205eb2989a4beb9ef5947abff00b35 - - -] Increasing timeout for trunk.update_subport_bindings calls to 480 seconds. Restart the
[Yahoo-eng-team] [Bug 1741575] Re: creating a VM without IP (ip_allocation='none')
** Changed in: nova Assignee: do3meli (d-info-e) => (unassigned) ** Changed in: nova Status: In Progress => Opinion -- 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/1741575 Title: creating a VM without IP (ip_allocation='none') Status in OpenStack Compute (nova): Opinion Bug description: Using latest neutron [1] and python-neutronclient [2], we are now able to create VMs without IP addresses. If I run : $ openstack network create net1 $ openstack port create --network net1 --no-fixed-ip port_net1 I get the IP_allocation field equal to "none" in the neutron database for the created port. So the following command should result in a VM without IP Addresses : $ openstack server create --flavor 1 --image 78ee2490-3b59-4c1f- bc29-cdb878ccfc26 --port port_net1 Instead I have the following error : Port c1013516-8e00-4f99-817d-07edbb386142 requires a FixedIP in order to be used. (HTTP 400) It seems that nova only accepts VMs with deferred ip_allocation [3][4], not "none". Accepting "none" as a valid option for the ip_allocation attribute would implement [5], as [4] was expected to, regarding Matt Riedemann last comment on [5]. [1] https://review.openstack.org/#/c/361455/ [2] https://review.openstack.org/#/c/504817/ [3] http://git.openstack.org/cgit/openstack/nova/tree/nova/network/neutronv2/api.py#n1663 [4] https://review.openstack.org/#/c/299591/ [5] https://review.openstack.org/#/c/239276/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1741575/+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 1846513] [NEW] debian 10 cloud-init stuck in systemd-networkd after 1. reboot
Public bug reported: i have create a virtual machine using the following official debian image: https://cdimage.debian.org/cdimage/openstack/current-10/ they have version 18.3-6 installed. after the initial boot of the vm cloud-init works as it should. but when a reboot occurred it seems to be hanging in networkd-systemd bringing up interfaces. see attached log file. i have also manually upgraded to cloud-init 19.2-1 and that had the same issue. ** Affects: cloud-init Importance: Undecided Status: Incomplete ** Tags: debian ** Attachment added: "vm-boot-log.txt" https://bugs.launchpad.net/bugs/1846513/+attachment/5294014/+files/vm-boot-log.txt -- 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/1846513 Title: debian 10 cloud-init stuck in systemd-networkd after 1. reboot Status in cloud-init: Incomplete Bug description: i have create a virtual machine using the following official debian image: https://cdimage.debian.org/cdimage/openstack/current-10/ they have version 18.3-6 installed. after the initial boot of the vm cloud-init works as it should. but when a reboot occurred it seems to be hanging in networkd-systemd bringing up interfaces. see attached log file. i have also manually upgraded to cloud-init 19.2-1 and that had the same issue. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1846513/+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 1833041] [NEW] importing a keypair when keypair limit is reached will logout user
Public bug reported: when importing a keypair via horizon gui while the corresponding project quota limit is reached will automatically logout the current user and redirect him to the login screen. this has been testet with version openstack rocky on ubuntu 18 with the cloud archive repository. exact package: 3:14.0.2-0ubuntu2~cloud0 ** Affects: horizon Importance: Undecided Status: New -- 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/1833041 Title: importing a keypair when keypair limit is reached will logout user Status in OpenStack Dashboard (Horizon): New Bug description: when importing a keypair via horizon gui while the corresponding project quota limit is reached will automatically logout the current user and redirect him to the login screen. this has been testet with version openstack rocky on ubuntu 18 with the cloud archive repository. exact package: 3:14.0.2-0ubuntu2~cloud0 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1833041/+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 1815030] [NEW] FreeBSD: Unable to determine distribution
Public bug reported: The util.py currently is not so FreeBSD friendly as it always prints the following warnings: 2019-02-07 11:02:02,324 - util.py[WARNING]: Unable to determine distribution, template expansion may have unexpected results This is obviously getting printed for each stage and most likely due to the fact that the get_linux_distro() function is getting called for FreeBSD. We might should change that function so it will also handle the FreeBSD case and not fail. I did not further trace this back so it might be that it should not even call the get_linux_distro() and use another method as it is not really a Linux. ** Affects: cloud-init Importance: Undecided Status: New ** Tags: freebsd ** Tags added: freebsd -- 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/1815030 Title: FreeBSD: Unable to determine distribution Status in cloud-init: New Bug description: The util.py currently is not so FreeBSD friendly as it always prints the following warnings: 2019-02-07 11:02:02,324 - util.py[WARNING]: Unable to determine distribution, template expansion may have unexpected results This is obviously getting printed for each stage and most likely due to the fact that the get_linux_distro() function is getting called for FreeBSD. We might should change that function so it will also handle the FreeBSD case and not fail. I did not further trace this back so it might be that it should not even call the get_linux_distro() and use another method as it is not really a Linux. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1815030/+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 1811076] [NEW] remove send_arp_for_ha in nova sample Configuration File
Public bug reported: The sample nova configuration file is most likely inaccurate as it still references send_arp_for_ha and send_arp_for_ha_count which in my opinion has been removed in pike release: https://docs.openstack.org/releasenotes/neutron/pike.html this needs to be confirmed and if valid should be fixed in the following branches: * pike * queens * rocky * stein * master --- Release: 18.1.1.dev26 on 2019-01-09 02:42 SHA: 380c4bcfab7889e6312eb87d2077277c00cbd0b3 Source: https://git.openstack.org/cgit/openstack/nova/tree/doc/source/configuration/sample-config.rst URL: https://docs.openstack.org/nova/rocky/configuration/sample-config.html ** Affects: nova Importance: Undecided Status: New ** Tags: doc -- 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/1811076 Title: remove send_arp_for_ha in nova sample Configuration File Status in OpenStack Compute (nova): New Bug description: The sample nova configuration file is most likely inaccurate as it still references send_arp_for_ha and send_arp_for_ha_count which in my opinion has been removed in pike release: https://docs.openstack.org/releasenotes/neutron/pike.html this needs to be confirmed and if valid should be fixed in the following branches: * pike * queens * rocky * stein * master --- Release: 18.1.1.dev26 on 2019-01-09 02:42 SHA: 380c4bcfab7889e6312eb87d2077277c00cbd0b3 Source: https://git.openstack.org/cgit/openstack/nova/tree/doc/source/configuration/sample-config.rst URL: https://docs.openstack.org/nova/rocky/configuration/sample-config.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1811076/+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 1777129] Re: live migration doc says "convergence" while config uses "converge"
** Changed in: nova/pike Status: Fix Committed => Fix Released ** Changed in: nova Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1777129 Title: live migration doc says "convergence" while config uses "converge" Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) pike series: Fix Released Bug description: The documentation mentions the configuration option live_migration_permit_auto_convergence while the actual config file uses live_migration_permit_auto_converge. There seems to be some spelling issues in the titles + text + config options. --- Release: 16.1.4.dev15 on 2018-06-04 05:37 SHA: 2c9c4a09cb5fd31ccff368315534eaa788e90e67 Source: https://git.openstack.org/cgit/openstack/nova/tree/doc/source/admin/live-migration-usage.rst URL: https://docs.openstack.org/nova/pike/admin/live-migration-usage.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1777129/+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 1804016] [NEW] gui not showing attached ports without ip
Public bug reported: in the instance overview under either admin or project one does not see attached ports that do no have an IP address set. for example: 1. create a port with following command: openstack port create --network --no-fixed-ip test-port --project my-project 2. attach the port to a vm now there is no way to see attached ports without ip address in the detail view of an instance. ** Affects: horizon Importance: Undecided Status: New -- 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/1804016 Title: gui not showing attached ports without ip Status in OpenStack Dashboard (Horizon): New Bug description: in the instance overview under either admin or project one does not see attached ports that do no have an IP address set. for example: 1. create a port with following command: openstack port create --network --no-fixed-ip test-port --project my-project 2. attach the port to a vm now there is no way to see attached ports without ip address in the detail view of an instance. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1804016/+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 1797053] [NEW] UI: not showing IPv6 in instance overview of admin context
Public bug reported: We usually have 2 interfaces/ports per VM. 1 internal and 1 external interface/port. On the external interface/port we do have 2 static IP addresses assigned. one of them is an IPv4 and the other an IPv6. However we do only see the IPv4 being shown in the instance overview of the admin context. On the other hand when switching to the instance view of the project context we can see both addresses. ** Affects: horizon Importance: Undecided Status: New -- 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/1797053 Title: UI: not showing IPv6 in instance overview of admin context Status in OpenStack Dashboard (Horizon): New Bug description: We usually have 2 interfaces/ports per VM. 1 internal and 1 external interface/port. On the external interface/port we do have 2 static IP addresses assigned. one of them is an IPv4 and the other an IPv6. However we do only see the IPv4 being shown in the instance overview of the admin context. On the other hand when switching to the instance view of the project context we can see both addresses. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1797053/+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 1781916] Re: nova-compute version cap leads to ValueError
attached is the full stacktrace of the compute node. ** Attachment added: "cap_stacktrace.txt" https://bugs.launchpad.net/nova/+bug/1781916/+attachment/5164744/+files/cap_stacktrace.txt ** Changed in: nova Status: Invalid => New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1781916 Title: nova-compute version cap leads to ValueError Status in OpenStack Compute (nova): New Bug description: Setting the following config on a compute host leads to a Stacktrace. [upgrade_levels] compute = auto cells = auto intercell = auto cert = auto scheduler = auto conductor = auto console = auto consoleauth = auto network = auto baseapi = auto Stacktrace: 2018-07-16 14:02:39.011 474 ERROR nova File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line 119, in _check_version_cap 2018-07-16 14:02:39.011 474 ERROR nova if not utils.version_is_compatible(self.version_cap, version): 2018-07-16 14:02:39.011 474 ERROR nova File "/usr/lib/python2.7/dist-packages/oslo_messaging/_utils.py", line 40, in version_is_compatible 2018-07-16 14:02:39.011 474 ERROR nova if int(version_parts[0]) != int(imp_version_parts[0]): # Major 2018-07-16 14:02:39.011 474 ERROR nova ValueError: invalid literal for int() with base 10: 'auto' The same setting on a controller node works fine. Is it not supposed to use these version caps on a compute node or is this simply a bug in the code? # nova-compute --version 17.0.4 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1781916/+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 1781916] [NEW] nova-compute version cap leads to ValueError
Public bug reported: Setting the following config on a compute host leads to a Stacktrace. [upgrade_levels] compute = auto cells = auto intercell = auto cert = auto scheduler = auto conductor = auto console = auto consoleauth = auto network = auto baseapi = auto Stacktrace: 2018-07-16 14:02:39.011 474 ERROR nova File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line 119, in _check_version_cap 2018-07-16 14:02:39.011 474 ERROR nova if not utils.version_is_compatible(self.version_cap, version): 2018-07-16 14:02:39.011 474 ERROR nova File "/usr/lib/python2.7/dist-packages/oslo_messaging/_utils.py", line 40, in version_is_compatible 2018-07-16 14:02:39.011 474 ERROR nova if int(version_parts[0]) != int(imp_version_parts[0]): # Major 2018-07-16 14:02:39.011 474 ERROR nova ValueError: invalid literal for int() with base 10: 'auto' The same setting on a controller node works fine. Is it not supposed to use these version caps on a compute node or is this simply a bug in the code? # nova-compute --version 17.0.4 ** Affects: nova Importance: Undecided Status: New ** Summary changed: - nova-compute version cap leds to ValueError + nova-compute version cap leads to ValueError -- 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/1781916 Title: nova-compute version cap leads to ValueError Status in OpenStack Compute (nova): New Bug description: Setting the following config on a compute host leads to a Stacktrace. [upgrade_levels] compute = auto cells = auto intercell = auto cert = auto scheduler = auto conductor = auto console = auto consoleauth = auto network = auto baseapi = auto Stacktrace: 2018-07-16 14:02:39.011 474 ERROR nova File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line 119, in _check_version_cap 2018-07-16 14:02:39.011 474 ERROR nova if not utils.version_is_compatible(self.version_cap, version): 2018-07-16 14:02:39.011 474 ERROR nova File "/usr/lib/python2.7/dist-packages/oslo_messaging/_utils.py", line 40, in version_is_compatible 2018-07-16 14:02:39.011 474 ERROR nova if int(version_parts[0]) != int(imp_version_parts[0]): # Major 2018-07-16 14:02:39.011 474 ERROR nova ValueError: invalid literal for int() with base 10: 'auto' The same setting on a controller node works fine. Is it not supposed to use these version caps on a compute node or is this simply a bug in the code? # nova-compute --version 17.0.4 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1781916/+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 1779672] [NEW] netdev_pformat key error on FreeBSD with 18.3
Public bug reported:
i am running cloud-init on commit id
c42a926ae730994f66fe87c264b65f6e4dca69a1 against a FreeBSD 10.4 Host an
getting the following stacktrace:
2018-07-02 11:40:18,158 - util.py[DEBUG]: Cloud-init v. 18.3 running 'init' at
Mon, 02 Jul 2018 11:40:18 +. Up 20.11459589 seconds.
2018-07-02 11:40:18,159 - main.py[DEBUG]: No kernel command line url found.
2018-07-02 11:40:18,159 - main.py[DEBUG]: Closing stdin.
2018-07-02 11:40:18,172 - util.py[DEBUG]: Writing to /var/log/cloud-init.log -
ab: [644] 0 bytes
2018-07-02 11:40:18,175 - util.py[DEBUG]: Changing the ownership of
/var/log/cloud-init.log to 0:0
2018-07-02 11:40:18,175 - util.py[DEBUG]: Running command ['ifconfig', '-a']
with allowed return codes [0, 1] (shell=False, capture=True)
2018-07-02 11:40:18,195 - util.py[WARNING]: failed stage init
2018-07-02 11:40:18,196 - util.py[DEBUG]: failed stage init
Traceback (most recent call last):
File
"/usr/local/lib/python2.7/site-packages/cloud_init-18.3-py2.7.egg/cloudinit/cmd/main.py",
line 655, in status_wrapper
ret = functor(name, args)
File
"/usr/local/lib/python2.7/site-packages/cloud_init-18.3-py2.7.egg/cloudinit/cmd/main.py",
line 284, in main_init
sys.stderr.write("%s\n" % (netinfo.debug_info()))
File
"/usr/local/lib/python2.7/site-packages/cloud_init-18.3-py2.7.egg/cloudinit/netinfo.py",
line 447, in debug_info
netdev_lines = netdev_pformat().splitlines()
File
"/usr/local/lib/python2.7/site-packages/cloud_init-18.3-py2.7.egg/cloudinit/netinfo.py",
line 392, in netdev_pformat
(dev, data["up"], addr["ip"], empty, addr["scope6"],
KeyError: 'scope6'
2018-07-02 11:40:18,204 - util.py[DEBUG]: cloud-init mode 'init' took 0.142
seconds (0.14)
2018-07-02 11:40:18,205 - handlers.py[DEBUG]: finish: init-network: SUCCESS:
searching for network datasources
The interface setup on the host is like:
root@host-10-1-80-61:~ # ifconfig -a
vtnet0: flags=8843 metric 0 mtu 1500
options=6c07bb
ether fa:16:3e:14:1f:99
hwaddr fa:16:3e:14:1f:99
inet 10.1.80.61 netmask 0xf000 broadcast 10.1.95.255
nd6 options=29
media: Ethernet 10Gbase-T
status: active
pflog0: flags=0<> metric 0 mtu 33160
pfsync0: flags=0<> metric 0 mtu 1500
syncpeer: 0.0.0.0 maxupd: 128 defer: off
lo0: flags=8049 metric 0 mtu 16384
options=63
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet 127.0.0.1 netmask 0xff00
nd6 options=21
with previous 18.2 release i did not have any problems.
** Affects: cloud-init
Importance: Undecided
Status: New
** Tags: freebsd
** Tags added: freebsd
--
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/1779672
Title:
netdev_pformat key error on FreeBSD with 18.3
Status in cloud-init:
New
Bug description:
i am running cloud-init on commit id
c42a926ae730994f66fe87c264b65f6e4dca69a1 against a FreeBSD 10.4 Host
an getting the following stacktrace:
2018-07-02 11:40:18,158 - util.py[DEBUG]: Cloud-init v. 18.3 running 'init'
at Mon, 02 Jul 2018 11:40:18 +. Up 20.11459589 seconds.
2018-07-02 11:40:18,159 - main.py[DEBUG]: No kernel command line url found.
2018-07-02 11:40:18,159 - main.py[DEBUG]: Closing stdin.
2018-07-02 11:40:18,172 - util.py[DEBUG]: Writing to /var/log/cloud-init.log
- ab: [644] 0 bytes
2018-07-02 11:40:18,175 - util.py[DEBUG]: Changing the ownership of
/var/log/cloud-init.log to 0:0
2018-07-02 11:40:18,175 - util.py[DEBUG]: Running command ['ifconfig', '-a']
with allowed return codes [0, 1] (shell=False, capture=True)
2018-07-02 11:40:18,195 - util.py[WARNING]: failed stage init
2018-07-02 11:40:18,196 - util.py[DEBUG]: failed stage init
Traceback (most recent call last):
File
"/usr/local/lib/python2.7/site-packages/cloud_init-18.3-py2.7.egg/cloudinit/cmd/main.py",
line 655, in status_wrapper
ret = functor(name, args)
File
"/usr/local/lib/python2.7/site-packages/cloud_init-18.3-py2.7.egg/cloudinit/cmd/main.py",
line 284, in main_init
sys.stderr.write("%s\n" % (netinfo.debug_info()))
File
"/usr/local/lib/python2.7/site-packages/cloud_init-18.3-py2.7.egg/cloudinit/netinfo.py",
line 447, in debug_info
netdev_lines = netdev_pformat().splitlines()
File
"/usr/local/lib/python2.7/site-packages/cloud_init-18.3-py2.7.egg/cloudinit/netinfo.py",
line 392, in netdev_pformat
(dev, data["up"], addr["ip"], empty, addr["scope6"],
KeyError: 'scope6'
2018-07-02 11:40:18,204 - util.py[DEBUG]: cloud-init mode 'init' took 0.142
seconds (0.14)
2018-07-02 11:40:18,205 - handlers.py[DEBUG]: finish: init-network: SUCCESS:
searching for network datasources
The interface setup on the host is like:
root@host-10-1-80-61:~ # ifconfig -a
vtnet0: flags=8843 metric 0 mtu 1500
options=6c07bb
ether
[Yahoo-eng-team] [Bug 1777129] [NEW] live migration doc says "convergence" while config uses "converge"
Public bug reported: The documentation mentions the configuration option live_migration_permit_auto_convergence while the actual config file uses live_migration_permit_auto_converge. There seems to be some spelling issues in the titles + text + config options. --- Release: 16.1.4.dev15 on 2018-06-04 05:37 SHA: 2c9c4a09cb5fd31ccff368315534eaa788e90e67 Source: https://git.openstack.org/cgit/openstack/nova/tree/doc/source/admin/live-migration-usage.rst URL: https://docs.openstack.org/nova/pike/admin/live-migration-usage.html ** Affects: nova Importance: Undecided Status: New ** Tags: doc live-migration -- 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/1777129 Title: live migration doc says "convergence" while config uses "converge" Status in OpenStack Compute (nova): New Bug description: The documentation mentions the configuration option live_migration_permit_auto_convergence while the actual config file uses live_migration_permit_auto_converge. There seems to be some spelling issues in the titles + text + config options. --- Release: 16.1.4.dev15 on 2018-06-04 05:37 SHA: 2c9c4a09cb5fd31ccff368315534eaa788e90e67 Source: https://git.openstack.org/cgit/openstack/nova/tree/doc/source/admin/live-migration-usage.rst URL: https://docs.openstack.org/nova/pike/admin/live-migration-usage.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1777129/+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 1765376] [NEW] nova scheduler log contains html
Public bug reported: Description === The nova scheduler log contains some HTML (see actual result). Log files should not contain any HTML. I suspect some wrong error message parsing here. Actual result = Log Message: 2018-04-19 13:12:53.109 12125 WARNING nova.scheduler.client.report [req-a35b4d7e-9914-48f1-b912-27cedb6eebdd cd9715e9b4714bc6b4d77f15f12ba5a9 fa976f761aad4d378706dfc26ddf6004 - default default] Unable to submit allocation for instance 6dc8e703-1174-499d-aa9b-4d05f83b7784 (409 409 Conflict 409 Conflict There was a conflict when trying to complete your request. Unable to allocate inventory: Unable to create allocation for 'VCPU' on resource provider '322b4b21-f3ff-4d59-b6c8-8c1a9fe2b530'. The requested amount would violate inventory constraints. ) Steps to reproduce == This log line occurred after trying to live-migrate a vm from one node to another. obviously the request failed to do so. Expected result === The log line should be better formatted. for example like this: 2018-04-19 13:12:53.109 12125 WARNING nova.scheduler.client.report [req-a35b4d7e-9914-48f1-b912-27cedb6eebdd cd9715e9b4714bc6b4d77f15f12ba5a9 fa976f761aad4d378706dfc26ddf6004 - default default] Unable to submit allocation for instance 6dc8e703-1174-499d-aa9b-4d05f83b7784 - HTTP Error 409 - There was a conflict when trying to complete your request. Unable to allocate inventory: Unable to create allocation for 'VCPU' on resource provider '322b4b21-f3ff-4d59-b6c8-8c1a9fe2b530'. The requested amount would violate inventory constraints. Environment === Ubuntu 16.04 with the following packages from Ubuntu Cloud Archive: nova-api 2:16.0.4-0ubuntu1~cloud0 nova-common2:16.0.4-0ubuntu1~cloud0 nova-conductor 2:16.0.4-0ubuntu1~cloud0 nova-consoleauth 2:16.0.4-0ubuntu1~cloud0 nova-novncproxy2:16.0.4-0ubuntu1~cloud0 nova-placement-api 2:16.0.4-0ubuntu1~cloud0 nova-scheduler 2:16.0.4-0ubuntu1~cloud0 python-nova2:16.0.4-0ubuntu1~cloud0 python-novaclient 2:9.1.0-0ubuntu1~cloud0 ** Affects: nova Importance: Undecided Status: New ** Description changed: Description === The nova scheduler log contains some HTML (see actual result). Log files should not contain any HTML. I suspect some wrong error message parsing here. + + Actual result + = + Log Message: + + 2018-04-19 13:12:53.109 12125 WARNING nova.scheduler.client.report [req-a35b4d7e-9914-48f1-b912-27cedb6eebdd cd9715e9b4714bc6b4d77f15f12ba5a9 fa976f761aad4d378706dfc26ddf6004 - default default] Unable to submit allocation for instance 6dc8e703-1174-499d-aa9b-4d05f83b7784 (409 + + 409 Conflict + + + 409 Conflict + There was a conflict when trying to complete your request. + Unable to allocate inventory: Unable to create allocation for 'VCPU' on resource provider '322b4b21-f3ff-4d59-b6c8-8c1a9fe2b530'. The requested amount would violate inventory constraints. + + + ) + Steps to reproduce == This log line occurred after trying to live-migrate a vm from one node to another. obviously the request failed to do so. Expected result === The log line should be better formatted. for example like this: 2018-04-19 13:12:53.109 12125 WARNING nova.scheduler.client.report [req-a35b4d7e-9914-48f1-b912-27cedb6eebdd cd9715e9b4714bc6b4d77f15f12ba5a9 fa976f761aad4d378706dfc26ddf6004 - default default] Unable to submit allocation for instance 6dc8e703-1174-499d-aa9b-4d05f83b7784 - HTTP Error 409 - There was a conflict when trying to complete your request. Unable to allocate inventory: Unable to create allocation for 'VCPU' on resource provider '322b4b21-f3ff-4d59-b6c8-8c1a9fe2b530'. The requested amount would violate inventory constraints. - Actual result - = - Log Message: - - 2018-04-19 13:12:53.109 12125 WARNING nova.scheduler.client.report [req-a35b4d7e-9914-48f1-b912-27cedb6eebdd cd9715e9b4714bc6b4d77f15f12ba5a9 fa976f761aad4d378706dfc26ddf6004 - default default] Unable to submit allocation for instance 6dc8e703-1174-499d-aa9b-4d05f83b7784 (409 - - 409 Conflict - - - 409 Conflict - There was a conflict when trying to complete your request. - Unable to allocate inventory: Unable to create allocation for 'VCPU' on resource provider '322b4b21-f3ff-4d59-b6c8-8c1a9fe2b530'. The requested amount would violate inventory constraints. - - - - ) - - Environment === + Ubuntu 16.04 with the following packages from Ubuntu Cloud Archive: - ii nova-api 2:16.0.4-0ubuntu1~cloud0 all OpenStack Compute - API frontend - ii nova-common 2:16.0.4-0ubuntu1~cloud0 all OpenStack Compute -
[Yahoo-eng-team] [Bug 1764729] [NEW] doc: live migration missing part about different cpu models/flags
Public bug reported: - [X] This is a doc addition request. The current live migration documentation [1] and the corresponding configuration guide [2] do not mention any word about the cpu model and flags requirements that are needed in order to successfully live migrate an instance. I believe that it is a crucial piece of information for any openstack administrator to know what prerequisites are needed for it to complete. [1] https://docs.openstack.org/nova/latest/admin/live-migration-usage.html [2] https://docs.openstack.org/nova/latest/admin/configuring-migrations.html#section-configuring-compute-migrations ** Affects: nova Importance: Undecided Status: New ** Tags: doc -- 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/1764729 Title: doc: live migration missing part about different cpu models/flags Status in OpenStack Compute (nova): New Bug description: - [X] This is a doc addition request. The current live migration documentation [1] and the corresponding configuration guide [2] do not mention any word about the cpu model and flags requirements that are needed in order to successfully live migrate an instance. I believe that it is a crucial piece of information for any openstack administrator to know what prerequisites are needed for it to complete. [1] https://docs.openstack.org/nova/latest/admin/live-migration-usage.html [2] https://docs.openstack.org/nova/latest/admin/configuring-migrations.html#section-configuring-compute-migrations To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1764729/+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 1763039] [NEW] evacuate instance documentation not mentioning host-evacuate
Public bug reported: - [X] This is a doc addition request. The current documentation topic "evacuate" in the admin guide is not mentioning the host-evacuate command at all. if one wants to evacuate all instances on a failed host it is easier to use above command. As far as i understand the host-evacuate command will loop over the instances on the failed node and then run each instance against the scheduler so it can be recreated on a different compute node. i suggest to enhance the current documentation with a new section "auto schedule failover host" and move the current part into a section called "manually define failover host". or something like this. --- Release: 17.0.0.0rc2.dev637 on 2018-04-11 13:22 SHA: 80fa0ff912e37890f255bbbcd1c25f26759070ff Source: https://git.openstack.org/cgit/openstack/nova/tree/doc/source/admin/evacuate.rst URL: https://docs.openstack.org/nova/latest/admin/evacuate.html ** Affects: nova Importance: Undecided Status: New ** Tags: doc ** Tags added: doc -- 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/1763039 Title: evacuate instance documentation not mentioning host-evacuate Status in OpenStack Compute (nova): New Bug description: - [X] This is a doc addition request. The current documentation topic "evacuate" in the admin guide is not mentioning the host-evacuate command at all. if one wants to evacuate all instances on a failed host it is easier to use above command. As far as i understand the host-evacuate command will loop over the instances on the failed node and then run each instance against the scheduler so it can be recreated on a different compute node. i suggest to enhance the current documentation with a new section "auto schedule failover host" and move the current part into a section called "manually define failover host". or something like this. --- Release: 17.0.0.0rc2.dev637 on 2018-04-11 13:22 SHA: 80fa0ff912e37890f255bbbcd1c25f26759070ff Source: https://git.openstack.org/cgit/openstack/nova/tree/doc/source/admin/evacuate.rst URL: https://docs.openstack.org/nova/latest/admin/evacuate.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1763039/+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 1412094] Re: Package handling support on FreeBSD
set this to fix released as the current master branch seems to cover the changes linked in the related branch. ** 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/1412094 Title: Package handling support on FreeBSD Status in cloud-init: Fix Released Bug description: cloud-init should support repository metadata updates and package installation/upgrades on FreeBSD. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1412094/+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 1755204] [NEW] make salt minion id more configurable
Public bug reported: per default the salt minion does create the minion_id file with the short hostname if it does not exist on its first startup. in some environments the salt minion id is required to be a fully qualified domain name. therefore i recommend to have a salt minion cloud-config parameter that allows to be set to true/false and based on the value takes the FQDN or the shortname and writes it to the minion_id file. alternatively the minion id could also be fully configurable. meaning: the whole config string is taken and written to the minion_id file. ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1755204 Title: make salt minion id more configurable Status in cloud-init: New Bug description: per default the salt minion does create the minion_id file with the short hostname if it does not exist on its first startup. in some environments the salt minion id is required to be a fully qualified domain name. therefore i recommend to have a salt minion cloud-config parameter that allows to be set to true/false and based on the value takes the FQDN or the shortname and writes it to the minion_id file. alternatively the minion id could also be fully configurable. meaning: the whole config string is taken and written to the minion_id file. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1755204/+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 1754253] [NEW] make integration tests work in other OS
Public bug reported: most of the integration tests are written for ubuntu and have hardcoded paths, service names or package names that may are different on other OS. it would be good to have the possibility to run integration tests in another os than ubuntu. this would as far as i can tell require a lot of tests to be rewritten. but first, there must be an easy way to get os specific variables for a certain module into the test class. for example how could the SaltConstant class being accessed from within the salt_minion.yaml so we don't have to hardcode paths ect. in the collection scripts? ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1754253 Title: make integration tests work in other OS Status in cloud-init: New Bug description: most of the integration tests are written for ubuntu and have hardcoded paths, service names or package names that may are different on other OS. it would be good to have the possibility to run integration tests in another os than ubuntu. this would as far as i can tell require a lot of tests to be rewritten. but first, there must be an easy way to get os specific variables for a certain module into the test class. for example how could the SaltConstant class being accessed from within the salt_minion.yaml so we don't have to hardcode paths ect. in the collection scripts? To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1754253/+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 1753499] [NEW] hostname in FreeBSD should prefere FQDN
Public bug reported: in its current behavior cloud-init does not set the hostname on FreeBSD servers to it's FQDN if it is given. As per [1] FreeBSD Man Page for rc.conf the hostname variable in rc.conf should be set to FQDN. [1] https://www.freebsd.org/cgi/man.cgi?query=rc.conf=5=0=FreeBSD+11.1-RELEASE+and+Ports ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1753499 Title: hostname in FreeBSD should prefere FQDN Status in cloud-init: New Bug description: in its current behavior cloud-init does not set the hostname on FreeBSD servers to it's FQDN if it is given. As per [1] FreeBSD Man Page for rc.conf the hostname variable in rc.conf should be set to FQDN. [1] https://www.freebsd.org/cgi/man.cgi?query=rc.conf=5=0=FreeBSD+11.1-RELEASE+and+Ports To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1753499/+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 1721503] [NEW] salt module not able to be used on FreeBSD
Public bug reported: unfortunately the salt module is not working on FreeBSD as the service name is not salt-minion but instead salt_minion. In addition the package is called differently on freeshports. see: https://www.freshports.org/sysutils/py-salt/ ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1721503 Title: salt module not able to be used on FreeBSD Status in cloud-init: New Bug description: unfortunately the salt module is not working on FreeBSD as the service name is not salt-minion but instead salt_minion. In addition the package is called differently on freeshports. see: https://www.freshports.org/sysutils/py-salt/ To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1721503/+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 1721243] [NEW] cc_resizefs for zfs/zpool
Public bug reported: the resizefs module is not able to handle zfs/zpool resizing for the root filesystem. if tried so we get the error message: "Could not determine filesystem type of /". version: cloud_init-17.1-py2.7.egg ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1721243 Title: cc_resizefs for zfs/zpool Status in cloud-init: New Bug description: the resizefs module is not able to handle zfs/zpool resizing for the root filesystem. if tried so we get the error message: "Could not determine filesystem type of /". version: cloud_init-17.1-py2.7.egg To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1721243/+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 1716868] [NEW] config file is not read
Public bug reported: we are running horizon on an Ubuntu 16 cluster with the official repos for the new pike release and figured out that the configuration file /etc/openstack-dashboard/local_settings.py is no longer read. it seems the symlink /usr/share/openstack- dashboard/openstack_dashboard/local/local_settings.py is no longer working. we removed that symlink and copied the file directly into /usr/share/openstack-dashboard/openstack_dashboard/local/ which seems to help for the moment. installed package: python-django-horizon - 3:12.0.0-0ubuntu1~cloud0 OS: Ubuntu 16.04.3 LTS apache virtual host config: http://paste.openstack.org/show/621008/ file permissions: -rw-r--r-- 1 root horizon 34573 Sep 13 10:01 /etc/openstack-dashboard/local_settings.py ** Affects: horizon Importance: Undecided Status: New -- 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/1716868 Title: config file is not read Status in OpenStack Dashboard (Horizon): New Bug description: we are running horizon on an Ubuntu 16 cluster with the official repos for the new pike release and figured out that the configuration file /etc/openstack-dashboard/local_settings.py is no longer read. it seems the symlink /usr/share/openstack- dashboard/openstack_dashboard/local/local_settings.py is no longer working. we removed that symlink and copied the file directly into /usr/share/openstack-dashboard/openstack_dashboard/local/ which seems to help for the moment. installed package: python-django-horizon - 3:12.0.0-0ubuntu1~cloud0 OS: Ubuntu 16.04.3 LTS apache virtual host config: http://paste.openstack.org/show/621008/ file permissions: -rw-r--r-- 1 root horizon 34573 Sep 13 10:01 /etc/openstack-dashboard/local_settings.py To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1716868/+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
