After I recheck this issue, I find that transient switching loop may not
exist...
The fail_mode of br-int, br-eth0 and br-ex are secure, which means that when
node reboot or OpenvSwitch restart, there will no normal flow in these bridges
so no packets can pass these bridges.
The normal flow in b
** Changed in: neutron
Status: Incomplete => Invalid
** No longer affects: neutron
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1666927
Title:
introduce os-vif VIF object for p
** Changed in: neutron
Status: Incomplete => Invalid
** No longer affects: neutron
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1666926
Title:
introduce os-vif VIF object for v
Public bug reported:
[Existing problem]
>From `os-vif Nova SPEC`_, whenever a new Neutron mechanism driver is created,
>this results in the definition of a new VIF type. This situation generates two
>problems:
* Nova developers need to maintain the plug/unplug code in the VIF drivers,
which is
Public bug reported:
Here is an example of a job at
http://logs.openstack.org/58/487458/6/check/gate-grenade-dsvm-ironic-
ubuntu-xenial/d8f187e/console.html#_2017-07-28_09_33_52_031224
2017-07-28 09:33:52.027473 | Captured pythonlogging:
2017-07-28 09:33:52.027484 | ~~~
2017-0
I confirmed the symptom seen in bug 1700448 was fixed
** Changed in: networking-midonet
Importance: Undecided => Critical
** Changed in: networking-midonet
Status: New => Fix Released
** Changed in: networking-midonet
Milestone: None => 5.0.0
** Changed in: networking-midonet
Reviewed: https://review.openstack.org/487130
Committed:
https://git.openstack.org/cgit/openstack/neutron/commit/?id=2ec36dc812710c284b75498e695a44585484c6a1
Submitter: Jenkins
Branch:master
commit 2ec36dc812710c284b75498e695a44585484c6a1
Author: Trevor McCasland
Date: Tue Jul 25 08:44:08
Public bug reported:
Running queries for shared providers creates the following warning:
/home/cdent/src/nova/.tox/functional/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py:340:
OsloDBDeprecationWarning: EngineFacade is deprecated; please use
oslo_db.sqlalchemy.engine
Public bug reported:
This bug tracker is for errors with the documentation, use the following
as a template and remove or add fields as you see fit. Convert [ ] into
[x] to check boxes:
- [x] This doc is inaccurate in this way: In installation step 1,the guide dose
not show the users to instal
Self over allocating VCPUs is not a good idea. If your machine only has
4 CPUs and you expose that as 5 CPUs to a guest, you'll get
pathologically bad performance as the guest tries to optimize workloads
across those, which are causing cache flushes in the CPUs below.
Definitely in the Won't Fix c
Fixed in docs.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1679703
Title:
Unable to boot instance with VF( direct-port ) because the
Ok, given the docs are fixed, lets put this into Opinion (which is a
closed state) for the actual code changes which don't have concensus.
** Changed in: nova
Status: New => Opinion
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscri
I think this is one of those edge cases that the work around you
provided is the right way through. The decorating on images is meant to
be part of the original image build process, and doesn't magically fix
things.
** Changed in: nova
Status: New => Won't Fix
--
You received this bug not
If nova cli allows you to do that, it means the REST API allows you to
do that. Permissions should not be done on the client side as they can
be circumvented with curl.
This looks like it's a permissions issue on the server side where you'd
like a different policy?
** Changed in: nova
Stat
** Changed in: nova
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1677892
Title:
nova scheduler_default_filter ComputeCapabilities filte
Working as design, device_name is since removed from the API.
** Tags added: shelve
** Changed in: nova
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launch
What real world scenario would you expect to expose a situation where
the neutron environment is turned off and nova-compute is restarted?
This seems pretty synthetic, and the fact that it recovers ones the
neutron agent restarts seems like most of the environment is working as
expected.
** Change
This is really a note to self. Moving to Opinion as there are a lot of
mights here. :)
** Tags added: note-to-self
** Changed in: nova
Status: New => Opinion
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Comput
The device_name was removed from the API. I think the only place it ever
worked was xenserver.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bug
If there is a request for a Nova feature here, please bring it in via
the Nova Specs process - https://specs.openstack.org/openstack/nova-
specs/readme.html
** Changed in: nova
Status: New => Opinion
--
You received this bug notification because you are a member of Yahoo!
Engineering Team
I think on the Nova side this is pretty much working as designed. If
there is different / better ironic behavior, perhaps it could be brought
up with the Ironic team?
** Changed in: nova
Status: New => Opinion
--
You received this bug notification because you are a member of Yahoo!
Engine
I think this is the kind of enhancement that would come through the
specs process - https://specs.openstack.org/openstack/nova-
specs/readme.html
** Changed in: nova
Status: New => Opinion
** Changed in: nova
Importance: Undecided => Wishlist
--
You received this bug notification beca
I expect this was an issue with a stale installation of dependencies. If
this is still an issue, please reopen
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (no
** Tags added: note-to-self
** Changed in: nova
Status: New => Opinion
** Changed in: nova
Importance: Undecided => Wishlist
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchp
Evacuate behavior changes are so dicey at this point that I think
anything like this probably needs a spec to actually think through the
edge conditions.
Please dive in here if you are interested -
https://specs.openstack.org/openstack/nova-specs/readme.html
** Tags added: evacuate
** Changed in
Managing the AppArmor config is currently beyond scope for Nova, thus
marking this as Opinion. It would be good if those rules from the
distros were able to do this better.
If you wanted to put that in scope for Nova, that would require a Nova
spec - https://specs.openstack.org/openstack/nova-spec
This would be a spec enhancement I think, please look at the specs
process here - https://specs.openstack.org/openstack/nova-
specs/readme.html
** Changed in: nova
Status: New => Opinion
** Changed in: nova
Importance: Undecided => Wishlist
--
You received this bug notification becaus
** Changed in: nova
Status: Confirmed => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1454418
Title:
Evacuate fails when using cells - AttributeError:
Public bug reported:
Earlier this week on Zesty on Azure I saw a cloud-init failure in its
'mount_cb' function.
That function esentially does:
a.) make a tmp directory for a mount point
b.) mount some filesystem to that mount point
c.) call a function
d.) unmount the directory
What I recall
Public bug reported:
In an attempt to fix a different bug [1] where a later try to detach a
volume failed if the guest was busy and ignored the request to detach
from the live domain, a new bug was introduced where a later try to
detach a volume silently passes even though the device is still atta
Public bug reported:
I got this message while booting the latest Ubuntu 16.04 Cloud image from:
http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.img
It said to report it, so here I am :)
1. I'm running OpenStack Newton.
2. 0.7.9-153-g16a7302f-0ubuntu1~16.04.2
Reviewed: https://review.openstack.org/485752
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=14c38ac0f253036da79f9d07aedf7dfd5778fde8
Submitter: Jenkins
Branch:master
commit 14c38ac0f253036da79f9d07aedf7dfd5778fde8
Author: Kashyap Chamarthy
Date: Thu Jul 20 19:01:23 2
Public bug reported:
The configuration guide document should contain all information for
configuration options, as well as sample policy files. Keystone's
configuration section uses the wrong directive, which results in the
configuration options being rendered where the sample policy file should
b
** Also affects: nova/newton
Importance: Undecided
Status: New
** Also affects: nova/ocata
Importance: Undecided
Status: New
** Changed in: nova
Importance: Undecided => Medium
** Changed in: nova/newton
Importance: Undecided => Medium
** Changed in: nova/ocata
Impo
It does feel like it might be better to fix this on the client side.
Marking as opinion as the patch author abandoned the nova patch. It is
welcome to come back later.
** Changed in: nova
Status: New => Opinion
--
You received this bug notification because you are a member of Yahoo!
Engin
This isn't a bug. IF the {role_id} at the end of the call is not passed,
we use the list action of:
/v3/domains/{domain_id}/groups/{group_id}/roles/ (regardless of head or
get action)
If a role_id is passed, you're calling a different API. This is not a
great design, but this is working as intend
Public bug reported:
This code in the scheduler report client is used by the scheduler when
making allocation requests against a certain instance during a move
operation:
https://github.com/openstack/nova/blob/09f0795fe0f5d043593f5ae55a6ec5f6298ba5ba/nova/scheduler/client/report.py#L200
The idea
Public bug reported:
There are a few places in the scheduler report client that don't account
for shared resource providers, like a shared storage pool.
1.
https://github.com/openstack/nova/blob/09f0795fe0f5d043593f5ae55a6ec5f6298ba5ba/nova/scheduler/client/report.py#L921
That's used in _allocat
*** This bug is a duplicate of bug 1562681 ***
https://bugs.launchpad.net/bugs/1562681
** Tags added: evacuate
** This bug has been marked a duplicate of bug 1562681
Post instance evacuation, image metadata is not retained when using shared
storage
--
You received this bug notification
There definitely could be enhancements to the recovery mode when things
start up again, but this is more than a simple bug, and probably needs a
spec to work through all the edge conditions here.
The Nova spec process is here - https://specs.openstack.org/openstack
/nova-specs/
** Changed in: nov
Public bug reported:
Steps to reproduce:
1. Create public flavor using UI or API
2. Change flavor access to admin project
3. Login with user credentials
4. Check that flavor is unavailable for user while creating instance
Expected result:
Flavor absents
Actual result:
Flavor presents
** Affects
This is apparently fixed in os-vif for Newton and beyond. Marking
Invalid on the Nova side because the logic doesn't live in Nova in any
supported version.
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team,
** Also affects: oslo.policy
Importance: Undecided
Status: New
--
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/1707246
Title:
Configuration guide reference
Public bug reported:
Seen here:
http://logs.openstack.org/78/480778/2/check/gate-tempest-dsvm-neutron-
full-ubuntu-
xenial/10b/logs/screen-n-cpu.txt.gz?level=TRACE#_Jul_27_07_06_43_460444
Jul 27 07:06:43.460444 ubuntu-xenial-citycloud-la1-10111613
nova-compute[18654]: ERROR oslo_messaging.r
Reviewed: https://review.openstack.org/467715
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=20c4715a49a44c642882618f102cd0fc9342978d
Submitter: Jenkins
Branch:master
commit 20c4715a49a44c642882618f102cd0fc9342978d
Author: Matt Riedemann
Date: Thu Jun 15 11:46:44 2017
Public bug reported:
>From a single scenario job (http://logs.openstack.org/57/488557/1/check
/gate-tempest-dsvm-neutron-dvr-multinode-scenario-ubuntu-xenial-
nv/36d8e0b/logs/?C=S;O=D)
[ ] screen-q-agt.txt.gz 2017-07-28 19:459.6M
[ ] screen-q-svc.txt.gz 2017-07-28 19:
Reviewed: https://review.openstack.org/488363
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=5728a575c77bc74af8df5e5d8ef22dba0eed1677
Submitter: Jenkins
Branch:master
commit 5728a575c77bc74af8df5e5d8ef22dba0eed1677
Author: Chris Dent
Date: Fri Jul 28 11:25:13 2017 +01
Marking invalid per comment above.
** Changed in: cloud-init
Status: New => Invalid
--
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/1585193
Title:
walinuxagent not found on Cen
** Changed in: cloud-init
Status: New => Invalid
--
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/1551747
Title:
ubuntu-fan causes issues during network configuration
Status in
Public bug reported:
Description
===
Create an instance with an existing port and a security group. The security
group is ignored. The port's security group is not updated. Steps to reproduce:
Steps to reproduce
==
$ source /opt/stack/devstack/openrc demo demo
$ openstack
Public bug reported:
subport doesn't transition to DOWN state after trunk deletion
logstash query:
http://logstash.openstack.org/#dashboard/file/logstash.json?query=build_name%3Agate-tempest-dsvm-neutron-dvr-multinode-scenario-ubuntu-xenial-nv%20AND%20build_branch%3Amaster%20AND%20message%3A%5C
51 matches
Mail list logo