[Yahoo-eng-team] [Bug 1617164] [NEW] format error in agent/l3/ha_router.HaRouter._add_default_gw_virtual_route

2016-08-25 Thread hujin
Public bug reported:

format error in
agent/l3/ha_router.HaRouter._add_default_gw_virtual_route

** Affects: neutron
 Importance: Undecided
 Assignee: hujin (hujin)
 Status: In Progress

** Changed in: neutron
 Assignee: (unassigned) => hujin (hujin)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1617164

Title:
  format error in
  agent/l3/ha_router.HaRouter._add_default_gw_virtual_route

Status in neutron:
  In Progress

Bug description:
  format error in
  agent/l3/ha_router.HaRouter._add_default_gw_virtual_route

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1617164/+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 1605336] Re: Neutron loadbalancer VIP port fails to create

2016-08-25 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/346221
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=625fdb423e289ee98dbfbd4c81edf64b598cb352
Submitter: Jenkins
Branch:master

commit 625fdb423e289ee98dbfbd4c81edf64b598cb352
Author: Graham Hayes 
Date:   Fri Jul 22 20:55:44 2016 +0100

Avoid KeyError when accessing "dns_name" as it may not exist

Neutron LBaaS does not pass a full copy of the request_data
into this function, and causes the port create to fail
with a KeyError

Change-Id: Ib81cbbaf24a4ffaa983e1b05146aea0dc74e29bb
Fixes-Bug: #1605336


** Changed in: neutron
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1605336

Title:
  Neutron loadbalancer VIP port fails to create

Status in Designate:
  Invalid
Status in OpenStack Neutron LBaaS Integration:
  New
Status in neutron:
  Fix Released

Bug description:
  When trying to create a Loadbalancer (v1) VIP with the command:

  neutron lb-vip-create --address 10.97.0.254 --name vip-97 \
  --protocol-port 22 --protocol TCP --subnet-id subnet-97 hapool-97

  Where subnet-97 is a subnet to tenant-97, which have 'dns_domain' set
  to an existing domain. The domain works - creating an instance +
  floating IP on that will register the set dns_name in the domain.

  However, the lb-vip-create will fail with

  Request Failed: internal server error while processing your request.
  Neutron server returns request_ids: 
['req-ee6a68f1-ed8a-4f22-9dea-646fb97ff795']

  and the log will say:

  ==> /var/log/neutron/neutron-server.log <==
  2016-07-21 18:08:54.940 7926 INFO neutron.wsgi 
[req-cc53af04-89fc-482c-8a4f-0a3f5cc2e614 4b0e25c70d2b4ad6ba4c50250f2f0b0b 
04ee0e71babe4fd7aa16c3f64a8fca89 - - -] 10.0.4.1 - - [21/Jul/2016 18:08:54] 
"GET /v2.0/lb/pools.json?fields=id=hapool-97 HTTP/1.1" 200 257 0.070421
  2016-07-21 18:08:55.027 7926 INFO neutron.wsgi 
[req-e95bbb13-c38e-4cdf-afc5-9bba3351b8ff 4b0e25c70d2b4ad6ba4c50250f2f0b0b 
04ee0e71babe4fd7aa16c3f64a8fca89 - - -] 10.0.4.1 - - [21/Jul/2016 18:08:55] 
"GET /v2.0/subnets.json?fields=id=subnet-97 HTTP/1.1" 200 259 0.081731
  2016-07-21 18:08:55.037 7926 INFO neutron.quota 
[req-ee6a68f1-ed8a-4f22-9dea-646fb97ff795 4b0e25c70d2b4ad6ba4c50250f2f0b0b 
04ee0e71babe4fd7aa16c3f64a8fca89 - - -] Loaded quota_driver: 
.
  2016-07-21 18:08:55.494 7926 INFO neutron.plugins.ml2.managers 
[req-ee6a68f1-ed8a-4f22-9dea-646fb97ff795 4b0e25c70d2b4ad6ba4c50250f2f0b0b 
04ee0e71babe4fd7aa16c3f64a8fca89 - - -] Extension driver 'dns' failed in 
process_create_port
  2016-07-21 18:08:55.719 7926 ERROR neutron.api.v2.resource 
[req-ee6a68f1-ed8a-4f22-9dea-646fb97ff795 4b0e25c70d2b4ad6ba4c50250f2f0b0b 
04ee0e71babe4fd7aa16c3f64a8fca89 - - -] create failed
  2016-07-21 18:08:55.719 7926 ERROR neutron.api.v2.resource Traceback 
(most recent call last):
  2016-07-21 18:08:55.719 7926 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/dist-packages/neutron/api/v2/resource.py", line 84, in 
resource
  2016-07-21 18:08:55.719 7926 ERROR neutron.api.v2.resource result = 
method(request=request, **args)
  2016-07-21 18:08:55.719 7926 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 410, in create
  2016-07-21 18:08:55.719 7926 ERROR neutron.api.v2.resource return 
self._create(request, body, **kwargs)
  2016-07-21 18:08:55.719 7926 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/dist-packages/oslo_db/api.py", line 148, in wrapper
  2016-07-21 18:08:55.719 7926 ERROR neutron.api.v2.resource 
ectxt.value = e.inner_exc
  2016-07-21 18:08:55.719 7926 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 221, in __exit__
  2016-07-21 18:08:55.719 7926 ERROR neutron.api.v2.resource 
self.force_reraise()
  2016-07-21 18:08:55.719 7926 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 197, in 
force_reraise
  2016-07-21 18:08:55.719 7926 ERROR neutron.api.v2.resource 
six.reraise(self.type_, self.value, self.tb)
  2016-07-21 18:08:55.719 7926 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/dist-packages/oslo_db/api.py", line 138, in wrapper
  2016-07-21 18:08:55.719 7926 ERROR neutron.api.v2.resource return 
f(*args, **kwargs)
  2016-07-21 18:08:55.719 7926 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 521, in _create
  2016-07-21 18:08:55.719 7926 ERROR neutron.api.v2.resource obj = 
do_create(body)
  2016-07-21 18:08:55.719 7926 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/dist-packages/neutron/api/v2/base.py", line 503, in 
do_create
  

[Yahoo-eng-team] [Bug 1612186] Re: failed to create flavor router

2016-08-25 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/353981
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=371be082b85d8a8bdc00086b527116bef746bff3
Submitter: Jenkins
Branch:master

commit 371be082b85d8a8bdc00086b527116bef746bff3
Author: gong yong sheng 
Date:   Thu Aug 11 18:53:20 2016 +0800

Fix the attribute name: _flavor_plugin_ref

Change-Id: I673060a11103b98b7f8af593e90d2fc90bc22b15
Partially-Implements: blueprint multi-l3-backends
Closes-Bug: #1612186


** Changed in: neutron
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1612186

Title:
  failed to create flavor router

Status in neutron:
  Fix Released

Bug description:
  [gongysh@fedora23 devstack]$ neutron router-create 
--flavor-id=5c4016b6-c5ef-4b70-891d-741d376fa96f testrouter2
  Request Failed: internal server error while processing your request.
  Neutron server returns request_ids: 
['req-a1da952c-e4f6-4b09-883d-12a894f6a8d1']

  
  the exception on log is:

  
on.services.l3_router.service_providers.driver_controller.DriverController._set_router_provider
 router, precommit_create
  2016-08-11 18:48:34.282 2901 ERROR neutron.callbacks.manager Traceback (most 
recent call last):
  2016-08-11 18:48:34.282 2901 ERROR neutron.callbacks.manager   File 
"/mnt/data3/opt/stack/neutron/neutron/callbacks/manager.py", line 148, in 
_notify_loop
  2016-08-11 18:48:34.282 2901 ERROR neutron.callbacks.manager 
callback(resource, event, trigger, **kwargs)
  2016-08-11 18:48:34.282 2901 ERROR neutron.callbacks.manager   File 
"/mnt/data3/opt/stack/neutron/neutron/services/l3_router/service_providers/driver_controller.py",
 line 81, in _set_router_provider
  2016-08-11 18:48:34.282 2901 ERROR neutron.callbacks.manager drv = 
self._get_provider_for_create(context, router)
  2016-08-11 18:48:34.282 2901 ERROR neutron.callbacks.manager   File 
"/mnt/data3/opt/stack/neutron/neutron/services/l3_router/service_providers/driver_controller.py",
 line 160, in _get_provider_for_create
  2016-08-11 18:48:34.282 2901 ERROR neutron.callbacks.manager return 
self._get_l3_driver_by_flavor(context, router['flavor_id'])
  2016-08-11 18:48:34.282 2901 ERROR neutron.callbacks.manager   File 
"/mnt/data3/opt/stack/neutron/neutron/services/l3_router/service_providers/driver_controller.py",
 line 164, in _get_l3_driver_by_flavor
  2016-08-11 18:48:34.282 2901 ERROR neutron.callbacks.manager flavor = 
self._flavor_plugin.get_flavor(context, flavor_id)
  2016-08-11 18:48:34.282 2901 ERROR neutron.callbacks.manager   File 
"/mnt/data3/opt/stack/neutron/neutron/services/l3_router/service_providers/driver_controller.py",
 line 68, in _flavor_plugin
  2016-08-11 18:48:34.282 2901 ERROR neutron.callbacks.manager 
constants.FLAVORS]
  2016-08-11 18:48:34.282 2901 ERROR neutron.callbacks.manager AttributeError: 
can't set attribute
  2016-08-11 18:48:34.282 2901 ERROR neutron.callbacks.manager 
  2016-08-11 18:48:34.300 2901 ERROR neutron.api.v2.resource 
[req-a1da952c-e4f6-4b09-883d-12a894f6a8d1 e5fd88d4cebf44baa9547e45d17248cd 
3b9307233b4844c0850bd6625ab8f0e3 - - -] create failed: No details.
  2016-08-11 18:48:34.300 2901 ERROR neutron.api.v2.resource Traceback (most 
recent call last):
  2016-08-11 18:48:34.300 2901 ERROR neutron.api.v2.resource   File 
"/mnt/data3/opt/stack/neutron/neutron/api/v2/resource.py", line 79, in resource
  2016-08-11 18:48:34.300 2901 ERROR neutron.api.v2.resource result = 
method(request=request, **args)
  2016-08-11 18:48:34.300 2901 ERROR neutron.api.v2.resource   File 
"/mnt/data3/opt/stack/neutron/neutron/api/v2/base.py", line 397, in create
  2016-08-11 18:48:34.300 2901 ERROR neutron.api.v2.resource return 
self._create(request, body, **kwargs)
  2016-08-11 18:48:34.300 2901 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/oslo_db/api.py", line 151, in wrapper
  2016-08-11 18:48:34.300 2901 ERROR neutron.api.v2.resource ectxt.value = 
e.inner_exc
  2016-08-11 18:48:34.300 2901 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
  2016-08-11 18:48:34.300 2901 ERROR neutron.api.v2.resource 
self.force_reraise()
  2016-08-11 18:48:34.300 2901 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
  2016-08-11 18:48:34.300 2901 ERROR neutron.api.v2.resource 
six.reraise(self.type_, self.value, self.tb)
  2016-08-11 18:48:34.300 2901 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/oslo_db/api.py", line 139, in wrapper
  2016-08-11 18:48:34.300 2901 ERROR neutron.api.v2.resource return 
f(*args, **kwargs)
  2016-08-11 18:48:34.300 2901 ERROR neutron.api.v2.resource   File 

[Yahoo-eng-team] [Bug 1614059] Re: TrunkStub.trunk_deleted is called with NULL trunk object

2016-08-25 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/356386
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=c5629e9734f566aaf1692ed3ae016951a62bebe0
Submitter: Jenkins
Branch:master

commit c5629e9734f566aaf1692ed3ae016951a62bebe0
Author: Babu Shanmugam 
Date:   Wed Aug 17 11:00:28 2016 +

TrunkStub.trunk_deleted is called with NULL trunk object

On AFTER_DELETE event, the trunk object is set in payload.original_trunk,
but this is not used for calling TrunkStub.trunk_deleted(), instead it is
called with payload.current_trunk which is 'None'.

Closes-bug: #1614059
Change-Id: Ib09516379ef5d48bf723a9ba098d90bf6bf5a0eb


** Changed in: neutron
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1614059

Title:
  TrunkStub.trunk_deleted is called with NULL trunk object

Status in neutron:
  Fix Released

Bug description:
  On AFTER_DELETE event, the trunk object is set in
  payload.original_trunk, but this is not used for calling
  TrunkStub.trunk_deleted(), instead it is called with
  payload.current_trunk which is 'None'.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1614059/+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 1617154] [NEW] Failed to launch vpn-agent when running devstack with fwaas and vpnaas

2016-08-25 Thread Kengo Hobo
Public bug reported:

After finished running devstack completely, vpn-agent does not work.
I assume that following commit affects.
https://github.com/openstack/neutron-fwaas/commit/ea23bbc3ee4cc90280375153d13f59cb85ffe6f2

neutron-vpnaas repo should catch up with modification in  neutron-fwaas.

local.conf when I ran devstack

enable_plugin neutron-fwaas http://git.openstack.org/openstack/neutron-fwaas
enable_service q-fwaas
enable_plugin neutron-vpnaas https://git.openstack.org/openstack/neutron-vpnaas
enable_service q-vpnaas
disable_service n-net
enable_service q-svc
enable_service q-agt
enable_service q-dhcp
enable_service q-l3
enable_service q-meta
enable_service q-lbaas
enable_service q-metering
==

log in neutron-vpnaas screen after finished running devstack

ubuntu@test:~/openstack/devstack$ /usr/local/bin/neutron-vpn-agent 
--config-file /etc/neutron/neutron.conf --config-file=/etc/neutron/l3_agent.ini 
--config-file=/etc/neutron/vpn_agent.ini --config-file 
/etc/neutron/fwaas_driver.ini & echo $! 
>/opt/stack/status/stack/neutron-vpnaas.pid; fg || echo "neutron-vpnaas failed 
to start" | tee "/opt/stack/status/stack/neutron-vpnaas.failure" 
[1] 32430
/usr/local/bin/neutron-vpn-agent --config-file /etc/neutron/neutron.conf 
--config-file=/etc/neutron/l3_agent.ini 
--config-file=/etc/neutron/vpn_agent.ini --config-file 
/etc/neutron/fwaas_driver.ini
Traceback (most recent call last):
  File "/usr/local/bin/neutron-vpn-agent", line 10, in 
sys.exit(main())
  File "/opt/stack/neutron-vpnaas/neutron_vpnaas/cmd/eventlet/agent.py", line 
