[Yahoo-eng-team] [Bug 1586207] [NEW] [qos] section is missing from neutron.conf
Public bug reported: Liberty neutron.conf: [qos] # Drivers list to use to send the update notification # notification_drivers = message_queue Mitaka/master auto-generated neutron.conf: # # From neutron.qos # # Drivers list to use to send the update notification (list value) #notification_drivers = m,e,s,s,a,g,e,_,q,u,e,u,e ** Affects: neutron Importance: Undecided Assignee: John Kasperski (jckasper) Status: In Progress ** Tags: qos ** Changed in: neutron Assignee: (unassigned) => John Kasperski (jckasper) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1586207 Title: [qos] section is missing from neutron.conf Status in neutron: In Progress Bug description: Liberty neutron.conf: [qos] # Drivers list to use to send the update notification # notification_drivers = message_queue Mitaka/master auto-generated neutron.conf: # # From neutron.qos # # Drivers list to use to send the update notification (list value) #notification_drivers = m,e,s,s,a,g,e,_,q,u,e,u,e To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1586207/+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 1584204] Re: VersionsCallbackNotFound exception when using QoS
Proposed patch: https://review.openstack.org/#/c/319444/
** Also affects: neutron
Importance: Undecided
Status: New
** Changed in: neutron
Assignee: (unassigned) => John Kasperski (jckasper)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1584204
Title:
VersionsCallbackNotFound exception when using QoS
Status in networking-ovn:
Confirmed
Status in neutron:
New
Bug description:
VersionsCallbackNotFound exception occurred in neutron-server running
networking-ovn when trying to enable QoS with the following commands:
$ neutron qos-policy-create bw-limiter
$ neutron qos-bandwidth-limit-rule-create bw-limiter --max-kbps 3000
--max-burst-kbps 300
Note: This exception occurred when running core plugin or ML2 mech
driver.
2016-05-20 09:41:36.789 27596 DEBUG oslo_policy.policy
[req-0fe76c74-76a6-43b3-8f5b-4d85a65aec7b admin -] Reloaded policy file:
/etc/neutron/policy.json _load_policy_file
/usr/local/lib/python2.7/dist-packages/oslo_policy/policy.py:520
2016-05-20 09:41:36.954 27596 INFO neutron.wsgi
[req-0fe76c74-76a6-43b3-8f5b-4d85a65aec7b admin -] 192.168.56.10 - -
[20/May/2016 09:41:36] "GET /v2.0/qos/policies.json?fields=id&name=bw-limiter
HTTP/1.1" 200 260 0.368297
2016-05-20 09:41:37.031 27596 DEBUG neutron.api.v2.base
[req-c50967a6-838f-4da8-adab-9a44e7c7c207 admin -] Request body:
{u'bandwidth_limit_rule': {u'max_kbps': u'3000', u'max_burst_kbps': u'300'}}
prepare_request_body /opt/stack/neutron/neutron/api/v2/base.py:658
2016-05-20 09:41:37.031 27596 DEBUG neutron.api.v2.base
[req-c50967a6-838f-4da8-adab-9a44e7c7c207 admin -] Unknown quota resources
['bandwidth_limit_rule']. _create /opt/stack/neutron/neutron/api/v2/base.py:460
2016-05-20 09:41:37.056 27596 DEBUG neutron.api.rpc.handlers.resources_rpc
[req-c50967a6-838f-4da8-adab-9a44e7c7c207 admin -]
neutron.api.rpc.handlers.resources_rpc.ResourcesPushRpcApi method push called
with arguments (,
QosPolicy(description='',id=dbee9581-44a5-4889-bd06-9193eb08c10d,name='bw-limiter',rules=[QosRule(7317f86e-bacb-4c6c-9221-66e2f9d9309d)],shared=False,tenant_id=7c291c3d9d1a45dd89c8c80c7f5f12b0),
'updated') {} wrapper
/usr/local/lib/python2.7/dist-packages/oslo_log/helpers.py:47
2016-05-20 09:41:37.056 27596 ERROR neutron.api.v2.resource
[req-c50967a6-838f-4da8-adab-9a44e7c7c207 admin -] create failed
2016-05-20 09:41:37.056 27596 ERROR neutron.api.v2.resource Traceback (most
recent call last):
2016-05-20 09:41:37.056 27596 ERROR neutron.api.v2.resource File
"/opt/stack/neutron/neutron/api/v2/resource.py", line 84, in resource
2016-05-20 09:41:37.056 27596 ERROR neutron.api.v2.resource result =
method(request=request, **args)
2016-05-20 09:41:37.056 27596 ERROR neutron.api.v2.resource File
"/opt/stack/neutron/neutron/api/v2/base.py", line 412, in create
2016-05-20 09:41:37.056 27596 ERROR neutron.api.v2.resource return
self._create(request, body, **kwargs)
2016-05-20 09:41:37.056 27596 ERROR neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 148, in wrapper
2016-05-20 09:41:37.056 27596 ERROR neutron.api.v2.resource ectxt.value =
e.inner_exc
2016-05-20 09:41:37.056 27596 ERROR neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 221, in
__exit__
2016-05-20 09:41:37.056 27596 ERROR neutron.api.v2.resource
self.force_reraise()
2016-05-20 09:41:37.056 27596 ERROR neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 197, in
force_reraise
2016-05-20 09:41:37.056 27596 ERROR neutron.api.v2.resource
six.reraise(self.type_, self.value, self.tb)
2016-05-20 09:41:37.056 27596 ERROR neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/oslo_db/api.py", line 138, in wrapper
2016-05-20 09:41:37.056 27596 ERROR neutron.api.v2.resource return
f(*args, **kwargs)
2016-05-20 09:41:37.056 27596 ERROR neutron.api.v2.resource File
"/opt/stack/neutron/neutron/api/v2/base.py", line 523, in _create
2016-05-20 09:41:37.056 27596 ERROR neutron.api.v2.resource obj =
do_create(body)
2016-05-20 09:41:37.056 27596 ERROR neutron.api.v2.resource File
"/opt/stack/neutron/neutron/api/v2/base.py", line 505, in do_create
2016-05-20 09:41:37.056 27596 ERROR neutron.api.v2.resource
request.context, reservation.reservation_id)
2016-05-20 09:41:37.056 27596 ERROR neutron.api.v2.resource File
"/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 221, in
__exit__
2016-05-20 09:41:37.056 27596 ERROR neutron.api.v2.resource
self.force_reraise()
2
[Yahoo-eng-team] [Bug 1578281] [NEW] IPv6 IP allocated on port-create for IPv4 subnet
|
|
| fixed_ips | {"subnet_id": "bba5da3a-500c-466b-9d1d-f917d5c24d64",
"ip_address": "172.16.1.4"}|
| | {"subnet_id": "49d0ce59-6888-4e0c-8aff-7def31087524",
"ip_address": "2001:db8::f816:3eff:fe56:fc6e"} |
| id| fb3e6820-0448-47c0-b028-4659a6f6c833
|
| mac_address | fa:16:3e:56:fc:6e
|
| name |
|
| network_id| e0c605e7-f117-4319-8eab-6429c8d53b4b
|
| port_security_enabled | True
|
| security_groups | b886de86-0fdf-4dff-8f07-e67fb7a9a1aa
|
| status| DOWN
|
| tenant_id | ec507c583aa64f1ca186bc5d7944895e
|
| updated_at| 2016-05-04T15:40:29
|
+---+------+
If the user requested only the IPv4 subnet, an IPv6 address should not
be allocated.
** Affects: neutron
Importance: Undecided
Assignee: John Kasperski (jckasper)
Status: New
** Changed in: neutron
Assignee: (unassigned) => John Kasperski (jckasper)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1578281
Title:
IPv6 IP allocated on port-create for IPv4 subnet
Status in neutron:
New
Bug description:
* High level description: When you have a network that has both IPv4
subnet and a IPv6 stateless subnet, a neutron port-create in which
only a IPv4 subnet is requested (via fixed_ip) results in both IPv4
and IPv6 addresses being allocated for the port. An IPv6 address
should not be allocated in this case.
* Pre-conditions: None. CLI commands executed as tenant user.
* Step-by-step reproduction steps: CLI commands shown below
* Expected output: When creating neutron port with fixed_ip of IPv4
subnet, expected the resulting port to contain only an IPv4 address.
* Actual output: IPv6 and IPv4 addresses were allocated on the port-
create
* Version: master / DevStack
* Steps to re-create:
Create a neutron network with 2 subnets (v4 and v6-slaac)
$ neutron net-create network
$ neutron subnet-create --name subnet_v4 --ip-version 4 network
172.16.1.0/24
$ neutron subnet-create --name subnet_v6 --ip-version 6 --ipv6-ra-mode slaac
--ipv6-address-mode slaac network 2001:db8::/64
$ neutron net-list
+--+-+-+
| id | name| subnets
|
+--+-+-+
| e0c605e7-f117-4319-8eab-6429c8d53b4b | network |
bba5da3a-500c-466b-9d1d-f917d5c24d64 172.16.1.0/24 |
| | |
49d0ce59-6888-4e0c-8aff-7def31087524 2001:db8::/64 |
|+--+-+-+
When creating a neutron port, an IP address is allocated out of both subnets
(as expected).
$ neutron port-create network
Created a new port:
+---+--+
| Field | Value
|
+---+--+
| admin_state_up| True
|
| allowed_address_pairs |
|
| binding:vnic_type | normal
[Yahoo-eng-team] [Bug 1500526] Re: Deprecate config option 'use_helper_for_ns_read'
*** This bug is a duplicate of bug 1500528 ***
https://bugs.launchpad.net/bugs/1500528
Launchpad messed up and opened 3 bugs for a single bug report.
** This bug is no longer a duplicate of bug 1500527
Deprecate config option 'use_helper_for_ns_read'
** This bug has been marked a duplicate of bug 1500528
Deprecate config option 'use_helper_for_ns_read'
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1500526
Title:
Deprecate config option 'use_helper_for_ns_read'
Status in neutron:
New
Bug description:
The config option 'cfg.CONF.AGENT.use_helper_for_ns_read' defaults to
"True" as seen here:
cfg.BoolOpt('use_helper_for_ns_read',
default=True,
help=_('Use the root helper to read the namespaces from '
'the operating system.')),
There are two places in neutron.agent.linux.ip_lib where the list of
namespaces are retrieved:
class IPWrapper(SubProcessBase):
def get_namespaces(cls):
output = cls._execute([], 'netns', ('list',))
return [l.strip() for l in output.split('\n')]
and
class IpNetnsCommand(IpCommandBase):
def exists(self, name):
output = self._parent._execute(
['o'], 'netns', ['list'],
run_as_root=cfg.CONF.AGENT.use_helper_for_ns_read)
for line in output.split('\n'):
if name == line.strip():
return True
return False
Both methods are calling "ip netns list", but only one is actually using the
configuration option.
Both of these methods are called through out the code.
The configuration option is not necessary in the first case therefore
it should be removed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1500526/+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 1500528] [NEW] Deprecate config option 'use_helper_for_ns_read'
Public bug reported:
The config option 'cfg.CONF.AGENT.use_helper_for_ns_read' defaults to
"True" as seen here:
cfg.BoolOpt('use_helper_for_ns_read',
default=True,
help=_('Use the root helper to read the namespaces from '
'the operating system.')),
There are two places in neutron.agent.linux.ip_lib where the list of
namespaces are retrieved:
class IPWrapper(SubProcessBase):
def get_namespaces(cls):
output = cls._execute([], 'netns', ('list',))
return [l.strip() for l in output.split('\n')]
and
class IpNetnsCommand(IpCommandBase):
def exists(self, name):
output = self._parent._execute(
['o'], 'netns', ['list'],
run_as_root=cfg.CONF.AGENT.use_helper_for_ns_read)
for line in output.split('\n'):
if name == line.strip():
return True
return False
Both methods are calling "ip netns list", but only one is actually using
the configuration option. Both of these methods are called through out
the code.
The configuration option is not necessary in the first case therefore it
should be removed.
** Affects: neutron
Importance: Undecided
Assignee: John Kasperski (jckasper)
Status: New
** Description changed:
The config option 'cfg.CONF.AGENT.use_helper_for_ns_read' defaults to
"True" as seen here:
- cfg.BoolOpt('use_helper_for_ns_read',
- default=True,
- help=_('Use the root helper to read the namespaces from '
-'the operating system.')),
+ cfg.BoolOpt('use_helper_for_ns_read',
+ default=True,
+ help=_('Use the root helper to read the namespaces from '
+ 'the operating system.')),
There are two places in neutron.agent.linux.ip_lib where the list of
namespaces are retrieved:
-class IPWrapper(SubProcessBase):
- def get_namespaces(cls):
- output = cls._execute([], 'netns', ('list',))
- return [l.strip() for l in output.split('\n')]
+ class IPWrapper(SubProcessBase):
+ def get_namespaces(cls):
+ output = cls._execute([], 'netns', ('list',))
+ return [l.strip() for l in output.split('\n')]
and
-class IpNetnsCommand(IpCommandBase):
- def exists(self, name):
- output = self._parent._execute(
- ['o'], 'netns', ['list'],
- run_as_root=cfg.CONF.AGENT.use_helper_for_ns_read)
- for line in output.split('\n'):
- if name == line.strip():
- return True
- return False
+ class IpNetnsCommand(IpCommandBase):
+ def exists(self, name):
+ output = self._parent._execute(
+ ['o'], 'netns', ['list'],
+ run_as_root=cfg.CONF.AGENT.use_helper_for_ns_read)
+ for line in output.split('\n'):
+ if name == line.strip():
+ return True
+ return False
- Both methods are calling "ip netns list", but only one is actually using the
configuration option.
- Both of these methods are called through out the code.
+ Both methods are calling "ip netns list", but only one is actually using
+ the configuration option. Both of these methods are called through out
+ the code.
The configuration option is not necessary in the first case therefore it
should be removed.
** Changed in: neutron
Assignee: (unassigned) => John Kasperski (jckasper)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1500528
Title:
Deprecate config option 'use_helper_for_ns_read'
Status in neutron:
New
Bug description:
The config option 'cfg.CONF.AGENT.use_helper_for_ns_read' defaults to
"True" as seen here:
cfg.BoolOpt('use_helper_for_ns_read',
default=True,
help=_('Use the root helper to read the namespaces from '
'the operating system.')),
There are two places in neutron.agent.linux.ip_lib where the list of
namespaces are retrieved:
class IPWrapper(SubProcessBase):
def get_namespaces(cls):
output = cls._execute([], 'netns', ('list',))
return [l.strip() for l in output.split('\n')]
and
class IpNetnsCommand(IpCommandBase):
def exists(self, name):
output = self._parent._execute(
['o'], 'netns', ['l
[Yahoo-eng-team] [Bug 1500526] [NEW] Deprecate config option 'use_helper_for_ns_read'
Public bug reported:
The config option 'cfg.CONF.AGENT.use_helper_for_ns_read' defaults to
"True" as seen here:
cfg.BoolOpt('use_helper_for_ns_read',
default=True,
help=_('Use the root helper to read the namespaces from '
'the operating system.')),
There are two places in neutron.agent.linux.ip_lib where the list of
namespaces are retrieved:
class IPWrapper(SubProcessBase):
def get_namespaces(cls):
output = cls._execute([], 'netns', ('list',))
return [l.strip() for l in output.split('\n')]
and
class IpNetnsCommand(IpCommandBase):
def exists(self, name):
output = self._parent._execute(
['o'], 'netns', ['list'],
run_as_root=cfg.CONF.AGENT.use_helper_for_ns_read)
for line in output.split('\n'):
if name == line.strip():
return True
return False
Both methods are calling "ip netns list", but only one is actually using the
configuration option.
Both of these methods are called through out the code.
The configuration option is not necessary in the first case therefore it
should be removed.
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1500526
Title:
Deprecate config option 'use_helper_for_ns_read'
Status in neutron:
New
Bug description:
The config option 'cfg.CONF.AGENT.use_helper_for_ns_read' defaults to
"True" as seen here:
cfg.BoolOpt('use_helper_for_ns_read',
default=True,
help=_('Use the root helper to read the namespaces from '
'the operating system.')),
There are two places in neutron.agent.linux.ip_lib where the list of
namespaces are retrieved:
class IPWrapper(SubProcessBase):
def get_namespaces(cls):
output = cls._execute([], 'netns', ('list',))
return [l.strip() for l in output.split('\n')]
and
class IpNetnsCommand(IpCommandBase):
def exists(self, name):
output = self._parent._execute(
['o'], 'netns', ['list'],
run_as_root=cfg.CONF.AGENT.use_helper_for_ns_read)
for line in output.split('\n'):
if name == line.strip():
return True
return False
Both methods are calling "ip netns list", but only one is actually using the
configuration option.
Both of these methods are called through out the code.
The configuration option is not necessary in the first case therefore
it should be removed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1500526/+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 1500527] [NEW] Deprecate config option 'use_helper_for_ns_read'
Public bug reported:
The config option 'cfg.CONF.AGENT.use_helper_for_ns_read' defaults to
"True" as seen here:
cfg.BoolOpt('use_helper_for_ns_read',
default=True,
help=_('Use the root helper to read the namespaces from '
'the operating system.')),
There are two places in neutron.agent.linux.ip_lib where the list of
namespaces are retrieved:
class IPWrapper(SubProcessBase):
def get_namespaces(cls):
output = cls._execute([], 'netns', ('list',))
return [l.strip() for l in output.split('\n')]
and
class IpNetnsCommand(IpCommandBase):
def exists(self, name):
output = self._parent._execute(
['o'], 'netns', ['list'],
run_as_root=cfg.CONF.AGENT.use_helper_for_ns_read)
for line in output.split('\n'):
if name == line.strip():
return True
return False
Both methods are calling "ip netns list", but only one is actually using the
configuration option.
Both of these methods are called through out the code.
The configuration option is not necessary in the first case therefore it
should be removed.
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1500527
Title:
Deprecate config option 'use_helper_for_ns_read'
Status in neutron:
New
Bug description:
The config option 'cfg.CONF.AGENT.use_helper_for_ns_read' defaults to
"True" as seen here:
cfg.BoolOpt('use_helper_for_ns_read',
default=True,
help=_('Use the root helper to read the namespaces from '
'the operating system.')),
There are two places in neutron.agent.linux.ip_lib where the list of
namespaces are retrieved:
class IPWrapper(SubProcessBase):
def get_namespaces(cls):
output = cls._execute([], 'netns', ('list',))
return [l.strip() for l in output.split('\n')]
and
class IpNetnsCommand(IpCommandBase):
def exists(self, name):
output = self._parent._execute(
['o'], 'netns', ['list'],
run_as_root=cfg.CONF.AGENT.use_helper_for_ns_read)
for line in output.split('\n'):
if name == line.strip():
return True
return False
Both methods are calling "ip netns list", but only one is actually using the
configuration option.
Both of these methods are called through out the code.
The configuration option is not necessary in the first case therefore
it should be removed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1500527/+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 1498597] [NEW] Curvature network topology no longer supports fly over
Public bug reported: The old network topology supported "fly over" where the details on the object would be automatically displayed when the cursor is placed over that object. In the new curvature network topology, you need to select each object in order for these details to be displayed. Slight change in functionality as compared to previous release. It is unclear from reading the blueprint as to why this change in functionality was done. ** Affects: horizon Importance: Undecided Status: New -- 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/1498597 Title: Curvature network topology no longer supports fly over Status in OpenStack Dashboard (Horizon): New Bug description: The old network topology supported "fly over" where the details on the object would be automatically displayed when the cursor is placed over that object. In the new curvature network topology, you need to select each object in order for these details to be displayed. Slight change in functionality as compared to previous release. It is unclear from reading the blueprint as to why this change in functionality was done. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1498597/+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 1498606] [NEW] Curvature network topology does not include scroll bars
Public bug reported: The curvature network topology does not appear to add any scroll bars when the diagram is too large (or zoom-ed in too much) to fit on the screen. It seems like there should be some indication that part of the canvas/diagram is currently scrolled off the view-able screen.An administrator might get confused when only part of the network is displayed on the screen. It is also possible to zoom on the network topology than then drag the entire output off the edge of the screen such that you are left with a completely empty canvas. Seems like this should be prevented or at least some indication that you are not viewing the entire screen (scroll bars ?) ** Affects: horizon Importance: Undecided Status: New -- 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/1498606 Title: Curvature network topology does not include scroll bars Status in OpenStack Dashboard (Horizon): New Bug description: The curvature network topology does not appear to add any scroll bars when the diagram is too large (or zoom-ed in too much) to fit on the screen. It seems like there should be some indication that part of the canvas/diagram is currently scrolled off the view-able screen. An administrator might get confused when only part of the network is displayed on the screen. It is also possible to zoom on the network topology than then drag the entire output off the edge of the screen such that you are left with a completely empty canvas. Seems like this should be prevented or at least some indication that you are not viewing the entire screen (scroll bars ?) To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1498606/+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 1498588] [NEW] Curvature network topology does not display IPs
Public bug reported: The curvature network topology does not display the IP address for VM and router network interfaces nor does it display the CIDR for the network/subnet. This information was automatically displayed by the old network topology layout. The only way to determine this IP address information on the new curvature network topology is to drill down into each object individually. This seems like a regression of functionality. There is a toggle to display "Labels". Could a new toggle be added to display "IP addresses" ? Old layout vs new layout: http://imgur.com/a/qddWB ** Affects: horizon Importance: Undecided Status: New -- 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/1498588 Title: Curvature network topology does not display IPs Status in OpenStack Dashboard (Horizon): New Bug description: The curvature network topology does not display the IP address for VM and router network interfaces nor does it display the CIDR for the network/subnet. This information was automatically displayed by the old network topology layout. The only way to determine this IP address information on the new curvature network topology is to drill down into each object individually. This seems like a regression of functionality. There is a toggle to display "Labels". Could a new toggle be added to display "IP addresses" ? Old layout vs new layout: http://imgur.com/a/qddWB To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1498588/+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 1485732] [NEW] subnet-update of allocation_pool does not prevent orphaning existing ports
Public bug reported: An error should be returned when subnet-update is used to modify the allocation_pool such that existing neutron ports are no longer included. This operation should not be permitted. Currently the existing allocated neutron ports are not verified when a subnet allocation pool is changed. This can lead to unusual statistics such as: there could be 50 allocated neutron objects associated with a subnet, however the allocation pool range only includes 10 IP addresses and all 10 of those are not allocated. ** Affects: neutron Importance: Undecided Assignee: John Kasperski (jckasper) Status: New ** Changed in: neutron Assignee: (unassigned) => John Kasperski (jckasper) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1485732 Title: subnet-update of allocation_pool does not prevent orphaning existing ports Status in neutron: New Bug description: An error should be returned when subnet-update is used to modify the allocation_pool such that existing neutron ports are no longer included. This operation should not be permitted. Currently the existing allocated neutron ports are not verified when a subnet allocation pool is changed. This can lead to unusual statistics such as: there could be 50 allocated neutron objects associated with a subnet, however the allocation pool range only includes 10 IP addresses and all 10 of those are not allocated. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1485732/+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 1479948] [NEW] During subnet-update, allocation_pools used before being validated
Public bug reported: During the processing of a subnet-update request, neutron uses the specified allocation_pools to determine if the gateway IP is in that specified pool [1] prior to that incoming allocation_pools property ever being validated [2]. Validation of the incoming allocation_pool should be done before that property is used. [1]: https://github.com/openstack/neutron/blob/master/neutron/db/db_base_plugin_v2.py#L575 [2]: https://github.com/openstack/neutron/blob/master/neutron/db/ipam_backend_mixin.py#L188 ** Affects: neutron Importance: Undecided Assignee: John Kasperski (jckasper) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => John Kasperski (jckasper) ** Changed in: neutron Status: New => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1479948 Title: During subnet-update, allocation_pools used before being validated Status in neutron: In Progress Bug description: During the processing of a subnet-update request, neutron uses the specified allocation_pools to determine if the gateway IP is in that specified pool [1] prior to that incoming allocation_pools property ever being validated [2]. Validation of the incoming allocation_pool should be done before that property is used. [1]: https://github.com/openstack/neutron/blob/master/neutron/db/db_base_plugin_v2.py#L575 [2]: https://github.com/openstack/neutron/blob/master/neutron/db/ipam_backend_mixin.py#L188 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1479948/+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 1479514] [NEW] subnet-update of allocation_pool does not prevent overlap of existing gateway IP
Public bug reported: There are three variations here with the subnet-update command: 1) subnet-update of the gateway_ip such that the new gateway is placed in the existing subnet allocaton pool. This results in GatewayConflictWithAllocationPools. 2) subnet-update of both the gateway_ip and the allocation_poll . If the new gateway IP is located in the new allocation pool, then GatewayConflictWithAllocationPools is returned. 3) subnet-update of just the allocation_pool. If the new allocation pool includes the existing gateway_ip, no error is returned. Scenario 3 needs to be fixed to return same exception as (1) and (2). ** Affects: neutron Importance: Undecided Assignee: John Kasperski (jckasper) Status: In Progress ** Changed in: neutron Assignee: (unassigned) => John Kasperski (jckasper) ** Changed in: neutron Status: New => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1479514 Title: subnet-update of allocation_pool does not prevent overlap of existing gateway IP Status in neutron: In Progress Bug description: There are three variations here with the subnet-update command: 1) subnet-update of the gateway_ip such that the new gateway is placed in the existing subnet allocaton pool. This results in GatewayConflictWithAllocationPools. 2) subnet-update of both the gateway_ip and the allocation_poll . If the new gateway IP is located in the new allocation pool, then GatewayConflictWithAllocationPools is returned. 3) subnet-update of just the allocation_pool. If the new allocation pool includes the existing gateway_ip, no error is returned. Scenario 3 needs to be fixed to return same exception as (1) and (2). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1479514/+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
