** Changed in: keystone
Status: New => Invalid
--
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/1842283
Title:
Edit keystone.conf not effective in devstack
St
Reviewed: https://review.opendev.org/679473
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=3cef7edbc2dd72a25e46ca1962731ee3153f1fd7
Submitter: Zuul
Branch:master
commit 3cef7edbc2dd72a25e46ca1962731ee3153f1fd7
Author: Matt Riedemann
Date: Fri Aug 30 12:11:59 2019 -040
Public bug reported:
Description
===
IronicDriver should be using fields="instance_uuid" when calling Ironic API via
the OpenStack SDK, but instead is using fields="instance_id". The SDK will
return a node object with node.instance_id, which lead to the confusion in
implementation.
Ref
Public bug reported:
- [x] This doc is inaccurate in this way:
The reference link here is broken:
https://docs.openstack.org/nova/latest/contributor/testing/zero-
downtime-upgrade.html#zero-downtime-upgrade-process
---
Release: on 2017-09-06 22:01:01
SHA: 4476e6
Reviewed: https://review.opendev.org/677579
Committed:
https://git.openstack.org/cgit/openstack/horizon/commit/?id=c238b519f3e10ba6aa119b5ebc2bf30b2610bf16
Submitter: Zuul
Branch:master
commit c238b519f3e10ba6aa119b5ebc2bf30b2610bf16
Author: Andy Botting
Date: Wed Aug 21 08:35:57 2019 +10
Public bug reported:
Reproduce:
nova boot once
then nova rebuild: trigger an error during a first rebuild -> instance goes in
error state, fine
then normal nova rebuild: if ironic succeeds, instance is still stuck in error
state
while having a fully functional baremetal bound to it, so instance
It turns out that the fix merged breaks long-living OpenStack clouds
from the era where keystone used an integer for project/user ID. We
decided to revert the fix for this considering the importance of the
impact caused by the above change.
** Changed in: horizon
Status: Fix Released => New
Public bug reported:
When running a few subnet detaching from router and deletion, some
subnets are not possible to be deleted with this error:
$ openstack subnet delete e81929f6-25ea-45c2-89b5-ff94afd7136a
F
Reviewing our taxonomy, this probably fits closest as a class C1 report
due to depending on the existence of other exploitable bugs to leverage.
https://security.openstack.org/vmt-process.html#incident-report-taxonomy
** Information type changed from Private Security to Public
** Changed in: ossa
Couple of things here:
You're not using hw:cpu_policy=dedicated, which means multiple instances
vCPUS can be pinned to the same host CPUs. This explains why they're all
landing on the same NUMA node.
You're not setting hw:mem_page_size, which means Nova does not do per-
NUMA-cell accounting of me
Public bug reported:
In neutron-tempest-plugin we have scenario test for multicast traffic. This
test require "advanced image" to be used in VMs as it requires python3 to be
installed.
But there is way that some advanced image without python3 can be used (e.g.
RHEL 8) and then this test is fail
It looks for me more like nova or python-novaclient issue rather than neutron
itself.
I'm moving it to nova project for now. Feel free to move it back to Neutron if
You will have e.g. related errors from neutron log.
** Also affects: nova
Importance: Undecided
Status: New
** No longer
Public bug reported:
>> I have created a neutron network and a subnet
>> I have created a port on the network
>> I have created a vm with the port id option with --security-group option
>> provided
>>The CLI used.
nova --insecure boot --image cirros --flavor m1.tiny --nic
port-id=f6c035a3-fd
Adding a neutron bug-task to get an upstream opinion on whether neutron
should be loading these modules as the n-ovs-agent starts up.
** Also affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, w
14 matches
Mail list logo