17, in main
agent.main()
  File "/opt/stack/neutron-vpnaas/neutron_vpnaas/services/vpn/agent.py", line 
74, in main
entry.main(manager='neutron_vpnaas.services.vpn.agent.VPNAgent')
  File "/opt/stack/neutron/neutron/agent/l3_agent.py", line 51, in main
common_config.init(sys.argv[1:])
  File "/opt/stack/neutron/neutron/common/config.py", line 72, in init
**kwargs)
  File "/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py", line 2256, 
in __call__
raise ConfigFilesNotFoundError(self._namespace._files_not_found)
oslo_config.cfg.ConfigFilesNotFoundError: Failed to find some config files: 
/etc/neutron/fwaas_driver.ini
neutron-vpnaas failed to start
===

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: vpnaas

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1617154

Title:
  Failed to launch vpn-agent when running devstack with fwaas and vpnaas

Status in neutron:
  New

Bug description:
  After finished running devstack completely, vpn-agent does not work.
  I assume that following commit affects.
  
https://github.com/openstack/neutron-fwaas/commit/ea23bbc3ee4cc90280375153d13f59cb85ffe6f2

  neutron-vpnaas repo should catch up with modification in  neutron-
  fwaas.

  local.conf when I ran devstack
  
  enable_plugin neutron-fwaas http://git.openstack.org/openstack/neutron-fwaas
  enable_service q-fwaas
  enable_plugin neutron-vpnaas 
https://git.openstack.org/openstack/neutron-vpnaas
  enable_service q-vpnaas
  disable_service n-net
  enable_service q-svc
  enable_service q-agt
  enable_service q-dhcp
  enable_service q-l3
  enable_service q-meta
  enable_service q-lbaas
  enable_service q-metering
  ==

  log in neutron-vpnaas screen after finished running devstack
  
  ubuntu@test:~/openstack/devstack$ /usr/local/bin/neutron-vpn-agent 
--config-file /etc/neutron/neutron.conf --config-file=/etc/neutron/l3_agent.ini 
--config-file=/etc/neutron/vpn_agent.ini --config-file 
/etc/neutron/fwaas_driver.ini & echo $! 
>/opt/stack/status/stack/neutron-vpnaas.pid; fg || echo "neutron-vpnaas failed 
to start" | tee "/opt/stack/status/stack/neutron-vpnaas.failure" 
  [1] 32430
  /usr/local/bin/neutron-vpn-agent --config-file /etc/neutron/neutron.conf 
--config-file=/etc/neutron/l3_agent.ini 
--config-file=/etc/neutron/vpn_agent.ini --config-file 
/etc/neutron/fwaas_driver.ini
  Traceback (most recent call last):
File "/usr/local/bin/neutron-vpn-agent", line 10, in 
  sys.exit(main())
File "/opt/stack/neutron-vpnaas/neutron_vpnaas/cmd/eventlet/agent.py", line 
17, in main
  agent.main()
File "/opt/stack/neutron-vpnaas/neutron_vpnaas/services/vpn/agent.py", line 
74, in main
  entry.main(manager='neutron_vpnaas.services.vpn.agent.VPNAgent')
File "/opt/stack/neutron/neutron/agent/l3_agent.py", line 51, in main
  common_config.init(sys.argv[1:])
File "/opt/stack/neutron/neutron/common/config.py", line 72, in init
  **kwargs)
File "/usr/local/lib/python2.7/dist-packages/oslo_config/cfg.py", line 
2256, in __call__
  raise ConfigFilesNotFoundError(self._namespace._files_not_found)
  oslo_config.cfg.ConfigFilesNotFoundError: Failed to find some config files: 

[Yahoo-eng-team] [Bug 1521064] Re: Launch Stack dialogue doesn't appear to be picking up environment values as defaults?

2016-08-25 Thread Martin Paulo
I'm still affected by this?

** Changed in: horizon
   Status: Expired => 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/1521064

Title:
  Launch Stack dialogue doesn't appear to be picking up environment
  values as defaults?

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  If I launch a stack via the dashboard and provide an environments file
  I expected that the values specified in the parameters section of the
  environment file would be the selected parameter values in the Launch
  Stack dialogue. On our Liberty installation this doesn't appear to be
  happening? Is my expectation wrong, or is something broken?

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1521064/+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 1521064] Re: Launch Stack dialogue doesn't appear to be picking up environment values as defaults?

2016-08-25 Thread Launchpad Bug Tracker
[Expired for OpenStack Dashboard (Horizon) because there has been no
activity for 60 days.]

** Changed in: horizon
   Status: Incomplete => Expired

-- 
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/1521064

Title:
  Launch Stack dialogue doesn't appear to be picking up environment
  values as defaults?

Status in OpenStack Dashboard (Horizon):
  Expired

Bug description:
  If I launch a stack via the dashboard and provide an environments file
  I expected that the values specified in the parameters section of the
  environment file would be the selected parameter values in the Launch
  Stack dialogue. On our Liberty installation this doesn't appear to be
  happening? Is my expectation wrong, or is something broken?

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1521064/+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 1617140] [NEW] form exception on host aggregate create

2016-08-25 Thread shlo
Public bug reported:

The expected error message about missing the required "name" field on the 
create-aggregate form is shown as expected only in the case that there were no 
existed aggregates in the system.
Under the circumstance that there are existed aggregates, workflow exception 
raises when create button is clicked without the required "name" field filled.

** Affects: horizon
 Importance: Undecided
 Assignee: shlo (shlo-sam)
 Status: In Progress

** Changed in: horizon
 Assignee: (unassigned) => shlo0828 (shlo-sam)

** Changed in: horizon
   Status: New => 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/1617140

Title:
  form exception on host aggregate create

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  The expected error message about missing the required "name" field on the 
create-aggregate form is shown as expected only in the case that there were no 
existed aggregates in the system.
  Under the circumstance that there are existed aggregates, workflow exception 
raises when create button is clicked without the required "name" field filled.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1617140/+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 1615788] Re: Microversions URL missing in Nova docs.

2016-08-25 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/358899
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=a4d1bf1850629b82fe291e7a4b06cd5f78370424
Submitter: Jenkins
Branch:master

commit a4d1bf1850629b82fe291e7a4b06cd5f78370424
Author: Anusha Unnam 
Date:   Mon Aug 22 22:56:52 2016 +

Correct microversions URL in api_plugins.rst

The requested URL to the microversions specific document in
api_plugins.rst is broken. Changed it to the right URL.

Change-Id: I30cf2f14d36bf7ede0a04f05b5e1e2c993403d83
Closes-Bug: #1615788


** Changed in: nova
   Status: In Progress => Fix Released

-- 
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/1615788

Title:
  Microversions URL missing in Nova docs.

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  http://docs.openstack.org/developer/nova/api_plugins.html

  Above page has "microversions specific document" link which shows up
  "The requested URL /developer/nova/api_microversions.html was not
  found on this server"

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1615788/+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 1615944] Re: [api-guide]: Outdated link reference

2016-08-25 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/358993
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=0cfc126bfd5580efa7f52ab8971ecb574ed857da
Submitter: Jenkins
Branch:master

commit 0cfc126bfd5580efa7f52ab8971ecb574ed857da
Author: Nguyen Phuong An 
Date:   Tue Aug 23 14:12:01 2016 +0700

[api-guide]: Update reference links

This patch update reference links in
http://developer.openstack.org/api-guide/compute/.

Closes-Bug: #1615944

Change-Id: Ia794f6ae2b84620636e19f9460c5b2bd07f4522d


** Changed in: nova
   Status: In Progress => Fix Released

-- 
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/1615944

Title:
  [api-guide]: Outdated link reference

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  http://developer.openstack.org/api-guide/compute/faults.html Server actions 
has a reference link:
  [1]. It is an outdated link because api-ref is changed to[2]

  [1] 
"http://developer.openstack.org/api-ref-compute-v2.1.html#os-instance-actions-v2.1;
  [2] 
"http://developer.openstack.org/api-ref/compute/#servers-run-an-action-servers-action;

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1615944/+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 1615111] Re: Useless log message about encryption key loading.

2016-08-25 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/359941
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=6bde3f3ac21de8b993103871de071a1eaba115fe
Submitter: Jenkins
Branch:master

commit 6bde3f3ac21de8b993103871de071a1eaba115fe
Author: Dolph Mathews 
Date:   Wed Aug 24 14:58:49 2016 +

Reduce log level of Fernet key count message

This reduces the log level of the fairly repetitive message regarding
the number of Fernet keys on disk, and also adds a suggestion into the
message itself about how the message can be resolved (hint: start
rotating your keys!).

Change-Id: Id35f781c7b34463c324a867c6a781572f4144311
Closes-Bug: 1615111


** Changed in: keystone
   Status: In Progress => Fix Released

-- 
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/1615111

Title:
  Useless log message about encryption key loading.

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  
  When running keystone with fernet enabled I get a lot of log messages like 
this:

   2016-08-16 19:54:28.782 2417 INFO
  keystone.token.providers.fernet.utils [req-1bbe529c-2513-487b-ac4e-
  e7ee42fe397a - - - - -] Loaded 2 encryption keys (max_active_keys=3)
  from: /etc/keystone/fernet-keys/

  
  There's no point to this being at info level. What am I as an operator 
supposed to do about it?

  Why are the keys being loaded all the time? Seems like it would be
  faster to cache them.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1615111/+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 1547283] Re: hacking rules for callback notifications

2016-08-25 Thread Armando Migliaccio
This probably does not turn out to be as simple as I initially
anticipated.

** Changed in: neutron
   Status: Confirmed => Incomplete

** Changed in: neutron
Milestone: newton-3 => None

** Changed in: neutron
 Assignee: j_king (james-agentultra) => (unassigned)

** Tags removed: low-hanging-fruit

** Changed in: neutron
   Status: Incomplete => Won't Fix

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1547283

Title:
  hacking rules for callback notifications

Status in neutron:
  Won't Fix

Bug description:
  Callbacks were made available during the Liberty timeframe [1]. They
  have been put to use in a number of places, like [2] and [3].

  Currently there's no formal convention or place where to locate
  callback notifications. This can represent a potential drawback where
  an inexperienced developer may accidentally add a duplicated
  notification (with exact signature) without carefully checking for
  existing notifications. A reviewer can also easily miss the error
  during code review.

  This could lead to callbacks called multiple times from different
  places of workflow, without the callback being able to distinguish the
  difference: so long as callbacks are designed to be idempotent, this
  is fine, but if they aren't, then this could lead to unexpected
  results.

  We should add a hacking rule that validates that a patch introducing a
  new notification hook, does not duplicate the exact signature of an
  existing notification.

  Callbacks can (un)subscribe multiple times to the same resource event,
  and that's idempotent by design.

  [1] http://docs.openstack.org/developer/neutron/devref/callbacks.html
  [2] 
https://github.com/openstack/neutron/commit/868e67b480b08cc815d802cf950547c6b5ac0153
  [3] 
https://github.com/openstack/neutron/commit/593b64dee4c0923fc85d6656e29a2beb27f27b17

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1547283/+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 1612341] Re: cpu thread pinning flavor metadef

2016-08-25 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/354213
Committed: 
https://git.openstack.org/cgit/openstack/glance/commit/?id=411418b04449f53afcbd103efcc0231fc825b0a7
Submitter: Jenkins
Branch:master

commit 411418b04449f53afcbd103efcc0231fc825b0a7
Author: Stephen Finucane 
Date:   Thu Aug 11 17:32:58 2016 +0100

Add CPU thread pinning to metadata defs

CPU pinning policy is defined, but CPU thread pinning policy is not.
Resolve this.

UpgradeImpact
Change-Id: Ie3027a9ee92ac272b6c9a07926aa529d72187d00
Closes-bug: #1612341


** Changed in: glance
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1612341

Title:
  cpu thread pinning flavor metadef

Status in Glance:
  Fix Released

Bug description:
  Similar to #1476696. Flavor namespace in glance metadefs should be
  extended with "hw:cpu_thread_policy" or "hw_cpu_thread_policy"
  property to be able to configure Nova::Flavor, Glance::Image,
  Cinder::Volume(image) using that property

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1612341/+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 1617081] [NEW] Cannot get hugepages on PPC64

2016-08-25 Thread Vincent JARDIN
Public bug reported:

We cannot spawn VMs with hugepages on PPC64, for example with the IBM P8 
systems.
The analysis shows that it is due to
  virt/libvirt/driver.py
 _has_hugepage_support()

which has only:
   supported_archs = [arch.I686, arch.X86_64]

 arch.PPC64LE is missing here.

** Affects: nova
 Importance: Undecided
 Status: New

-- 
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/1617081

Title:
  Cannot get hugepages on PPC64

Status in OpenStack Compute (nova):
  New

Bug description:
  We cannot spawn VMs with hugepages on PPC64, for example with the IBM P8 
systems.
  The analysis shows that it is due to
virt/libvirt/driver.py
   _has_hugepage_support()

  which has only:
 supported_archs = [arch.I686, arch.X86_64]

   arch.PPC64LE is missing here.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1617081/+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 1617073] [NEW] Libvirt live block migration fails due to ['migrate-incoming': Failed to bind socket: Address already in use]

2016-08-25 Thread Ken'ichi Ohmichi
Public bug reported:

On the gate job gate-tempest-dsvm-multinode-live-migration, a Tempest
test test_live_block_migration fails because an actual host which a
server stays was different from the expected.

The tempest log is http://logs.openstack.org/50/349450/5/check/gate-
tempest-dsvm-multinode-live-
migration/60eb3b3/console.html#_2016-08-25_19_14_13_416233

2016-08-25 19:14:13.416233 | 2016-08-25 19:14:13.415 | Captured traceback:
2016-08-25 19:14:13.417870 | 2016-08-25 19:14:13.417 | ~~~
2016-08-25 19:14:13.419367 | 2016-08-25 19:14:13.419 | Traceback (most 
recent call last):
2016-08-25 19:14:13.421015 | 2016-08-25 19:14:13.420 |   File 
"tempest/api/compute/admin/test_live_migration.py", line 132, in 
test_live_block_migration
2016-08-25 19:14:13.422730 | 2016-08-25 19:14:13.422 | 
self._test_live_migration()
2016-08-25 19:14:13.424314 | 2016-08-25 19:14:13.423 |   File 
"tempest/api/compute/admin/test_live_migration.py", line 128, in 
_test_live_migration
2016-08-25 19:14:13.426047 | 2016-08-25 19:14:13.425 | msg)
2016-08-25 19:14:13.427470 | 2016-08-25 19:14:13.427 |   File 
"/opt/stack/new/tempest/.tox/tempest/local/lib/python2.7/site-packages/testtools/testcase.py",
 line 411, in assertEqual
