[Yahoo-eng-team] [Bug 1617164] [NEW] format error in agent/l3/ha_router.HaRouter._add_default_gw_virtual_route
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
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 HayesDate: 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
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 shengDate: 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
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 ShanmugamDate: 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
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?
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?
[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
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.
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 UnnamDate: 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
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 AnDate: 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.
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 MathewsDate: 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
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
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 FinucaneDate: 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
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]
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
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 AjoDate: 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
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
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
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 OvchinnikovaDate: 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
Reviewed: https://review.openstack.org/359184 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=d390f1c8500b9bbd8852e1b77a93fe35fd6e5fa7 Submitter: Jenkins Branch:master commit d390f1c8500b9bbd8852e1b77a93fe35fd6e5fa7 Author: venkatamaheshDate: 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.
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
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
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
** 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
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
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ómezDate: 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
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 FedorukDate: 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
** 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 DavidgeDate: 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
** 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
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.zhuyjDate: 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
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.
** 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
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
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
** 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
** 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 DavidgeDate: 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
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
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
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: AvnishPalDate: 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.
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
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
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 BechtoldDate: 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
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
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
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
Reviewed: https://review.openstack.org/358569 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=7126d0d50f7972a6802b0c97ad8f9af21b77e59e Submitter: Jenkins Branch:master commit 7126d0d50f7972a6802b0c97ad8f9af21b77e59e Author: AvnishPalDate: 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
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
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
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
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 TuDate: 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
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
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
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
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
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
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 DavidgeDate: 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
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 DavidgeDate: 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
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 FilemonDate: 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