[Yahoo-eng-team] [Bug 1794534] [NEW] first load of launch instance is missing tabs if LAUNCH_INSTANCE_DEFAULTS.enable_scheduler_hints is False
Public bug reported: If LAUNCH_INSTANCE_DEFAULTS.enable_scheduler_hints = False in local_settings.py, the first time launch instance is used, some tabs are missing. This seems to be intermittent with Chrome browser, but reproducible every time with MS Edge browser. Closing the launch instance dialog, and opening it again almost always results in proper display. Full refresh of the instances page, and clicking the launch instance dialog again reintroduces the issue. It appears that this issue may have been introduced by the code for "Choose a server group when booting a VM with NF Launch instance" https://github.com/openstack/horizon/commit/cf91124d0c97ae80c565ba0b03a41aa2579b998c #diff-925f277526c87432c7733408f990be2f The server group code appears to share some of the scheduler hints code and variables, but there is no LAUNCH_INSTANCE_DEFAULTS configuration option to disable the server group tab. I've been able to reproduce this with a fresh install of RDO packages for Queens on CentOS, with only required environment configuration changes. Not seeing any error messages logged in horizon logs, or javascript errors in the browser. ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "screenshot - missing tabs" https://bugs.launchpad.net/bugs/1794534/+attachment/5193154/+files/missing-tabs.png -- 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/1794534 Title: first load of launch instance is missing tabs if LAUNCH_INSTANCE_DEFAULTS.enable_scheduler_hints is False Status in OpenStack Dashboard (Horizon): New Bug description: If LAUNCH_INSTANCE_DEFAULTS.enable_scheduler_hints = False in local_settings.py, the first time launch instance is used, some tabs are missing. This seems to be intermittent with Chrome browser, but reproducible every time with MS Edge browser. Closing the launch instance dialog, and opening it again almost always results in proper display. Full refresh of the instances page, and clicking the launch instance dialog again reintroduces the issue. It appears that this issue may have been introduced by the code for "Choose a server group when booting a VM with NF Launch instance" https://github.com/openstack/horizon/commit/cf91124d0c97ae80c565ba0b03a41aa2579b998c #diff-925f277526c87432c7733408f990be2f The server group code appears to share some of the scheduler hints code and variables, but there is no LAUNCH_INSTANCE_DEFAULTS configuration option to disable the server group tab. I've been able to reproduce this with a fresh install of RDO packages for Queens on CentOS, with only required environment configuration changes. Not seeing any error messages logged in horizon logs, or javascript errors in the browser. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1794534/+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 1736174] [NEW] update_hostname module fails on CentOS/RHEL with systemd
Public bug reported:
Cloud provider: OpenStack
#cloud-config
hostname: somehostname.somedomain
fqdn: somehostname.somedomain
__init__.py[INFO]: /var/lib/cloud/data/previous-hostname differs from
/etc/hostname, assuming user maintained hostname.
Error message is a little bit misleading, since when uses_systemd(),
/etc/hostname isn't actually read, instead, the result of
util.subp(['hostname']) is used.
Also, this comparison/test will never succeed, because when
uses_systemd() and filename.endswitch('/previous-hostname'), the return
is stripped of cr/lf, however, the result of util.subp(['hostname'])
will contain a lf, and it is not being stripped:
(from rhel.py)
if self.uses_systemd() and filename.endswith('/previous-hostname'):
return util.load_file(filename).strip()
elif self.uses_systemd():
(out, _err) = util.subp(['hostname'])
if len(out):
return out
else:
return default
The simplest solution appears to be to add .strip() to return out; but
this fix may have other implications.
** Affects: cloud-init
Importance: Undecided
Status: New
** Tags: centos rhel
--
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/1736174
Title:
update_hostname module fails on CentOS/RHEL with systemd
Status in cloud-init:
New
Bug description:
Cloud provider: OpenStack
#cloud-config
hostname: somehostname.somedomain
fqdn: somehostname.somedomain
__init__.py[INFO]: /var/lib/cloud/data/previous-hostname differs from
/etc/hostname, assuming user maintained hostname.
Error message is a little bit misleading, since when uses_systemd(),
/etc/hostname isn't actually read, instead, the result of
util.subp(['hostname']) is used.
Also, this comparison/test will never succeed, because when
uses_systemd() and filename.endswitch('/previous-hostname'), the
return is stripped of cr/lf, however, the result of
util.subp(['hostname']) will contain a lf, and it is not being
stripped:
(from rhel.py)
if self.uses_systemd() and filename.endswith('/previous-hostname'):
return util.load_file(filename).strip()
elif self.uses_systemd():
(out, _err) = util.subp(['hostname'])
if len(out):
return out
else:
return default
The simplest solution appears to be to add .strip() to return out; but
this fix may have other implications.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1736174/+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