2016-08-25 19:14:13.429269 | 2016-08-25 19:14:13.428 | 
self.assertThat(observed, matcher, message)
2016-08-25 19:14:13.430954 | 2016-08-25 19:14:13.430 |   File 
"/opt/stack/new/tempest/.tox/tempest/local/lib/python2.7/site-packages/testtools/testcase.py",
 line 498, in assertThat
2016-08-25 19:14:13.432623 | 2016-08-25 19:14:13.432 | raise 
mismatch_error
2016-08-25 19:14:13.434426 | 2016-08-25 19:14:13.433 | 
testtools.matchers._impl.MismatchError: !=:
2016-08-25 19:14:13.436041 | 2016-08-25 19:14:13.435 | reference = 
u'ubuntu-xenial-2-node-rax-ord-3874987'
2016-08-25 19:14:13.437717 | 2016-08-25 19:14:13.437 | actual= 
u'ubuntu-xenial-2-node-rax-ord-3874987-181073'
2016-08-25 19:14:13.439228 | 2016-08-25 19:14:13.438 | : Live Migration 
failed. Migrations list for Instance 0240bf1c-d2cf-407f-9ecf-7acfd891b4c0: [
2016-08-25 19:14:13.440771 | 2016-08-25 19:14:13.440 | {u'migration_type': 
u'live-migration', u'instance_uuid': u'0240bf1c-d2cf-407f-9ecf-7acfd891b4c0', 
u'status': u'error', u'updated_at': u'2016-08-25T19:13:40.00', 
u'created_at': u'2016-08-25T19:13:33.00', u'source_node': None, 
u'dest_node': None, u'dest_host': None, u'dest_compute': 
u'ubuntu-xenial-2-node-rax-ord-3874987', u'source_compute': 
u'ubuntu-xenial-2-node-rax-ord-3874987-181073', u'id': 1, 
u'old_instance_type_id': 11, u'new_instance_type_id': 11}]

nova-cpu outputs the following log:

http://logs.openstack.org/50/349450/5/check/gate-tempest-dsvm-multinode-
live-
migration/60eb3b3/logs/subnode-2/screen-n-cpu.txt.gz#_2016-08-25_19_13_38_903

2016-08-25 19:13:38.904 25185 DEBUG nova.virt.libvirt.driver 
[req-04d0773e-0085-4605-ad4e-bd98329b6c4d 
tempest-LiveAutoBlockMigrationV225TestJSON-2087766141 
tempest-LiveAutoBlockMigrationV225TestJSON-2087766141] [instance: 
0240bf1c-d2cf-407f-9ecf-7acfd891b4c0] Migration operation thread notification 
thread_finished /opt/stack/new/nova/nova/virt/libvirt/driver.py:6273
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/eventlet/hubs/hub.py", line 457, 
in fire_timers
timer()
  File "/usr/local/lib/python2.7/dist-packages/eventlet/hubs/timer.py", line 
58, in __call__
cb(*args, **kw)
  File "/usr/local/lib/python2.7/dist-packages/eventlet/event.py", line 168, in 
_do_send
waiter.switch(result)
  File "/usr/local/lib/python2.7/dist-packages/eventlet/greenthread.py", line 
214, in main
result = function(*args, **kwargs)
  File "/opt/stack/new/nova/nova/utils.py", line 1066, in context_wrapper
return func(*args, **kwargs)
  File "/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 5874, in 
_live_migration_operation
instance=instance)
  File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 
220, in __exit__
self.force_reraise()
  File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 
196, in force_reraise
six.reraise(self.type_, self.value, self.tb)
  File "/opt/stack/new/nova/nova/virt/libvirt/driver.py", line 5870, in 
_live_migration_operation
bandwidth=CONF.libvirt.live_migration_bandwidth)
  File "/opt/stack/new/nova/nova/virt/libvirt/guest.py", line 568, in migrate
destination, params=params, flags=flags)
  File "/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 186, in 
doit
result = proxy_call(self._autowrap, f, *args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 144, in 
proxy_call
rv = execute(f, *args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 125, in 
execute
six.reraise(c, e, tb)
  File "/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 83, in 
tworker

[Yahoo-eng-team] [Bug 1608921] Re: The signature of the QoSPluginBase methods is wrong

2016-08-25 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/349965
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=795f5f1c872c170fb5f7391b2c280b73417aa2bf
Submitter: Jenkins
Branch:master

commit 795f5f1c872c170fb5f7391b2c280b73417aa2bf
Author: Miguel Angel Ajo 
Date:   Tue Aug 2 14:19:53 2016 +0200

Fix the QoSPluginBase methods signature.

rule_obj has been substituted for rule_cls which is more precise,
and the abstract method signature has been fixed to be correct.

Change-Id: I1dd25a346d13da80af4a1ca81f67563a8f9de94d
Closes-bug: #1608921


** Changed in: neutron
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1608921

Title:
  The signature of the QoSPluginBase methods is wrong

Status in neutron:
  Fix Released

Bug description:
  
  The automatic call wrapper calls:
  
https://github.com/openstack/neutron/blob/17d85e4748f05b9785686f1164b6a4fe2963b8eb/neutron/extensions/qos.py#L273

  
  with: (context, rule_obj,    to rule related methods.

  While the abstractmethods are defined with: (context, , rule_obj).

  
https://github.com/openstack/neutron/blob/17d85e4748f05b9785686f1164b6a4fe2963b8eb/neutron/extensions/qos.py#L314

  And btw, those are not rule_obj (objects) but rule_cls (classes).

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1608921/+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 1617049] [NEW] Nova to support resize or cold-migrate under LVM backing-storage

2016-08-25 Thread vu tran
Public bug reported:

Currently Nova doesn't support resize or cold-migrate under LVM backing-
storage.  Do resize/cold-migrate causes the following exception:

MigrationPreCheckError: Migration pre-check error: Migration is not
supported for LVM backed instances.

** Affects: nova
 Importance: Undecided
 Status: New

-- 
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/1617049

Title:
  Nova to support resize or cold-migrate under LVM backing-storage

Status in OpenStack Compute (nova):
  New

Bug description:
  Currently Nova doesn't support resize or cold-migrate under LVM
  backing-storage.  Do resize/cold-migrate causes the following
  exception:

  MigrationPreCheckError: Migration pre-check error: Migration is not
  supported for LVM backed instances.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1617049/+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 1604064] Re: ovn ml2 mechanism driver tcp connectors

2016-08-25 Thread Richard Theis
I don't think this bug impacts neutron.

** Changed in: neutron
   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/1604064

Title:
  ovn ml2 mechanism driver tcp connectors

Status in networking-ovn:
  Confirmed
Status in neutron:
  Invalid

Bug description:
  Bug description:
  When a TCP connection from the OVN ml2 mechanism driver dies (in my scenario, 
this is due to a UCARP fail over) a new TCP connection does not get generated 
for port monitoring.

  Reproduction steps:
  1. Set up UCARP between 2 nodes
  2. Set OVN north database and south database on both nodes
  3. Point the ml2 driver to the UCARP address (north and south ports)
  4. Point the ovn-controllers to the UCARP address (south database port)
  5. Boot a VM
  6. View VM entries in the north database and south database OVN tables
  7. See that port status is UP in north database
  8. See that Neutron still has status of VM as down

  **Temporary solution is to reboot neutron-server, thus resetting the TCP 
connections
  **I have not verified the problem is TCP connections, but it's currently my 
best guess.


  Linux Version: Ubuntu 14.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-ovn/+bug/1604064/+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 1608928] Re: Wrong test indentation

2016-08-25 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/349997
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=a2b7c323f29191e0f864b67bff80a11d78ee8d62
Submitter: Jenkins
Branch:master

commit a2b7c323f29191e0f864b67bff80a11d78ee8d62
Author: Tatiana Ovchinnikova 
Date:   Tue Aug 2 15:59:54 2016 +0300

Fix unit test indentation and the test itself

Unit test "test_update_project_when_default_role_does_not_exist"
from identity/projects/tests.py has wrong indentation which stops
it from running. This patch fixes it along with the test itself.

Change-Id: Id2648ac99051f225654a1f1d504b0b5927bd6656
Closes-Bug: #1608928


** Changed in: horizon
   Status: In Progress => Fix Released

-- 
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/1608928

Title:
  Wrong test indentation

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  Unit test "test_update_project_when_default_role_does_not_exist" from
  identity/projects/tests.py has wrong indentation which stops it from
  running. This should be fixed along with the test itself.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1608928/+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 1616065] Re: Inappropriate links in neutron layer-3 developer guide

2016-08-25 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/359184
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=d390f1c8500b9bbd8852e1b77a93fe35fd6e5fa7
Submitter: Jenkins
Branch:master

commit d390f1c8500b9bbd8852e1b77a93fe35fd6e5fa7
Author: venkatamahesh 
Date:   Tue Aug 23 18:25:21 2016 +0530

Added the appropriate links in developer guide

Change-Id: I68463032125bc6011979a4342045bd5ea5f3cab7
Closes-Bug: #1616065


** Changed in: neutron
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1616065

Title:
  Inappropriate links in neutron layer-3 developer guide

Status in neutron:
  Fix Released

Bug description:
  http://docs.openstack.org/developer/neutron/devref/layer3.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1616065/+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 1617009] [NEW] LBaaS V2 should not allow to config healthmonitor timeout be greater than the delay.

2016-08-25 Thread Banashankar
Public bug reported:

Create a healthmonitor, set timeout greater than delay value. It should
not succeed, because timeout value must be less than the delay value.

neutron lbaas-healthmonitor-create --delay 5 --max-retries 4 --timeout 6 --type 
HTTP --pool 8e94a810-1e5c-48ec-b943-6ea134fdaa1d
Created a new healthmonitor:
+--++
| Field | Value |
+--++
| admin_state_up | True |
| delay | 5 |
| expected_codes | 200 |
| http_method | GET |
| id | bae67511-3dc4-4095-bf4c-023cfbc6cf72 |
| max_retries | 4 |
| max_retries_down | 3 |
| name | |
| pools | {"id": "8e94a810-1e5c-48ec-b943-6ea134fdaa1d"} |
| tenant_id | 5c0465416476498fb855272f994e5a6b |
| timeout | 6 |
| type | HTTP |
| url_path | / |
+--++

** Affects: neutron
 Importance: Undecided
 Assignee: Banashankar (bkalebe)
 Status: In Progress

** Summary changed:

- LBaaS V2 should not allow to config healthmonitor timeout value be greater 
than the delay value.
+ LBaaS V2 should not allow to config healthmonitor timeout be greater than the 
delay.

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1617009

Title:
  LBaaS V2 should not allow to config healthmonitor timeout be greater
  than the delay.

Status in neutron:
  In Progress

Bug description:
  Create a healthmonitor, set timeout greater than delay value. It
  should not succeed, because timeout value must be less than the delay
  value.

  neutron lbaas-healthmonitor-create --delay 5 --max-retries 4 --timeout 6 
--type HTTP --pool 8e94a810-1e5c-48ec-b943-6ea134fdaa1d
  Created a new healthmonitor:
  +--++
  | Field | Value |
  +--++
  | admin_state_up | True |
  | delay | 5 |
  | expected_codes | 200 |
  | http_method | GET |
  | id | bae67511-3dc4-4095-bf4c-023cfbc6cf72 |
  | max_retries | 4 |
  | max_retries_down | 3 |
  | name | |
  | pools | {"id": "8e94a810-1e5c-48ec-b943-6ea134fdaa1d"} |
  | tenant_id | 5c0465416476498fb855272f994e5a6b |
  | timeout | 6 |
  | type | HTTP |
  | url_path | / |
  +--++

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1617009/+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 1616762] Re: Obsolete release notes of network_api_class and volume_api_class

2016-08-25 Thread Anusha Unnam
I think this bug is not valid.

The release notes you are referring says the options were deprecated and
removed in Newton.

There is new release notes for Newton where it says these options are
removed. Please refer to the links below,

https://github.com/openstack/nova/blob/734151daee0febedaac76079c40deaa7c0577d52/releasenotes/notes
/remove_volume_api_class-a3c618228c89f57b.yaml

https://github.com/openstack/nova/blob/9d43891099b8e1c4a242e9e030514ceea8f19e89/releasenotes/notes
/network-api-class-removed-a4a754ca24c02bde.yaml

Hence the release notes exists for that removal of config options, I am
marking this bug as Invalid.

Feel free to reopen bug if you feel that this is still valid.

** 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://bugs.launchpad.net/bugs/1616762

Title:
  Obsolete release notes of network_api_class  and volume_api_class

Status in OpenStack Compute (nova):
  Invalid

Bug description:
  network_api_class and volume_api_class options are removed in latest
  code. But release notes "nova/notes/rm_volume_manager-
  78fed5be43d285b3.yaml" says they're still valid, it should be updated.

  
https://review.openstack.org/gitweb?p=openstack/nova.git;a=blob;f=releasenotes/notes
  /rm_volume_manager-
  78fed5be43d285b3.yaml;h=dcc73e3716ccd9aecbdf33bd6afe0175ed21beac;hb=HEAD

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1616762/+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 1617001] [NEW] Dont' reinitalize themable selects once they've been initialized

2016-08-25 Thread Diana Whitten
Public bug reported:

init_themable_select should only work on things that have not already
been initialized.

** Affects: horizon
 Importance: Medium
 Assignee: Diana Whitten (hurgleburgler)
 Status: In Progress


** Tags: branding

-- 
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/1617001

Title:
  Dont' reinitalize themable selects once they've been initialized

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  init_themable_select should only work on things that have not already
  been initialized.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1617001/+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 1568708] Re: translation sync broken due to wrong usage of venv

2016-08-25 Thread Andreas Jaeger
** Changed in: neutron
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1568708

Title:
  translation sync broken due to wrong usage of venv

Status in networking-midonet:
  Fix Released
Status in networking-ovn:
  Fix Released
Status in neutron:
  Fix Released
Status in Sahara:
  Fix Released
Status in Sahara mitaka series:
  Fix Released

Bug description:
  post jobs cannot use zuul-cloner and have no access currently to
  upper-constraints. See how nova or neutron itself handle this.

  Right now the sync with translations fails:

  https://jenkins.openstack.org/job/neutron-fwaas-propose-translation-
  update/119/console

  Please fix venv tox environment.

To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-midonet/+bug/1568708/+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 1615430] Re: translation sync broken

2016-08-25 Thread Andreas Jaeger
This is fixed now, no further action needed.

** Changed in: ironic-lib
   Status: New => Invalid

** Changed in: python-glanceclient
   Status: New => Invalid

