Public bug reported:
We found a server that shows up in the output of "openstack server
list":
$ openstack server list | grep 705e3bb6-27a1-4b15-a37b-62f914fc221c
| 705e3bb6-27a1-4b15-a37b-62f914fc221c | 1mg89chr-bc4a8-sh8xn-worker-slpnh
| ERROR |
Public bug reported:
I am booting Ubuntu 18.04 (so, cloud-init 18.4-0ubuntu1~18.04.1) on an
OpenStack managed bare metal server. In order to activate the OpenStack
data source, I have set an explicit data source on the kernel command
line:
# cat /proc/cmdline
Public bug reported:
When deleting a baremetal server, we see:
2019-02-13 12:58:16.856 7 ERROR nova.compute.manager [instance:
dcb4f055-cda4-4d61-ba8f-976645c4e92a] Traceback (most recent call last):
2019-02-13 12:58:16.856 7 ERROR nova.compute.manager [instance:
Public bug reported:
When booting a baremetal server with Nova, we see Ironic report a
successful power on:
ironic-conductor.log:2019-02-13 10:52:15.901 7 INFO
ironic.conductor.utils [req-774350ce-9392-4096-b66c-20ad3d794e4e
7a9b1ac45e084e7cbeb9cb740ffe8d08 41ea8af8d00e46438c7be3b182bbb53f -
gnee: Lars Kellogg-Stedman (larsks)
Status: In Progress
--
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/1807527
Title:
RFE: allow the operator to control which f
Public bug reported:
When looking up a user in a domain, one can generally do this:
openstack user show --domain testdomain testuser
Unfortunately, if testuser is a federated user, the above command will
fail. For example:
$ openstack domain list -c ID -c Name
Public bug reported:
The test_unstable_names test expects cloudinit.util.udevadm_settle to be
called once:
self.assertEqual(1, mock_settle.call_count)
But cloudinit.net.find_fallback_nic inspects /proc/cmdline for the
net.ifnames=0 parameter, and if found will not call udevadm_settle,
which
should be logged at WARNING priority so that it is visible.
** Affects: nova
Importance: Undecided
Assignee: Lars Kellogg-Stedman (larsks)
Status: In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack
Public bug reported:
Nova currently provides nameserver information in network_data.json as a
globally-scoped "services" key. E.g., from
https://specs.openstack.org/openstack/nova-
specs/specs/liberty/implemented/metadata-service-network-info.html#rest-
api-impact:
{
"links": [...],
Public bug reported:
Currently, cloud-init adds nameserver entries directly to
/etc/resolv.conf but does not configure namservers in per-interface
configuration files. This could be problematic because information
received from other sources (e.g., from another interface that is using
dhcp)
Public bug reported:
When running in an environment that provides more than 3 nameservers,
cloud-init will raise a ValueError exception:
Mar 04 18:03:01 localhost.localdomain cloud-init[901]: ValueError:
Adding '8.8.8.8' would go beyond the '3' maximum name servers
While that is a legitimate
Public bug reported:
Given a network configuration that includes ipv4 and ipv6 configuration
for an interface, as in:
"networks": [
{
"id": "public-ipv6",
"ip_address": "2604:A880:0400:00D0:::1714:F001/64",
"link": "interface-public",
Public bug reported:
In cloudinit/net/sysconfig.py, we see:
elif len(iface_subnets) > 1:
for i, iface_subnet in enumerate(iface_subnets,
start=len(iface.children)):
iface_sub_cfg = iface_cfg.copy()
Public bug reported:
I don't know if we care about this or not, since it involves a test
harness other than tox.
Attempting to run the unittests using nosetests (nosetets
tests/unittests) will fail because the _set_mock_metadata method appears
to only run once...so tests that expect non-default
Public bug reported:
cloud-init adds ssh_authorized_keys to the default user fedora and to
root but for root it disables the keys with a prefix command that echoes
the helpful message:
'Please login as the user "fedora" rather than the user "root".'
However, if the key is of type
Public bug reported:
cloud-init sometimes times out and fails to fetch metadata in the
OpenStack environment when the Controller node is under high workload.
The default timeout value is 5 seconds and it may be too small in some
cases where the Controller node is too busy to respond to the
Public bug reported:
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
Public bug reported:
Recent fedora releases use "dnf" instead of "yum" for package
management. While there is a compatible "yum" cli available, there's no
guarantee that it will be available. cloud-init should use dnf if it is
available.
** Affects: cloud-init
Importance: Undecided
Public bug reported:
With 0.7.8 on a CentOS 7 environment, I am seeing cloud-init fail (when
called from cloud-config.service) with the following traceback:
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/cloudinit/stages.py", line 785, in
_run_modules
Public bug reported:
If an interface is "down", reading from several of the sysfs files for
that interface will return EINVAL, which causes Python to raise an
IOError like this:
Dec 02 18:11:09 citest.novalocal cloud-init[413]: [CLOUDINIT] util.py[DEBUG]:
failed stage init-local
Public bug reported:
The Azure data source (in sources/helpers/azure.py) attempts to read the
current DHCP lease from /var/lib/dhcp/dhclient.eth0.leases, but that
path does not exist on, for example, RHEL/Fedora/CentOS environments
(which appear to use /var/lib/dhclient/dhclient--eth0.lease).
Public bug reported:
The rh_subscription plugin attempts to connect to the RHN servers even
when no config is provided. This can introduce a large delay in the
boot process if the local environment is dropping outbound packets.
** Affects: cloud-init
Importance: Undecided
Status:
Public bug reported:
Given the following user-data:
#cloud-config
merge_how: 'list(append)+dict(recurse_array)+str()'
disable_root: 0
users:
- name: foobar
gecos: Foo B. Bar
lock-passwd: false
passwd: secret
- name: barfoo
gecos: Bar B. Foo
Public bug reported:
The existing cloud-init code determines if systemd is in use by looking
at the distribution name and version. This is prone to error because:
- RHEL derivatives other than CentOS (e.g., Scientific Linux) will fail this
test, and
- Distributions that are not derived from
Public bug reported:
The generate_sample.sh script refers to a MODULEPATH variable without
clearing it first. On a system using the environment-modules package,
MODULEPATH is a PATH-like environment variable, which leads
generate_sample.sh to fail like this:
No module named
Public bug reported:
If you attempt to boot an image that is too large for a given flavor:
$ nova boot --image fedora-21-cloud --flavor m1.tiny test0
The boot will of course fail, but the fault communicated to the client
is:
| fault| {message: Build of
Public bug reported:
If you attempt to boot a nova instance without Neutron properly
configured for neutron/nova notifications, the instance will eventually
fail to spawn:
[-] [instance: 1541a197-9f80-4ee5-a7d6-08e591aa83fd] Instance failed to spawn
[instance:
Public bug reported:
cloudinit/dists/rhel.py contains the follow code to determine if systemd
is in use:
def uses_systemd(self):
# Fedora 18 and RHEL 7 were the first adopters in their series
(dist, vers) = util.system_info()['dist'][:2]
major =
Public bug reported:
The changes introduced in https://review.openstack.org/#/c/91722 break
live migration from Icehouse compute nodes to Juno compute nodes. This
complicates the upgrade process since it means origin compute nodes must
be upgraded at the same time as target compute nodes, which
Public bug reported:
Nova (Icehouse) appears to be enumerating all available libvirt volumes
(at least those in the default storage pool) during the Auditing
locally available compute resources process. If these images are not
readable by Nova it results in the following error:
2014-11-12
.\n'
This can cause failures in, e.g.,
neutron/plugins/linuxbridge/agent/linuxbridge_neutron_agent.py, which
performs almost exactly the same iteration in the
get_interface_by_ip() method.
** Affects: neutron
Importance: Undecided
Assignee: Lars Kellogg-Stedman (larsks)
Status
Kellogg-Stedman (larsks)
Status: In Progress
--
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/1374666
Title:
Nova devref documentation on hooks is incorrect
Status
, and it is demonstrably not stable.
** Affects: neutron
Importance: Undecided
Assignee: Lars Kellogg-Stedman (larsks)
Status: In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https
Public bug reported:
Neutron does not permit one to delete an instance that is associated
with multiple floating ip addresses.
Create an instance:
nova boot ... --nic net-id=3ff9b903-e921-4752-a26f-cba8f1433992 --key-
name lars test0
Add a second fixed ip address:
nova add-fixed-ip test0
Public bug reported:
In Havana, this was a valid setting:
libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver
The nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver class has been
removed in Icehouse; if nova-compute is run with this setting in
nova.conf, the resulting error
Glance was tracking this in
https://bugs.launchpad.net/glance/+bug/1279000
** Changed in: glance
Status: New = Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1301036
Public bug reported:
In some situations (using nested KVM in an environment where nested KVM
support is buggy), the appliance started by libguestfs will hang and the
libguestfs-launched qemu process will never exit. This will cause the
launched instance to get stuck in state=spawning forver (or
Public bug reported:
The value of libvirt_type in nova.conf is not respected when Nova
launches libguestfs appliances. This can cause problems were an
administrator has explicitly set libvirt_type=qemu to work around KVM
issues (or to test qemu). Newer versions of libguestfs support the
Public bug reported:
The spelling of flavor in the Nova client is americanized. Those with
a non-American English education might prefer to have aliases available
for flavour in, e.g., nova boot and the various nova flavor-*
commands.
There is a precedent in the gnu/linux world in grep where
Public bug reported:
I have deployed OpenStack using RedHat's packstack tool by running
packstack --allinone, which results in the following tenants:
(keystone_admin)# keystone tenant-list
+--+--+-+
|id|
40 matches
Mail list logo
