As per a thread on the mailing list [1], this issue was already fixed
[2] in Neutron in Juno and backported to Icehouse, so I'm going to
remove Neutron as an affected project.
1: http://lists.openstack.org/pipermail/openstack-dev/2014-October/048916.html
2: https://bugs.launchpad.net/neutron/+bug/
** Changed in: neutron
Assignee: Oleg Bondarev (obondarev) => (unassigned)
** Changed in: neutron
Milestone: kilo-1 => None
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1361357
Title:
met
** Tags removed: icehouse-backport-potential juno-backport-potential
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1361357
Title:
metadata service performance regression ~8x
To manage notifications
** Changed in: neutron
Milestone: None => kilo-1
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1361357
Title:
metadata service performance regression ~8x
To manage notifications about this bug
** Tags added: icehouse-backport-potential
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1361357
Title:
metadata service performance regression ~8x
To manage notifications about this bug go to:
htt
** Changed in: neutron
Milestone: kilo-1 => None
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1361357
Title:
metadata service performance regression ~8x
To manage notifications about this bug
I'm changing assignment to Oleg since he has submitted a patch to switch
to eliminate the need for client initialization by using RPC.
** Changed in: neutron
Importance: High => Medium
** Changed in: neutron
Milestone: None => kilo-1
** Tags added: juno-backport-potential
--
You receive
** Changed in: neutron
Importance: Undecided => High
** Changed in: neutron
Assignee: Corey Bryant (corey.bryant) => Oleg Bondarev (obondarev)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/136
Preventing the timeout is a stop-gap, but a better solution might be for
port creation to be idempotent such that multiple creates for the same
port do not result in multiple ports. Perhaps it should be possible for
Nova to pass in the maximum number of ports that should be created for
an instance
I can confirm Ian Wells' suspicion that the problem is related to
scheduling. If there is an error interacting with Neutron during
scheduling, the vm will be rescheduled but a port that was created
before the scheduling failure will persist. Nova needs to be updated to
remove or reuse the port in
It's not clear that multiple fixed ips being allocated for a VM when
Nova and Neutron are experiencing heavy load is solved by the merged
patch or whether it was merely masked. At the least, there needs to be
documentation added that makes it clear how to set max_pool_size,
max_overflow and pool_t
** Changed in: neutron
Assignee: Gary Kotton (garyk) => Maru Newby (maru)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1160442
Title:
when boot many vms with quantum, nova sometimes alloca
Public bug reported:
The Quantum OVS plugin does not interact directly with Open vSwitch -
that is left to the agent - and so doesn't depend on having Open
vSwitch installed. The control file should be updated to reflect this.
This issue affects precise, quantul and raring.
See: http://bazaar.
13 matches
Mail list logo