** Changed in: python-ironicclient
   Status: New => Invalid

** Changed in: python-magnumclient
   Status: New => Invalid

** Changed in: python-muranoclient
   Status: New => Invalid

** Changed in: python-openstackclient
   Status: In Progress => Fix Released

** Changed in: python-neutronclient
   Status: New => Invalid

** Changed in: neutron
   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/1615430

Title:
  translation sync broken

Status in ironic-lib:
  Invalid
Status in neutron:
  Invalid
Status in python-glanceclient:
  Invalid
Status in python-ironicclient:
  Invalid
Status in python-magnumclient:
  Invalid
Status in python-muranoclient:
  Invalid
Status in python-neutronclient:
  Invalid
Status in python-openstackclient:
  Fix Released

Bug description:
  The post jobs fail since you use zuul-cloner in tox_install.sh and
  don't set the parameters correctly.

  
  See 
http://logs.openstack.org/periodic/python-openstackclient-propose-translation-update/0f38ba9/console.html:

  2016-08-21 08:06:46.703322 | usage: zuul-cloner [-h] [-m CLONE_MAP_FILE] 
[--workspace WORKSPACE] [-v]
  2016-08-21 08:06:46.703373 |[--color] [--version] 
[--cache-dir CACHE_DIR]
  2016-08-21 08:06:46.703424 |[--branch BRANCH] 
[--project-branch PROJECT=BRANCH]
  2016-08-21 08:06:46.703475 |[--zuul-branch $ZUUL_BRANCH] 
[--zuul-ref $ZUUL_REF]
  2016-08-21 08:06:46.703516 |[--zuul-url $ZUUL_URL]
  2016-08-21 08:06:46.703567 |git_base_url projects 
[projects ...]
  2016-08-21 08:06:46.703613 | zuul-cloner: error: Some Zuul parameters are not 
set:
  2016-08-21 08:06:46.703634 |  zuul_ref

To manage notifications about this bug go to:
https://bugs.launchpad.net/ironic-lib/+bug/1615430/+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 1598879] Re: Remove internal function for validate_integer once neutron-lib patch comes in

2016-08-25 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/351088
Committed: 
https://git.openstack.org/cgit/openstack/neutron-lbaas/commit/?id=0ef9183c69d6c7f73ecc21887ec5ea18e4096da6
Submitter: Jenkins
Branch:master

commit 0ef9183c69d6c7f73ecc21887ec5ea18e4096da6
Author: Pablo Iranzo Gómez 
Date:   Thu Aug 4 11:44:27 2016 +0200

Remove internal function validate_integer already implemented in neutron-lib

This removes the internal function used initially for
validating member weights

Change-Id: Ic4ef2bf35803355b7c2295fa17d7c1503a9813d1
Closes-Bug: 1598879


** Changed in: neutron
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1598879

Title:
  Remove internal function for validate_integer once neutron-lib patch
  comes in

Status in neutron:
  Fix Released

Bug description:
  Once this review comes in: 
  https://review.openstack.org/#/c/337237/

  We can remove the internal function being introduced at
  https://review.openstack.org/#/c/336461/

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1598879/+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 1587901] Re: Cant get listener connected with l7policy through neutron api

2016-08-25 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/326018
Committed: 
https://git.openstack.org/cgit/openstack/neutron-lbaas/commit/?id=ab59666a18c219ca7dc48eb950d36abc32f39d4c
Submitter: Jenkins
Branch:master

commit ab59666a18c219ca7dc48eb950d36abc32f39d4c
Author: Evgeny Fedoruk 
Date:   Mon Jun 6 06:05:29 2016 -0700

Add missing "listener_id" attribute to L7 policy

Adding missing "listener_id" attribute to the L7 policy resource.
Updating unit tests.

Change-Id: I1e7a173642f87851c35dd8b644d1f06653d7776a
Closes-Bug: 1587901


** Changed in: neutron
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1587901

Title:
  Cant get listener connected with l7policy through neutron api

Status in neutron:
  Fix Released

Bug description:
  I'm in process of adding l7policy and l7rule resources support to Heat.
  In according plugins sometimes I need to check loadbalancer status.
  When I try to do such check from l7rule, I have only id of l7policy.
  And I have no way to get loadbalancer id through api.
  Neutron api do not returns neither the listener from show_lbaas_l7policy nor 
l7policies from list_listeners/show_listener.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1587901/+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 1616745] Re: IP allocation with Service Subnets

2016-08-25 Thread Darek Smigiel
** Also affects: neutron
   Importance: Undecided
   Status: New

** Changed in: neutron
   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/1616745

Title:
  IP allocation with Service Subnets

Status in neutron:
  Invalid
Status in openstack-manuals:
  In Progress

Bug description:
  https://review.openstack.org/350613
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit de3a3cda740dfa22152c8224c39aeb9e51642d93
  Author: John Davidge 
  Date:   Mon Aug 1 14:04:08 2016 +0100

  IP allocation with Service Subnets
  
  This changes the way that IPAM decides which subnets to use when
  assigning IPs to newly created ports. If the port has a defined
  device_owner, this is used to filter available subnets to choose
  from only those with a matching service_type or no service_type
  at all.
  
  If the given network has no service subnets, then the existing
  behaviour is used.
  
  A new IPAM exception is introduced to handle the following scenarios:
  1. A port is created with a device_owner and only non-matching service
 subnets exist.
  2. A port is created without a device owner, and no subnets exist
 without a service_type.
  
  With this patch, service subnets are now usable.
  
  Implements: blueprint service-subnets
  APIImpact: subnet-create and subnet-update with service_types
  DocImpact: IPs assigned to new ports will now come from a service subnet
  matching the port device_owner, if one exists.
  
  Closes-Bug: 1544768
  Change-Id: If3dd94a46bdee24c13d1f17c4f2e69af0cb8af63

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1616745/+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 1616282] Re: creating ipv6 subnet on ipv6 vm will cause loss of connectivity

2016-08-25 Thread Kevin Benton
** Project changed: neutron => devstack

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1616282

Title:
  creating ipv6 subnet on ipv6 vm will cause loss of connectivity

Status in devstack:
  Fix Released

Bug description:
  The gate is all clogged, as any DSVM test using neutron (most of
  them), when it gets an IPv6 only OSIC node, seems to lose connectivity
  when devstack creates the internal neutron ipv6.

  Not sure of root cause yet, but starting this bug here.

  Please see starting at 01:48:

  http://eavesdrop.openstack.org/irclogs/%23openstack-infra
  /%23openstack-infra.2016-08-24.log.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/devstack/+bug/1616282/+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 1614792] Re: Strongswan: symbol for auth algorithm sha256 is not sha2_256

2016-08-25 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/357567
Committed: 
https://git.openstack.org/cgit/openstack/neutron-vpnaas/commit/?id=41805f1e60af749605ad8db39580ba8b9fce8802
Submitter: Jenkins
Branch:master

commit 41805f1e60af749605ad8db39580ba8b9fce8802
Author: nick.zhuyj 
Date:   Thu Aug 18 20:47:42 2016 -0500

Strongswan: Fix incorrect strongswan auth algorithm sha256 symbol

The symbol for auth algorithm sha256 is different in openswan/libreswan
and strongswan. For openswan/libreswan it is sha2_256 and for strongswan
it should be sha256. This patch override DIALECT_MAP['sha256'] to 'sha256'
in strongswan device driver.

Closes-Bug: #1614792

Change-Id: I1cfb3e350dfebe266554ead000df1474c87a6e5b


** Changed in: neutron
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1614792

Title:
  Strongswan: symbol for auth algorithm sha256 is not sha2_256

Status in neutron:
  Fix Released

Bug description:
  The symbol for auth algorithm sha256 is different for openswan/libreswan and 
strongswan.
  For openswan/libreswan it should be sha2_256.
  and fow strongswan, it should be sha256.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1614792/+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 1616938] [NEW] XenAPI: failed to create image from volume

2016-08-25 Thread Jianghua Wang
Public bug reported:

XenServer with dirver XenAPI, it always fails to create image from
volume.

Tempest test:
tempest.scenario.test_volume_boot_pattern.TestVolumeBootPatternV2.test_create_ebs_image_and_check_boot

2016-08-24 08:13:24.636 27347 DEBUG nova.compute.api 
[req-fd7afac4-a2ee-41cb-b785-02766806db26 
tempest-TestVolumeBootPatternV2-1645487335 
tempest-TestVolumeBootPatternV2-1645487335] [instance: 
5d5a8b10-655c-457e-8ad9-edbfb6ecd278] Creating snapshot from volume 
9953359c-327a-41bf-abec-f3c3da416390. snapshot_volume_backed 
/opt/stack/new/nova/nova/compute/api.py:2445^M
2016-08-24 08:13:25.964 27347 INFO os_vif 
[req-fd7afac4-a2ee-41cb-b785-02766806db26 
tempest-TestVolumeBootPatternV2-1645487335 
tempest-TestVolumeBootPatternV2-1645487335] Loaded VIF plugin class '' with name 'ovs'^M
2016-08-24 08:13:25.965 27347 INFO os_vif 
[req-fd7afac4-a2ee-41cb-b785-02766806db26 
tempest-TestVolumeBootPatternV2-1645487335 
tempest-TestVolumeBootPatternV2-1645487335] Loaded VIF plugin class '' with name 
'linux_bridge'^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions 
[req-fd7afac4-a2ee-41cb-b785-02766806db26 
tempest-TestVolumeBootPatternV2-1645487335 
tempest-TestVolumeBootPatternV2-1645487335] Unexpected exception in API method^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions Traceback 
(most recent call last):^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/api/openstack/extensions.py", line 338, in wrapped^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions return 
f(*args, **kwargs)^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/api/openstack/common.py", line 372, in inner^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions return 
f(*args, **kwargs)^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/api/validation/__init__.py", line 73, in wrapper^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/api/validation/__init__.py", line 73, in wrapper^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions return 
func(*args, **kwargs)^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/api/openstack/compute/servers.py", line 1072, in 
_action_create_image^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions 
metadata)^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/compute/api.py", line 146, in inner^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions return 
f(self, context, instance, *args, **kw)^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/compute/api.py", line 2463, in 
snapshot_volume_backed^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions return 
self.image_api.create(context, image_meta)^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/image/api.py", line 106, in create^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions return 
session.create(context, image_info, data=data)^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/image/glance.py", line 626, in create^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions data, 
force_activate)^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/image/glance.py", line 658, in _create_v2^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions context, 
2, 'create', **sent_service_image_meta)^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions   File 
"/opt/stack/new/nova/nova/image/glance.py", line 174, in call^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions result = 
getattr(client.images, method)(*args, **kwargs)^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions   File 
"/usr/local/lib/python2.7/dist-packages/glanceclient/v2/images.py", line 233, 
in create^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions raise 
TypeError(encodeutils.exception_to_unicode(e))^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions TypeError: 
Unable to set 'disk_format' to 'qcow2'. Reason: 'qcow2' is not one of [None, 
u'ami', u'ari', u'aki', u'vhd', u'raw', u'iso']^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions ^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions Failed 
validating u'enum' in schema[u'properties'][u'disk_format']:^M
2016-08-24 08:13:26.049 27347 ERROR nova.api.openstack.extensions 

[Yahoo-eng-team] [Bug 1616837] Re: neutron-sriov-agent crash when SRIOV and PCI-PT with same NIC as target.

2016-08-25 Thread prabhu murthy
** Project changed: nova => 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/1616837

Title:
  neutron-sriov-agent crash when SRIOV and PCI-PT with same NIC as
  target.

Status in neutron:
  New

Bug description:
  the SRIOV and PCIPT use case

  
  1)hed1 and hed2  is created for both sriov and pci-pt
  2)boot  pci-pt vm on hed2
  3)agent is down now and can not boot vm on hed1

  
  User impact : any SR-IOV VF  are no longer available for instances.

  # Create instance that consume PCI NIC shared with SRIOV.
   sriov-agent figures out NIC is gone and loop with following message and 
agent is still alive:
  {code}2016-08-19 12:44:28.770 24473 INFO 
neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent 
[req-ec987933-8dbe-4d0b-9df7-f9b9250968de - - - - -] Agent out of sync with 
plugin!
  2016-08-19 12:44:28.771 24473 DEBUG neutron.agent.linux.utils 
[req-ec987933-8dbe-4d0b-9df7-f9b9250968de - - - - -] Running command (rootwrap 
daemon): ['ip', 'link', 'show', 'hed2'] execute_rootwrap_daemon /opt/
  
stack/venv/neutron-20160811T121326Z/lib/python2.7/site-packages/neutron/agent/linux/utils.py:100
  2016-08-19 12:44:28.779 24473 ERROR neutron.agent.linux.utils 
[req-ec987933-8dbe-4d0b-9df7-f9b9250968de - - - - -] Exit code: 1; Stdin: ; 
Stdout: ; Stderr: Device "hed2" does not exist.

  2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib 
[req-ec987933-8dbe-4d0b-9df7-f9b9250968de - - - - -] Failed executing ip command
  2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib Traceback (most recent 
call last):
  2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib   File 
"/opt/stack/venv/neutron-20160811T121326Z/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/mech_sriov/agent
  /pci_lib.py", line 83, in get_assigned_macs
  2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib out = 
self._as_root([], "link", ("show", self.dev_name))
  2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib   File 
"/opt/stack/venv/neutron-20160811T121326Z/lib/python2.7/site-packages/neutron/agent/linux/ip_lib.py",
 line 94, in
  _as_root
  2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib 
log_fail_as_error=self.log_fail_as_error)
  2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib   File 
"/opt/stack/venv/neutron-20160811T121326Z/lib/python2.7/site-packages/neutron/agent/linux/ip_lib.py",
 line 103, in
   _execute
  2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib 
log_fail_as_error=log_fail_as_error)
  2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib   File 
"/opt/stack/venv/neutron-20160811T121326Z/lib/python2.7/site-packages/neutron/agent/linux/utils.py",
 line 140, in
  execute
  2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib raise RuntimeError(msg)
  2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib RuntimeError: Exit code: 
1; Stdin: ; Stdout: ; Stderr: Device "hed2" does not exist.
  2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib
  2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib
  2016-08-19 12:44:28.781 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent 
[req-ec987933-8dbe-4d0b-9df7-f9b9250968de - - - - -] Error in agent loop. 
Devices info: {}
  2016-08-19 12:44:28.781 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent Traceback (most 
recent call last):
  2016-08-19 12:44:28.781 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent   File 
"/opt/stack/venv/neutron-20160811T121326Z/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/mech_sri
  ov/agent/sriov_nic_agent.py", line 377, in daemon_loop
  2016-08-19 12:44:28.781 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent device_info = 
self.scan_devices(devices, updated_devices_copy)
  2016-08-19 12:44:28.781 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent   File 
"/opt/stack/venv/neutron-20160811T121326Z/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/mech_sri
  ov/agent/sriov_nic_agent.py", line 196, in scan_devices
  2016-08-19 12:44:28.781 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent curr_devices = 
self.eswitch_mgr.get_assigned_devices_info()
  2016-08-19 12:44:28.781 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent   File 

[Yahoo-eng-team] [Bug 1616921] [NEW] Instances pagination does not have prev link

2016-08-25 Thread Sergei Chipiga
Public bug reported:

Steps:
- Login as admin
- Launch 3 instances
- In user settings set **items per page** as 1
- Go to instances page
- Click **next** link

Expected result:
- **prev** link to navigate to previous page is present

Actual result:
- **prev** link is absent

** Affects: horizon
 Importance: Undecided
 Status: New

** Attachment added: "Instances   OpenStack Dashboard.png"
   
https://bugs.launchpad.net/bugs/1616921/+attachment/4727595/+files/Instances%20%20%20OpenStack%20Dashboard.png

-- 
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/1616921

Title:
  Instances pagination does not have prev link

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Steps:
  - Login as admin
  - Launch 3 instances
  - In user settings set **items per page** as 1
  - Go to instances page
  - Click **next** link

  Expected result:
  - **prev** link to navigate to previous page is present

  Actual result:
  - **prev** link is absent

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1616921/+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 1616917] [NEW] volume backup options not enabled by default

2016-08-25 Thread sandeep nandal
Public bug reported:

As volumes backup management functionality is added in horizon through
blueprint https://blueprints.launchpad.net/horizon/+spec/volume-backups,
but the options are not enabled by default.

In order to enable the volume backup management functionality in the
horizon, the user has to to enable the backup options in /etc/openstack-
dashboard/local_settings file:-

OPENSTACK_CINDER_FEATURES = { 'enable_backup': True,}


This option must be enabled by default.

** Affects: horizon
 Importance: Undecided
 Assignee: sandeep nandal (nandal)
 Status: New

** Changed in: horizon
 Assignee: (unassigned) => sandeep nandal (nandal)

-- 
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/1616917

Title:
  volume backup options not enabled by default

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  As volumes backup management functionality is added in horizon through
  blueprint https://blueprints.launchpad.net/horizon/+spec/volume-
  backups, but the options are not enabled by default.

  In order to enable the volume backup management functionality in the
  horizon, the user has to to enable the backup options in /etc
  /openstack-dashboard/local_settings file:-

  OPENSTACK_CINDER_FEATURES = { 'enable_backup': True,}

  
  This option must be enabled by default.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1616917/+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 1603307] Re: horizon plugin gives the KeyError

2016-08-25 Thread Kirill Zaitsev
** Changed in: murano
   Status: In Progress => Invalid

-- 
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/1603307

Title:
  horizon plugin gives the KeyError

Status in OpenStack Dashboard (Horizon):
  In Progress
Status in Murano:
  Invalid

Bug description:
  horizon master with murano-dashboard, open the murano-dashboard, give the 
error:
File 
"/opt/openstack/horizon/.tox/venv/lib/python2.7/site-packages/django/dispatch/dispatcher.py",
 line 189, in send
  response = receiver(signal=self, sender=sender, **named)
File "/opt/openstack/horizon/horizon/templatetags/angular.py", line 36, in 
update_angular_template_hash
  theme = context['THEME']  # current theme being compressed
  KeyError: 'THEME'

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1603307/+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 1616745] Re: IP allocation with Service Subnets

2016-08-25 Thread John Davidge
** Project changed: neutron => openstack-manuals

** Changed in: openstack-manuals
 Assignee: (unassigned) => John Davidge (john-davidge)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1616745

Title:
  IP allocation with Service Subnets

Status in openstack-manuals:
  New

Bug description:
  https://review.openstack.org/350613
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit de3a3cda740dfa22152c8224c39aeb9e51642d93
  Author: John Davidge 
  Date:   Mon Aug 1 14:04:08 2016 +0100

  IP allocation with Service Subnets
  
  This changes the way that IPAM decides which subnets to use when
  assigning IPs to newly created ports. If the port has a defined
  device_owner, this is used to filter available subnets to choose
  from only those with a matching service_type or no service_type
  at all.
  
  If the given network has no service subnets, then the existing
  behaviour is used.
  
  A new IPAM exception is introduced to handle the following scenarios:
  1. A port is created with a device_owner and only non-matching service
 subnets exist.
  2. A port is created without a device owner, and no subnets exist
 without a service_type.
  
  With this patch, service subnets are now usable.
  
  Implements: blueprint service-subnets
  APIImpact: subnet-create and subnet-update with service_types
  DocImpact: IPs assigned to new ports will now come from a service subnet
  matching the port device_owner, if one exists.
  
  Closes-Bug: 1544768
  Change-Id: If3dd94a46bdee24c13d1f17c4f2e69af0cb8af63

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-manuals/+bug/1616745/+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 1603307] Re: horizon plugin gives the KeyError

2016-08-25 Thread Timur Sufiev
New patch is here: https://review.openstack.org/#/c/359850/

** Changed in: murano
   Status: Confirmed => In Progress

** Changed in: horizon
 Assignee: David Lyle (david-lyle) => Timur Sufiev (tsufiev-x)

** Changed in: horizon
   Status: Fix Released => In Progress

** Changed in: horizon
Milestone: newton-3 => newton-rc1

** Changed in: horizon
   Importance: Low => High

-- 
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/1603307

Title:
  horizon plugin gives the KeyError

Status in OpenStack Dashboard (Horizon):
  In Progress
Status in Murano:
  In Progress

Bug description:
  horizon master with murano-dashboard, open the murano-dashboard, give the 
error:
File 
"/opt/openstack/horizon/.tox/venv/lib/python2.7/site-packages/django/dispatch/dispatcher.py",
 line 189, in send
  response = receiver(signal=self, sender=sender, **named)
File "/opt/openstack/horizon/horizon/templatetags/angular.py", line 36, in 
update_angular_template_hash
  theme = context['THEME']  # current theme being compressed
  KeyError: 'THEME'

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1603307/+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 1616827] [NEW] Network topology fail if router service is disabled

2016-08-25 Thread Kevin Tibi
Public bug reported:

In neutron, L3 service is disable.

In horizon, I disabled router features in local_setting

OPENSTACK_NEUTRON_NETWORK = {
'enable_distributed_router': False,
'enable_firewall': False,
'enable_ha_router': False,
'enable_lb': True,
'enable_quotas': True,
'enable_security_group': True,
'enable_vpn': False,
'profile_support': None,
'enable_router': False,
'enable_ipv6': False,
}

But network topology fail because neutron return 404 when horizon GET on
/v2.0/routers.json

Horizon trace :

2016-08-25 09:21:02,416 5007 ERROR django.request Internal Server Error: 
/dashboard/project/network_topology/
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/django/core/handlers/base.py", line 
132, in get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/usr/lib/python2.7/site-packages/horizon/decorators.py", line 36, in dec
return view_func(request, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/horizon/decorators.py", line 52, in dec
return view_func(request, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/horizon/decorators.py", line 36, in dec
return view_func(request, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/horizon/decorators.py", line 84, in dec
return view_func(request, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/django/views/generic/base.py", line 
71, in view
return self.dispatch(request, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/django/views/generic/base.py", line 
89, in dispatch
return handler(request, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/django/views/generic/base.py", line 
158, in get
context = self.get_context_data(**kwargs)
  File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/project/network_topology/views.py",
 line 204, in get_context_data
context['instance_quota_exceeded'] = self._quota_exceeded('instances')
  File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/dashboards/project/network_topology/views.py",
 line 194, in _quota_exceeded
usages = quotas.tenant_quota_usages(self.request)
  File "/usr/lib/python2.7/site-packages/horizon/utils/memoized.py", line 90, 
in wrapped
value = cache[key] = func(*args, **kwargs)
  File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/usage/quotas.py",
 line 376, in tenant_quota_usages
_get_tenant_network_usages(request, usages, disabled_quotas, tenant_id)
  File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/usage/quotas.py",
 line 333, in _get_tenant_network_usages
routers = neutron.router_list(request)
  File 
"/usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/api/neutron.py",
 line 950, in router_list
routers = neutronclient(request).list_routers(**params).get('routers')
  File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
97, in with_params
ret = self.function(instance, *args, **kwargs)
  File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
750, in list_routers
**_params)
  File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
373, in list
for r in self._pagination(collection, path, **params):
  File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
388, in _pagination
res = self.get(path, params=params)
  File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
358, in get
headers=headers, params=params)
  File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
335, in retry_request
headers=headers, params=params)
  File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
298, in do_request
self._handle_fault_response(status_code, replybody, resp)
  File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
273, in _handle_fault_response
exception_handler_v20(status_code, error_body)
  File "/usr/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
84, in exception_handler_v20
request_ids=request_ids)
NotFound: 404 Not Found

The resource could not be found.


Neutron logs :

"GET /v2.0/routers.json HTTP/1.1" 404 266 0.004036


I guess when  'enable_router': False,  we need to disable router features in 
network topology.

** 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/1616827

Title:
  Network topology fail if router service is disabled

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  In neutron, L3 service is disable.

  In horizon, I disabled router features in local_setting

 

[Yahoo-eng-team] [Bug 1614361] Re: tox.ini needs to be updated as openstack infra now supports upper constraints

2016-08-25 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/358953
Committed: 
https://git.openstack.org/cgit/openstack/vmware-nsx/commit/?id=d1b4a4b8b5eef2d3980137bba3b76eed7fb600a5
Submitter: Jenkins
Branch:master

commit d1b4a4b8b5eef2d3980137bba3b76eed7fb600a5
Author: AvnishPal 
Date:   Tue Aug 23 10:34:30 2016 +0530

Update tox.ini for upper constraints

Openstack infra now supports upper constraints for
all jobs. Updated tox.ini to use upper constraints
for all jobs.

Change-Id: Ie446293f52a87ba89e090d566e3d62141a5c4f51
Closes-Bug: #1614361


** Changed in: vmware-nsx
   Status: In Progress => Fix Released

-- 
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/1614361

Title:
  tox.ini needs to be updated as openstack infra now supports upper
  constraints

Status in Cinder:
  In Progress
Status in Designate:
  Fix Released
Status in Glance:
  In Progress
Status in heat:
  In Progress
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic Inspector:
  Fix Released
Status in Mistral:
  Fix Released
Status in Murano:
  Fix Released
Status in networking-ovn:
  Invalid
Status in octavia:
  Fix Released
Status in python-muranoclient:
  Fix Released
Status in tacker:
  In Progress
Status in OpenStack DBaaS (Trove):
  Invalid
Status in vmware-nsx:
  Fix Released
Status in zaqar:
  Fix Released
Status in Zaqar-ui:
  Fix Released

Bug description:
  Openstack infra now supports upper constraints for releasenotes, cover, venv 
targets.
  tox.ini uses install_command for these targets, which can now be safely 
removed.
  Reference for mail that details this support: 
http://lists.openstack.org/pipermail/openstack-dev/2016-August/101474.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1614361/+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 1616837] [NEW] neutron-sriov-agent crash when SRIOV and PCI-PT with same NIC as target.

2016-08-25 Thread prabhu murthy
Public bug reported:

the SRIOV and PCIPT use case


1)hed1 and hed2  is created for both sriov and pci-pt
2)boot  pci-pt vm on hed2
3)agent is down now and can not boot vm on hed1


User impact : any SR-IOV VF  are no longer available for instances.

# Create instance that consume PCI NIC shared with SRIOV.
 sriov-agent figures out NIC is gone and loop with following message and agent 
is still alive:
{code}2016-08-19 12:44:28.770 24473 INFO 
neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent 
[req-ec987933-8dbe-4d0b-9df7-f9b9250968de - - - - -] Agent out of sync with 
plugin!
2016-08-19 12:44:28.771 24473 DEBUG neutron.agent.linux.utils 
[req-ec987933-8dbe-4d0b-9df7-f9b9250968de - - - - -] Running command (rootwrap 
daemon): ['ip', 'link', 'show', 'hed2'] execute_rootwrap_daemon /opt/
stack/venv/neutron-20160811T121326Z/lib/python2.7/site-packages/neutron/agent/linux/utils.py:100
2016-08-19 12:44:28.779 24473 ERROR neutron.agent.linux.utils 
[req-ec987933-8dbe-4d0b-9df7-f9b9250968de - - - - -] Exit code: 1; Stdin: ; 
Stdout: ; Stderr: Device "hed2" does not exist.

2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib 
[req-ec987933-8dbe-4d0b-9df7-f9b9250968de - - - - -] Failed executing ip command
2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib Traceback (most recent 
call last):
2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib   File 
"/opt/stack/venv/neutron-20160811T121326Z/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/mech_sriov/agent
/pci_lib.py", line 83, in get_assigned_macs
2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib out = 
self._as_root([], "link", ("show", self.dev_name))
2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib   File 
"/opt/stack/venv/neutron-20160811T121326Z/lib/python2.7/site-packages/neutron/agent/linux/ip_lib.py",
 line 94, in
_as_root
2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib 
log_fail_as_error=self.log_fail_as_error)
2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib   File 
"/opt/stack/venv/neutron-20160811T121326Z/lib/python2.7/site-packages/neutron/agent/linux/ip_lib.py",
 line 103, in
 _execute
2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib 
log_fail_as_error=log_fail_as_error)
2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib   File 
"/opt/stack/venv/neutron-20160811T121326Z/lib/python2.7/site-packages/neutron/agent/linux/utils.py",
 line 140, in
execute
2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib raise RuntimeError(msg)
2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib RuntimeError: Exit code: 
1; Stdin: ; Stdout: ; Stderr: Device "hed2" does not exist.
2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib
2016-08-19 12:44:28.780 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.pci_lib
2016-08-19 12:44:28.781 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent 
[req-ec987933-8dbe-4d0b-9df7-f9b9250968de - - - - -] Error in agent loop. 
Devices info: {}
2016-08-19 12:44:28.781 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent Traceback (most 
recent call last):
2016-08-19 12:44:28.781 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent   File 
"/opt/stack/venv/neutron-20160811T121326Z/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/mech_sri
ov/agent/sriov_nic_agent.py", line 377, in daemon_loop
2016-08-19 12:44:28.781 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent device_info = 
self.scan_devices(devices, updated_devices_copy)
2016-08-19 12:44:28.781 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent   File 
"/opt/stack/venv/neutron-20160811T121326Z/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/mech_sri
ov/agent/sriov_nic_agent.py", line 196, in scan_devices
2016-08-19 12:44:28.781 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent curr_devices = 
self.eswitch_mgr.get_assigned_devices_info()
2016-08-19 12:44:28.781 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent   File 
"/opt/stack/venv/neutron-20160811T121326Z/lib/python2.7/site-packages/neutron/plugins/ml2/drivers/mech_sri
ov/agent/eswitch_manager.py", line 277, in get_assigned_devices_info
2016-08-19 12:44:28.781 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent for device in 
embedded_switch.get_assigned_devices_info():
2016-08-19 12:44:28.781 24473 ERROR 
neutron.plugins.ml2.drivers.mech_sriov.agent.sriov_nic_agent   File 

[Yahoo-eng-team] [Bug 1616831] [NEW] cloud-init doesn't prefer new APT config format when old and new are provided

2016-08-25 Thread Andres Rodriguez
Public bug reported:

Trying to use the new configuration format of APT configuration while
still providing the OLD format, causes cloud-init fails to configure
APT.

cloud-init should be ignoring the old format if the new format is
provided to ensure backwards compat.

This is a problem for MAAS provided that we cannot safely differentiate
/ determine what cloud-init version we are using for a specific release
we are deploying, and as such, we still need to send the old config
while still providing the new one because:

1. Yakkety uses newer cloud-init with new format above
2. Xenial, Trusty, Precise use older cloud-init that doesn't support new format.

And this is a problem because:

1. MAAS won't be able to use derived repositories in Xenial, Trusty, Precise 
until this gets backported into cloud-init.
2. Commission is done in Xenial, while deployment in Yakkety, but both may 
require the same config, but it is only supported in Yakkety's cloud-init.
3. Users may be using old images that may not contain new cloud-init at all, 
and even though the release already supports it, the image they are using 
doesn't and they have to continue to use the old format.
4. MAAS cannot differentiate/identify which cloud-init version its being used, 
as such, needs to sends both old and new config.

Aug 25 09:44:17 node02 [CLOUDINIT] cc_apt_configure.py[ERROR]: Error in
apt configuration: old and new format of apt features are mutually
exclusive ('apt':'{'primary': [{'arches': ['default'], 'uri':
'http://us.archive.ubuntu.com/ubuntu'}], 'preserve_sources_list': True,
'security': [{'arches': ['default'], 'uri':
'http://us.archive.ubuntu.com/ubuntu'}], 'sources': {'launchpad_3':
{'source': 'deb http://ppa.launchpad.net/maas/next/ubuntu yakkety
main'}}}' vs 'apt_proxy' key)


Aug 25 09:51:58 node02 [CLOUDINIT] util.py[DEBUG]: Running module apt-configure 
() 
failed#012Traceback (most recent call last):#012  File 
"/usr/lib/python3/dist-packages/cloudinit/stages.py", line 785, in 
_run_modules#012freq=freq)#012  File 
"/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 70, in run#012
return self._runners.run(name, functor, args, freq, clear_on_fail)#012  File 
"/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 199, in run#012
results = functor(*args)#012  File 
"/usr/lib/python3/dist-packages/cloudinit/config/cc_apt_configure.py", line 77, 
in handle#012ocfg = convert_to_v3_apt_format(ocfg)#012  File 
"/usr/lib/python3/dist-packages/cloudinit/config/cc_apt_configure.py", line 
527, in convert_to_v3_apt_format#012cfg = 
convert_v2_to_v3_apt_format(cfg)#012  File 
"/usr/lib/python3/dist-packages/cloudinit/config/cc_apt_
 configure.py", line 489, in convert_v2_to_v3_apt_format#012raise 
ValueError(msg)#012ValueError: Error in apt configuration: old and new format 
of apt features are mutually exclusive ('apt':'{'preserve_sources_list': True, 
'primary': [{'uri': 'http://us.archive.ubuntu.com/ubuntu', 'arches': 
['default']}], 'security': [{'uri': 'http://us.archive.ubuntu.com/ubuntu', 
'arches': ['default']}], 'sources': {'launchpad_3': {'source': 'deb 
http://ppa.launchpad.net/maas/next/ubuntu yakkety main'}}}' vs 'apt_proxy, 
apt_preserve_sources_list' key)

** Affects: cloud-init
 Importance: Undecided
 Status: New

** Affects: cloud-init (Ubuntu)
 Importance: Undecided
 Status: New

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Description changed:

  Trying to use the new configuration format of APT configuration while
  still providing the OLD format, causes cloud-init fails to configure
  APT.
  
  cloud-init should be ignoring the old format if the new format is
  provided to ensure backwards compat.
  
  This is a problem for MAAS provided that we cannot safely differentiate
  / determine what cloud-init version we are using for a specific release
  we are deploying, and as such, we still need to send the old config
  while still providing the new one because:
  
  1. Yakkety uses newer cloud-init with new format above
  2. Xenial, Trusty, Precise use older cloud-init that doesn't support new 
format.
  
  And this is a problem because:
  
  1. MAAS won't be able to use derived repositories in Xenial, Trusty, Precise 
until this gets backported into cloud-init.
  2. Commission is done in Xenial, while deployment in Yakkety, but both may 
require the same config, but it is only supported in Yakkety's cloud-init.
  3. Users may be using old images that may not contain new cloud-init at all, 
and even though the release already supports it, the image they are using 
doesn't and they have to continue to use the old format.
  4. MAAS cannot differentiate/identify which cloud-init version its being 
used, as such, needs to sends both old and new config.
+ 
+ 
+ Aug 25 09:44:17 node02 [CLOUDINIT] cc_apt_configure.py[ERROR]: Error in apt 
configuration: old and new format of apt features are mutually exclusive 

[Yahoo-eng-team] [Bug 1613542] Re: tempest.conf doesn't contain $project in [service_available] section

2016-08-25 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/355535
Committed: 
https://git.openstack.org/cgit/openstack/ceilometer/commit/?id=f2b6064d7f49cdc8fe5ed1f60851d38d3f09b675
Submitter: Jenkins
Branch:master

commit f2b6064d7f49cdc8fe5ed1f60851d38d3f09b675
Author: Thomas Bechtold 
Date:   Mon Aug 15 17:44:50 2016 +0200

Fix tempest.conf generation

[service_available] isn't being generated. This patch fixes it.

Closes-Bug: #1613542
Change-Id: Ic1ef8f2f9c4e79e0ee35e2e78311d96d00f014e8


** Changed in: ceilometer
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1613542

Title:
  tempest.conf doesn't contain $project in [service_available] section

Status in Aodh:
  Fix Released
Status in Ceilometer:
  Fix Released
Status in ec2-api:
  In Progress
Status in Gnocchi:
  In Progress
Status in Ironic:
  In Progress
Status in Ironic Inspector:
  In Progress
Status in OpenStack Identity (keystone):
  Invalid
Status in Magnum:
  Fix Released
Status in neutron:
  New
Status in OpenStack Data Processing ("Sahara") sahara-tests:
  In Progress
Status in vmware-nsx:
  Fix Released

Bug description:
  When generating the tempest conf, the tempest plugins need to register the 
config options.
  But for the [service_available] section, ceilometer (and the other mentioned 
projects) doesn't register any value so it's missng in the tempest sample 
config.

  Steps to reproduce:

  $ tox -egenconfig
  $ source .tox/genconfig/bin/activate
  $ oslo-config-generator --config-file 
.tox/genconfig/lib/python2.7/site-packages/tempest/cmd/config-generator.tempest.conf
 --output-file tempest.conf.sample

  Now check the [service_available] section from tempest.conf.sample

To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1613542/+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 1494287] Re: Urls in AVAILABLE_REGIONS setting fail to match against Keystone API endpoint in catalog

2016-08-25 Thread Rob Cresswell
I believe this was fixed by a d_o_a change previously.

** Changed in: horizon
 Assignee: Daniel Park (daniepar) => (unassigned)

** Changed in: horizon
   Status: In Progress => Fix Released

-- 
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/1494287

Title:
  Urls in AVAILABLE_REGIONS setting fail to match against Keystone API
  endpoint in catalog

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  The problem is that keystone endpoint urls from AVAILABLE_REGIONS
  settings has suffix defining which keystone version should be used,
  and that version does not always match with the version inside the url
  returned from keystone catalog.

  More concrete example (local_settings.py snippet):

  OPENSTACK_API_VERSIONS = {
 "data-processing": 1.1,
 "identity": 3,
 "volume": 2,
  }

  OPENSTACK_HOST = "192.168.0.1"
  OPENSTACK_KEYSTONE_URL = "http://%s:5000/v3; % OPENSTACK_HOST
  OPENSTACK_KEYSTONE_DEFAULT_ROLE = "_member_"

  #For multiple regions uncomment this configuration, and add (endpoint, title).
  AVAILABLE_REGIONS = [
 (OPENSTACK_KEYSTONE_URL, '7.0 lab'),
 ('http://192.168.10.1:5000/v2.0', '7.0 sahara lab'),
  ]

  Once I log in to '7.0 lab' Keystone endpoint here
  
https://github.com/openstack/django_openstack_auth/blob/1.4.0/openstack_auth/views.py#L124
  region is being set to 'http://192.168.0.1:5000/v2.0' which causes
  'region_name' on the next line to become None (since this url is not
  found inside 'regions' dict, see line above). See results on a
  screenshot below.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1494287/+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 1401101] Re: Nova launch instance from snapshot ignores --min-disk

2016-08-25 Thread Rob Cresswell
Marking released, as it seems to be fixed in Master.

** Changed in: horizon
   Status: In Progress => Fix Released

-- 
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/1401101

Title:
  Nova launch instance from snapshot ignores --min-disk

Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in OpenStack Compute (nova):
  Invalid

Bug description:
  Description of problem: Nova launch instance from Horizon, if glance
  image has --min-disk set insufficient flavors are filtered out. When
  launching from a snapshot with --min-disk set, flavors aren't filtered
  out, they all show up even flavors with insufficient disk size.

  
  Version-Release number of selected component (if applicable):
  rhel7 
  python-nova-2014.1.3-9.el7ost.noarch
  openstack-nova-compute-2014.1.3-9.el7ost.noarch
  openstack-nova-common-2014.1.3-9.el7ost.noarch
  python-novaclient-2.17.0-2.el7ost.noarch

  
  How reproducible:
  Every time

  Steps to Reproduce:
  1. Upload an image to glance, set --min-disk to say 20G
  2. Try to launch an instance from within horizon from that image, notice tiny 
flavor is grayed out. 
  3. From the booted instance above create a snapshot
  4. Edit that snapshot   #glance image-update snapID --min-disk 20
  5. From horizon boot an instance from the snapshot, notice you can select any 
flavor including tiny which should have been grayed out as in the case of image 
on step 2.

  
  Actual results:
  Tiny flavor isn't filtered from Horizon launch instance page.

  Expected results:
  As in the case of image if --min-disk is set any flavor with insufficient 
disk space should be grayed out.

  
  If this happens to --min-disk it might also happen with  --min-ram.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1401101/+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 1593537] Re: Unable to run a subset of tests using tox

2016-08-25 Thread Rob Cresswell
Fixed by https://review.openstack.org/#/c/322016/

** Changed in: horizon
   Status: In Progress => Invalid

** Changed in: horizon
Milestone: newton-3 => None

** Changed in: horizon
 Assignee: Richard Jones (r1chardj0n3s) => (unassigned)

-- 
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/1593537

Title:
  Unable to run a subset of tests using tox

Status in OpenStack Dashboard (Horizon):
  Invalid

Bug description:
  If I try to run a subset of tests using tox, such as:

  tox -v -e py27 -- openstack_dashboard.test.api_tests.network_tests

  I get an error from the manage.py command complaining about
  unrecognized arguments:

  usage: manage.py test [-h] [--version] [-v {0,1,2,3}] [--settings SETTINGS]
[--pythonpath PYTHONPATH] [--traceback] [--no-color]
[--noinput] [--failfast] [--testrunner TESTRUNNER]
[--liveserver LIVESERVER] [-t TOP_LEVEL]
[--pattern PATTERN] [-k] [-r] [--debug-sql] [-p] [-q]
[-c FILES] [-w WHERE] [--py3where PY3WHERE] [-m REGEX]
[--tests NAMES] [-l DEBUG] [--debug-log FILE]
[--logging-config FILE] [-I REGEX] [-e REGEX] [-i REGEX]
[-x] [-P] [--exe] [--noexe] [--traverse-namespace]
[--first-package-wins] [--no-byte-compile]
[--with-fixture-bundling] [--with-html-output]
[--html-out-file FILE] [--with-openstack]
[--openstack-red OPENSTACK_RED]
[--openstack-yellow OPENSTACK_YELLOW]
[--openstack-show-elapsed] [--openstack-color]
[--openstack-nocolor]
[--openstack-num-slow OPENSTACK_NUM_SLOW]
[--openstack-stdout] [--with-noseexclude]
[--exclude-dir EXCLUDE_DIRS]
[--exclude-dir-file EXCLUDE_DIR_FILE]
[--exclude-test EXCLUDE_TESTS]
[--exclude-test-file EXCLUDE_TEST_FILE]
[--with-xcoverage] [--xcoverage-file FILE]
[--xcoverage-to-stdout XCOVERAGE_TO_STDOUT] [-a ATTR]
[-A EXPR] [-s] [--nologcapture]
[--logging-format FORMAT] [--logging-datefmt FORMAT]
[--logging-filter FILTER] [--logging-clear-handlers]
[--logging-level LOGCAPTURE_LEVEL] [--with-coverage]
[--cover-package PACKAGE] [--cover-erase]
[--cover-tests]
[--cover-min-percentage COVER_MIN_PERCENTAGE]
[--cover-inclusive] [--cover-html]
[--cover-html-dir DIR] [--cover-branches] [--cover-xml]
[--cover-xml-file FILE] [--pdb] [--pdb-failures]
[--pdb-errors] [--no-deprecated] [--with-doctest]
[--doctest-tests] [--doctest-extension EXT]
[--doctest-result-variable VAR]
[--doctest-fixtures SUFFIX] [--doctest-options OPTIONS]
[--with-isolation] [-d] [--with-profile]
[--profile-sort SORT] [--profile-stats-file FILE]
[--profile-restrict RESTRICT] [--no-skip] [--with-id]
[--id-file FILE] [--failed] [--processes NUM]
[--process-timeout SECONDS] [--process-restartworker]
[--with-xunit] [--xunit-file FILE]
[--xunit-testsuite-name PACKAGE] [--all-modules]
[--collect-only]
[test_label [test_label ...]]
  manage.py test: error: unrecognized arguments: 
openstack_dashboard.test.api_tests.network_tests

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1593537/+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 1614361] Re: tox.ini needs to be updated as openstack infra now supports upper constraints

2016-08-25 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/358569
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=7126d0d50f7972a6802b0c97ad8f9af21b77e59e
Submitter: Jenkins
Branch:master

commit 7126d0d50f7972a6802b0c97ad8f9af21b77e59e
Author: AvnishPal 
Date:   Mon Aug 22 16:59:47 2016 +0530

Use upper constraints for all jobs in tox.ini

Openstack infra now supports upper constraints for
all jobs. Updated tox.ini to use upper constraints
for all jobs.

Change-Id: I0ee155178bf416f4cf955aa19c6273984fdd1f04
Closes-Bug: #1614361


** Changed in: horizon
   Status: In Progress => Fix Released

-- 
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/1614361

Title:
  tox.ini needs to be updated as openstack infra now supports upper
  constraints

Status in Cinder:
  In Progress
Status in Designate:
  Fix Released
Status in Glance:
  In Progress
Status in heat:
  In Progress
Status in OpenStack Dashboard (Horizon):
  Fix Released
Status in Ironic Inspector:
  Fix Released
Status in Mistral:
  Fix Released
Status in Murano:
  Fix Released
Status in networking-ovn:
  Invalid
Status in octavia:
  Fix Released
Status in python-muranoclient:
  Fix Released
Status in tacker:
  In Progress
Status in OpenStack DBaaS (Trove):
  Invalid
Status in vmware-nsx:
  In Progress
Status in zaqar:
  Fix Released
Status in Zaqar-ui:
  Fix Released

Bug description:
  Openstack infra now supports upper constraints for releasenotes, cover, venv 
targets.
  tox.ini uses install_command for these targets, which can now be safely 
removed.
  Reference for mail that details this support: 
http://lists.openstack.org/pipermail/openstack-dev/2016-August/101474.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1614361/+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 1576869] Re: Attach Interface form error

2016-08-25 Thread Rob Cresswell
Fixed in https://review.openstack.org/335709

** Changed in: horizon
   Status: In Progress => Invalid

** Changed in: horizon
Milestone: newton-3 => None

** Changed in: horizon
 Assignee: Ankur (ankur-gupta-f) => (unassigned)

-- 
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/1576869

Title:
  Attach Interface form error

Status in OpenStack Dashboard (Horizon):
  Invalid

Bug description:
  Horizon->Project->Instances

  When modal pops up, if you try submitting without selecting a network it 
errors (as it should).
  Modal stays open.
  When you go back and select a proper network to attach. Form errors out (it 
shouldn't)

  Error message:
  Danger: There was an error submitting the form. Please try again.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1576869/+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 1519720] Re: Enforced/Constrained Image Architecture Tagging

2016-08-25 Thread Rob Cresswell
Seems to have stalled, and should be a blueprinted feature regardless.
See comments on the attached patch too; metadata might solve this.

** Changed in: horizon
   Status: In Progress => Won't Fix

** Changed in: horizon
Milestone: newton-3 => None

** Changed in: horizon
 Assignee: Simon Murray (spjmurray) => (unassigned)

** Changed in: horizon
   Importance: Wishlist => Undecided

-- 
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/1519720

Title:
  Enforced/Constrained Image Architecture Tagging

Status in OpenStack Dashboard (Horizon):
  Won't Fix

Bug description:
  Some operators running heterogeneous clouds rely on images having the
  architecture attribute set in glance to allow nova to schedule
  instances on hypervisors of the correct architecture.  At present
  horizon presents this attribute as an optional text field, which is
  often ignored by end users who then end up with instances in the error
  state as an x86_64 image has been scheduled on an aarch64 hypervisor.

  It would be nice to allow this field in horizon to be required and
  constrained to a set of supported architectures presented as a drop
  down.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1519720/+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 1616815] [NEW] ovs_lib.OVSBridge.get_ports_attributes returns ports attributes even port not in current ovsbridge

2016-08-25 Thread hujin
Public bug reported:

Reproduce steps:
# cat neutron.conf
l3_ha=True

script:

from neutron.plugins.ml2.drivers.openvswitch.agent.openflow.ovs_ofctl
import br_int

int_br_name = 'br-int'
ex_br_name = 'br-flat'


def get_qg_device_from_br_ex():
ex_br = br_int.OVSIntegrationBridge(ex_br_name)
ex_vif_names = ex_br.get_port_name_list()
for i in ex_vif_names:
if i.startswith('qg'):
return i


def main():
int_br = br_int.OVSIntegrationBridge(int_br_name)
int_vif_names = int_br.get_port_name_list()
qg_dev_name = get_qg_device_from_br_ex()
if not qg_dev_name:
print 'qg device not found.'
return

print 'device name: ', qg_dev_name
print 'device belongs to br-int: ', qg_dev_name in int_vif_names
print 'get device attributes in br-int', int_br.get_ports_attributes(
"Port",
columns=["name", "tag", "other_config"],
ports=[qg_dev_name], if_exists=True)


if __name__ == '__main__':
main()


results:
[root@type-compute ~]# python test.py 
device name:  qg-08562579-d7
device belongs to br-int:  False
get device attributes in br-int [{u'tag': 23, u'name': u'qg-08562579-d7', 
u'other_config': {u'tag': u'23', u'physical_network': u'public-network', 
u'net_uuid': u'df19a06c-4fb1-401f-a551-1f8ce7f64b86', u'network_type': 
u'flat'}}]


This will cause the ports on the br-ex to be set with the tag attribute, and 
network unreachable

** Affects: neutron
 Importance: Undecided
 Assignee: hujin (hujin)
 Status: New

** Changed in: neutron
 Assignee: (unassigned) => hujin (hujin)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1616815

Title:
  ovs_lib.OVSBridge.get_ports_attributes returns ports attributes even
  port not in current ovsbridge

Status in neutron:
  New

Bug description:
  Reproduce steps:
  # cat neutron.conf
  l3_ha=True

  script:

  from neutron.plugins.ml2.drivers.openvswitch.agent.openflow.ovs_ofctl
  import br_int

  int_br_name = 'br-int'
  ex_br_name = 'br-flat'

  
  def get_qg_device_from_br_ex():
  ex_br = br_int.OVSIntegrationBridge(ex_br_name)
  ex_vif_names = ex_br.get_port_name_list()
  for i in ex_vif_names:
  if i.startswith('qg'):
  return i

  
  def main():
  int_br = br_int.OVSIntegrationBridge(int_br_name)
  int_vif_names = int_br.get_port_name_list()
  qg_dev_name = get_qg_device_from_br_ex()
  if not qg_dev_name:
  print 'qg device not found.'
  return

  print 'device name: ', qg_dev_name
  print 'device belongs to br-int: ', qg_dev_name in int_vif_names
  print 'get device attributes in br-int', int_br.get_ports_attributes(
  "Port",
  columns=["name", "tag", "other_config"],
  ports=[qg_dev_name], if_exists=True)

  
  if __name__ == '__main__':
  main()

  
  results:
  [root@type-compute ~]# python test.py 
  device name:  qg-08562579-d7
  device belongs to br-int:  False
  get device attributes in br-int [{u'tag': 23, u'name': u'qg-08562579-d7', 
u'other_config': {u'tag': u'23', u'physical_network': u'public-network', 
u'net_uuid': u'df19a06c-4fb1-401f-a551-1f8ce7f64b86', u'network_type': 
u'flat'}}]

  
  This will cause the ports on the br-ex to be set with the tag attribute, and 
network unreachable

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1616815/+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 1616290] Re: [api-ref]: Outdated link reference

2016-08-25 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/359631
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=6ecc42692b9d4192844f31ebda5da86e5dca596c
Submitter: Jenkins
Branch:master

commit 6ecc42692b9d4192844f31ebda5da86e5dca596c
Author: Ha Van Tu 
Date:   Wed Aug 24 15:02:02 2016 +0700

[api-ref]: Outdated link reference

There are some outdated link reference in Keystone API version 3 such as:

http://developer.openstack.org/api-ref-identity-v3.html#getRoleInference

http://developer.openstack.org/api-ref-identity-v3.html#assignRoleToUser-domain
http://developer.openstack.org/api-ref-identity-v3.html#createRoleInference
http://developer.openstack.org/api-ref-identity-v3.html#createRoleInference

We should update these links

Change-Id: I18c65e2efe87f094bd8ba9afa7baa13c085f9b14
Closes-Bug: #1616290


** Changed in: keystone
   Status: In Progress => Fix Released

-- 
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/1616290

Title:
  [api-ref]: Outdated link reference

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  There are some outdated link reference in Keystone API version 3 such
  as:

  http://developer.openstack.org/api-ref-identity-v3.html#getRoleInference
  
http://developer.openstack.org/api-ref-identity-v3.html#assignRoleToUser-domain
  http://developer.openstack.org/api-ref-identity-v3.html#createRoleInference
  http://developer.openstack.org/api-ref-identity-v3.html#createRoleInference

  We should update these links

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1616290/+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 1616793] [NEW] neutron availability-zone-list got a db error using postgresql

2016-08-25 Thread brenda
Public bug reported:

when use cli command "neutron availability-zone-list" with postgresql db
backend,I got a server error,like below:

2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource Traceback (most 
recent call last):
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/neutron/api/v2/resource.py", line 84, in 
resource
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource result = 
method(request=request, **args)
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/oslo_db/api.py", line 148, in wrapper
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource ectxt.value = 
e.inner_exc
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource 
self.force_reraise()
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource 
six.reraise(self.type_, self.value, self.tb)
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/oslo_db/api.py", line 138, in wrapper
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource return f(*args, 
**kwargs)
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/neutron/api/v2/base.py", line 341, in index
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource return 
self._items(request, True, parent_id)
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/neutron/api/v2/base.py", line 267, in _items
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource obj_list = 
obj_getter(request.context, **kwargs)
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/neutron/db/agents_db.py", line 155, in 
get_availability_zones
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource context, 
filters))]
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/neutron/db/agents_db.py", line 132, in 
_list_availability_zones
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource 
Agent.agent_type):
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/query.py", line 2736, in 
__iter__
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource return 
self._execute_and_instances(context)
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/orm/query.py", line 2751, in 
_execute_and_instances
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource result = 
conn.execute(querycontext.statement, self._params)
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 914, in 
execute
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource return 
meth(self, multiparams, params)
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/sql/elements.py", line 323, in 
_execute_on_connection
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource return 
connection._execute_clauseelement(self, multiparams, params)
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1010, in 
_execute_clauseelement
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource compiled_sql, 
distilled_params
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1146, in 
_execute_context
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource context)
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1337, in 
_handle_dbapi_exception
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource 
util.raise_from_cause(newraise, exc_info)
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/util/compat.py", line 200, in 
raise_from_cause
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource 
reraise(type(exception), exception, tb=exc_tb)
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource   File 
"/usr/lib64/python2.7/site-packages/sqlalchemy/engine/base.py", line 1139, in 
_execute_context
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource context)
2016-08-25 13:41:17.808 29748 ERROR neutron.api.v2.resource   File 

[Yahoo-eng-team] [Bug 1614063] Re: live migration doesn't use the correct interface to transfer the data

2016-08-25 Thread Pawel Koniszewski
Confirmed that it is a bug. Libvirt correctly uses
live_migration_inbound_addr, but QEMU still defaults to the hostname of
the other side instead of provided IP address.

** Changed in: nova
   Status: Invalid => Confirmed

** Changed in: nova
   Importance: Undecided => Medium

** Tags added: live-migration

-- 
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/1614063

Title:
  live migration doesn't use the correct interface to transfer the data

Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  My compute nodes are attached to several networks (storage, admin,
  etc). For each network I have a real or a virtual interface with an IP
  assigned. The DNS is properly configured, so I can `ping node1`, or
  `ping storage.node1`, and is resolving to the correct IP.

  I want to use the second network to transfer the data so:

  * Setup libvirtd to listen into the correct interface (checked with
  netstat)

  * Configure nova.conf live_migration_uri

  * Monitor interfaces and do nova live-migration

  The migration works correctly, is doing what I think is a PEER2PEER
  migration type, but the data is transfered via the normal interface.

  I can replicate it doing a live migration via virsh.

  After more checks I discover that if I do not use the --migrate-uri
  parameter, libvirt will ask to the other node the hostname to build
  this migrage_uri parameter. The hostname resolve via the slow
  interface.

  Using the --migrate-uri and the --listen-address (for the -incoming
  parameter) works at libvirt level. So we need somehow inject this
  paramer in migrateToURIx in the libvirt nova driver.

  I have a patch (attached - WIP) that address this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1614063/+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 1616782] [NEW] driver_discard='unmap' is written without considering the configuration

2016-08-25 Thread Ji.Wei
Public bug reported:

The original code is as follows:

if data.get('discard', False) is True:
min_qemu = nova.virt.libvirt.driver.MIN_QEMU_DISCARD_VERSION
if self.connection._host.has_min_version(
hv_ver=min_qemu,
hv_type=host.HV_DRIVER_QEMU):
conf.driver_discard = 'unmap'
else:
global SHOULD_LOG_DISCARD_WARNING
if SHOULD_LOG_DISCARD_WARNING:
SHOULD_LOG_DISCARD_WARNING = False
LOG.warning(_LW('Unable to attach %(type)s volume '
'%(serial)s with discard enabled: qemu '
'%(qemu)s or later is required.'),
{
'qemu': min_qemu,
'serial': conf.serial,
'type': connection_info['driver_volume_type']
})

https://github.com/openstack/nova/blob/master/nova/virt/libvirt/volume/volume.py#L96

No consideration is given to the case when the configuration file is not
configured as hw_disk_discard=unmap

Only when the backend report can support discard, is to write the unmap
in XML

** Affects: nova
 Importance: Undecided
 Assignee: Ji.Wei (jiwei)
 Status: New


** Tags: discard

** Tags added: discard

** Changed in: nova
 Assignee: (unassigned) => Ji.Wei (jiwei)

-- 
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/1616782

Title:
  driver_discard='unmap' is written without considering the
  configuration

Status in OpenStack Compute (nova):
  New

Bug description:
  The original code is as follows:

  if data.get('discard', False) is True:
  min_qemu = nova.virt.libvirt.driver.MIN_QEMU_DISCARD_VERSION
  if self.connection._host.has_min_version(
  hv_ver=min_qemu,
  hv_type=host.HV_DRIVER_QEMU):
  conf.driver_discard = 'unmap'
  else:
  global SHOULD_LOG_DISCARD_WARNING
  if SHOULD_LOG_DISCARD_WARNING:
  SHOULD_LOG_DISCARD_WARNING = False
  LOG.warning(_LW('Unable to attach %(type)s volume '
  '%(serial)s with discard enabled: qemu '
  '%(qemu)s or later is required.'),
  {
  'qemu': min_qemu,
  'serial': conf.serial,
  'type': connection_info['driver_volume_type']
  })

  
https://github.com/openstack/nova/blob/master/nova/virt/libvirt/volume/volume.py#L96

  No consideration is given to the case when the configuration file is
  not configured as hw_disk_discard=unmap

  Only when the backend report can support discard, is to write the
  unmap in XML

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1616782/+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 1616769] [NEW] When assigning neutron-port to PF sriov_numvfs parameter get "0" value

2016-08-25 Thread Eran Kuris
Public bug reported:

escription of problem:
When manage SR-IOV PFs as Neutron ports I can see that 
/sys/class/net/enp5s0f1/device/sriov_numvfs parameter gets "0" value . 
when I delete the PF port  so I can switch to SRIOV - direct port (VF) I cant 
boot vm because sriov_numvfs parameter equal to "0" value
Version-Release number of selected component (if applicable):
 rpm -qa |grep neutron
python-neutron-lib-0.3.0-0.20160803002107.405f896.el7ost.noarch
openstack-neutron-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
puppet-neutron-9.1.0-0.20160813031056.7cf5e07.el7ost.noarch
python-neutron-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
openstack-neutron-lbaas-9.0.0-0.20160816191643.4e7301e.el7ost.noarch
python-neutron-fwaas-9.0.0-0.20160817171450.e1ac68f.el7ost.noarch
python-neutron-lbaas-9.0.0-0.20160816191643.4e7301e.el7ost.noarch
openstack-neutron-ml2-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
openstack-neutron-metering-agent-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
openstack-neutron-openvswitch-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
python-neutronclient-5.0.0-0.20160812094704.ec20f7f.el7ost.noarch
openstack-neutron-common-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
openstack-neutron-fwaas-9.0.0-0.20160817171450.e1ac68f.el7ost.noarch
[root@controller1 ~(keystone_admin)]# rpm -qa |grep nova
python-novaclient-5.0.1-0.20160724130722.6b11a1c.el7ost.noarch
openstack-nova-api-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
puppet-nova-9.1.0-0.20160813014843.b94f0a0.el7ost.noarch
openstack-nova-common-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
openstack-nova-novncproxy-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
openstack-nova-conductor-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
python-nova-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
openstack-nova-scheduler-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
openstack-nova-cert-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
openstack-nova-console-14.0.0-0.20160817225441.04cef3b.el7ost.noarch


How reproducible:
always 

Steps to Reproduce:
1.Set SRIOV ENV and PF support : 
https://docs.google.com/document/d/1qQbJlLI1hSlE4uwKpmVd0BoGSDBd8Z0lTzx5itQ6WL0/edit#
2. BOOT VM that assign to PF (neutron port- direct-physical) -  should boot well
3. check cat /sys/class/net/enp5s0f1/device/sriov_numvfs  (=0)
4. delete vm  and check again sriov_numvfs   (=0)
5. I expect that numvfs should return to the default value that was configured

** Affects: nova
 Importance: Undecided
 Status: New

-- 
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/1616769

Title:
  When assigning neutron-port to PF sriov_numvfs parameter get "0" value

Status in OpenStack Compute (nova):
  New

Bug description:
  escription of problem:
  When manage SR-IOV PFs as Neutron ports I can see that 
  /sys/class/net/enp5s0f1/device/sriov_numvfs parameter gets "0" value . 
  when I delete the PF port  so I can switch to SRIOV - direct port (VF) I cant 
boot vm because sriov_numvfs parameter equal to "0" value
  Version-Release number of selected component (if applicable):
   rpm -qa |grep neutron
  python-neutron-lib-0.3.0-0.20160803002107.405f896.el7ost.noarch
  openstack-neutron-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
  puppet-neutron-9.1.0-0.20160813031056.7cf5e07.el7ost.noarch
  python-neutron-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
  openstack-neutron-lbaas-9.0.0-0.20160816191643.4e7301e.el7ost.noarch
  python-neutron-fwaas-9.0.0-0.20160817171450.e1ac68f.el7ost.noarch
  python-neutron-lbaas-9.0.0-0.20160816191643.4e7301e.el7ost.noarch
  openstack-neutron-ml2-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
  openstack-neutron-metering-agent-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
  openstack-neutron-openvswitch-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
  python-neutronclient-5.0.0-0.20160812094704.ec20f7f.el7ost.noarch
  openstack-neutron-common-9.0.0-0.20160817153328.b9169e3.el7ost.noarch
  openstack-neutron-fwaas-9.0.0-0.20160817171450.e1ac68f.el7ost.noarch
  [root@controller1 ~(keystone_admin)]# rpm -qa |grep nova
  python-novaclient-5.0.1-0.20160724130722.6b11a1c.el7ost.noarch
  openstack-nova-api-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
  puppet-nova-9.1.0-0.20160813014843.b94f0a0.el7ost.noarch
  openstack-nova-common-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
  openstack-nova-novncproxy-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
  openstack-nova-conductor-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
  python-nova-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
  openstack-nova-scheduler-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
  openstack-nova-cert-14.0.0-0.20160817225441.04cef3b.el7ost.noarch
  openstack-nova-console-14.0.0-0.20160817225441.04cef3b.el7ost.noarch

  
  How reproducible:
  always 

  Steps to Reproduce:
  1.Set SRIOV ENV and PF support : 

[Yahoo-eng-team] [Bug 1616762] [NEW] Obsolete release notes of network_api_class and volume_api_class

2016-08-25 Thread Yibo Cai
Public bug reported:

network_api_class and volume_api_class options are removed in latest
code. But release notes "nova/notes/rm_volume_manager-
78fed5be43d285b3.yaml" says they're still valid, it should be updated.

https://review.openstack.org/gitweb?p=openstack/nova.git;a=blob;f=releasenotes/notes
/rm_volume_manager-
78fed5be43d285b3.yaml;h=dcc73e3716ccd9aecbdf33bd6afe0175ed21beac;hb=HEAD

** Affects: nova
 Importance: Undecided
 Status: New

-- 
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/1616762

Title:
  Obsolete release notes of network_api_class  and volume_api_class

Status in OpenStack Compute (nova):
  New

Bug description:
  network_api_class and volume_api_class options are removed in latest
  code. But release notes "nova/notes/rm_volume_manager-
  78fed5be43d285b3.yaml" says they're still valid, it should be updated.

  
https://review.openstack.org/gitweb?p=openstack/nova.git;a=blob;f=releasenotes/notes
  /rm_volume_manager-
  78fed5be43d285b3.yaml;h=dcc73e3716ccd9aecbdf33bd6afe0175ed21beac;hb=HEAD

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1616762/+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 1544768] Re: [RFE] Differentiate between service and regular subnets

2016-08-25 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/350613
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=de3a3cda740dfa22152c8224c39aeb9e51642d93
Submitter: Jenkins
Branch:master

commit de3a3cda740dfa22152c8224c39aeb9e51642d93
Author: John Davidge 
Date:   Mon Aug 1 14:04:08 2016 +0100

IP allocation with Service Subnets

This changes the way that IPAM decides which subnets to use when
assigning IPs to newly created ports. If the port has a defined
device_owner, this is used to filter available subnets to choose
from only those with a matching service_type or no service_type
at all.

If the given network has no service subnets, then the existing
behaviour is used.

A new IPAM exception is introduced to handle the following scenarios:
1. A port is created with a device_owner and only non-matching service
   subnets exist.
2. A port is created without a device owner, and no subnets exist
   without a service_type.

With this patch, service subnets are now usable.

Implements: blueprint service-subnets
APIImpact: subnet-create and subnet-update with service_types
DocImpact: IPs assigned to new ports will now come from a service subnet
matching the port device_owner, if one exists.

Closes-Bug: 1544768
Change-Id: If3dd94a46bdee24c13d1f17c4f2e69af0cb8af63


** Changed in: neutron
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1544768

Title:
  [RFE] Differentiate between service and regular subnets

Status in neutron:
  Fix Released

Bug description:
  I've been thinking about this for a little while now.  There seems to
  be something different about floating IP subnets and other (I'll call
  them "service" in this context) subnets in some use cases.

  - On an external network where operators wish to use private IPs for router 
ports (and DVR FIP ports)  and public for floating IPs.
  - Enable using floating IPs on provider networks without routers [1].  This 
has come up a lot.  In many cases, operators want them to be public while the 
static ones are private.
  - On routed networks where VM instance and router ports need IPs from their 
segments but floating IPs can be routed more flexibly.

  I don't think we need to implement all of these use cases with this
  RFE.  I think this RFE should just solve the first one about router
  ports.  However, all of them seem to all need some way to distinguish
  different subnets on the same network for different purposes.

  Let's add a service type field to the subnet.  To start with, we’ll
  have two possible values other than the current default of null:
  "dvr_gateway", and "dvr_and_router_ports".  The names aren’t written
  in stone.  The choice between the two depends on if you want your
  routers to get public addresses for SNAT.  IPAM will consider the
  service type when allocating a port for a particular device_owner.
  Each device_owner will have a (possibly empty) list of service types
  to prefer.

  Any kind of port can get an address from a subnet without a specified
  service type.  This fallback ensures that legacy behavior is always
  preserved and there are no surprises when you upgrade.

  [1] http://lists.openstack.org/pipermail/openstack-
  operators/2016-February/009551.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1544768/+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 1616745] [NEW] IP allocation with Service Subnets

2016-08-25 Thread OpenStack Infra
Public bug reported:

https://review.openstack.org/350613
Dear bug triager. This bug was created since a commit was marked with DOCIMPACT.
Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

commit de3a3cda740dfa22152c8224c39aeb9e51642d93
Author: John Davidge 
Date:   Mon Aug 1 14:04:08 2016 +0100

IP allocation with Service Subnets

This changes the way that IPAM decides which subnets to use when
assigning IPs to newly created ports. If the port has a defined
device_owner, this is used to filter available subnets to choose
from only those with a matching service_type or no service_type
at all.

If the given network has no service subnets, then the existing
behaviour is used.

A new IPAM exception is introduced to handle the following scenarios:
1. A port is created with a device_owner and only non-matching service
   subnets exist.
2. A port is created without a device owner, and no subnets exist
   without a service_type.

With this patch, service subnets are now usable.

Implements: blueprint service-subnets
APIImpact: subnet-create and subnet-update with service_types
DocImpact: IPs assigned to new ports will now come from a service subnet
matching the port device_owner, if one exists.

Closes-Bug: 1544768
Change-Id: If3dd94a46bdee24c13d1f17c4f2e69af0cb8af63

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: doc 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/1616745

Title:
  IP allocation with Service Subnets

Status in neutron:
  New

Bug description:
  https://review.openstack.org/350613
  Dear bug triager. This bug was created since a commit was marked with 
DOCIMPACT.
  Your project "openstack/neutron" is set up so that we directly report the 
documentation bugs against it. If this needs changing, the docimpact-group 
option needs to be added for the project. You can ask the OpenStack infra team 
(#openstack-infra on freenode) for help if you need to.

  commit de3a3cda740dfa22152c8224c39aeb9e51642d93
  Author: John Davidge 
  Date:   Mon Aug 1 14:04:08 2016 +0100

  IP allocation with Service Subnets
  
  This changes the way that IPAM decides which subnets to use when
  assigning IPs to newly created ports. If the port has a defined
  device_owner, this is used to filter available subnets to choose
  from only those with a matching service_type or no service_type
  at all.
  
  If the given network has no service subnets, then the existing
  behaviour is used.
  
  A new IPAM exception is introduced to handle the following scenarios:
  1. A port is created with a device_owner and only non-matching service
 subnets exist.
  2. A port is created without a device owner, and no subnets exist
 without a service_type.
  
  With this patch, service subnets are now usable.
  
  Implements: blueprint service-subnets
  APIImpact: subnet-create and subnet-update with service_types
  DocImpact: IPs assigned to new ports will now come from a service subnet
  matching the port device_owner, if one exists.
  
  Closes-Bug: 1544768
  Change-Id: If3dd94a46bdee24c13d1f17c4f2e69af0cb8af63

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1616745/+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 1582045] Re: Nova doesn't support v3 when connecting to Ironic

2016-08-25 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/300154
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=2ea2399ec3e4b976beadfbcd1cab78b94382eca3
Submitter: Jenkins
Branch:master

commit 2ea2399ec3e4b976beadfbcd1cab78b94382eca3
Author: Clenimar Filemon 
Date:   Thu Mar 31 14:46:43 2016 -0300

Support Identity v3 when connecting to Ironic

This patch makes Nova:
a) support Identity v3 params when creating an Ironiccient by
creating a v3Password auth plugin and a Session;
b) deprecate auth parameters admin_tenant_name, admin_username
admin_password and admin_url;
c) remove support to admin_auth_token auth parameter [1].

[1] admin_auth_token was deprecated
(317d9d8f13e8a34af189504ae1258d315154cc82) in favour of admin_username and
admin_password (which are deprecated now in favour of username and
password). More info at Keystone release notes (see Deprecation Notes
and Security Issues):

http://docs.openstack.org/releasenotes/keystone/mitaka.html#deprecation-notes

Change-Id: Id837d26bb21c158de0504627e488c0692aef1e24
Closes-Bug: #1582045


** Changed in: nova
   Status: In Progress => Fix Released

-- 
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/1582045

Title:
  Nova doesn't support v3 when connecting to Ironic

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  nova-ironic communication only supports v2, deprecated auth
  parameters, e.g [1]. this will cause a fatal error during a v3-only
  devstack setup, as ironic keeps waiting for nova to provide resources
  and a timeout occurs (logs will show a lot of 404s) failing the setup.

  currently an ironic-enabled, v3-only devstack setup will fail because
  ironic itself doesn't support v3, but we already have a filed bug [2]
  and a patch on the way [3].

  to reproduce this issue: setup a v3-only devstack with patched [3]
  ironic enabled. it should fail waiting for nova-hypervisor to provide
  VMs.

  [1] 
https://github.com/openstack/nova/blob/master/nova/virt/ironic/client_wrapper.py#L72-L78
  [2] https://bugs.launchpad.net/ironic/+bug/1494776
  [3] https://review.openstack.org/#/c/236982/

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1582045/+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