[Yahoo-eng-team] [Bug 1082248] Re: Use uuidutils instead of uuid.uuid4()
** Also affects: networking-calico Importance: Undecided Status: New ** Changed in: networking-calico Assignee: (unassigned) => Yan Songming (songmingyan) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1082248 Title: Use uuidutils instead of uuid.uuid4() Status in Cinder: In Progress Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: Fix Released Status in kuryr: In Progress Status in kuryr-libnetwork: In Progress Status in Magnum: New Status in Mistral: Fix Released Status in Murano: In Progress Status in networking-calico: New Status in networking-ovn: Fix Released Status in networking-sfc: In Progress Status in neutron: Fix Released Status in OpenStack Compute (nova): In Progress Status in Sahara: Fix Released Status in senlin: Fix Released Status in tacker: In Progress Bug description: Openstack common has a wrapper for generating uuids. We should only use that function when generating uuids for consistency. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1082248/+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 1641879] [NEW] No routers created after l3-agent start - error during L3NATAgentWithStateReport.periodic_sync_routers_task
Public bug reported: After (re)starting the L3 agent, a failure during L3NATAgentWithStateReport.periodic_sync_routers_task was encountered. This resulted in a Python traceback being dumped to the log ending with "TypeError: 'NoneType' object is not iterable". The error repeats every minute or so. (See below.) While the error persists, no routers are provisioned by the L3 agent. It just keeps failing and failing and failing in an seemingly infinite loop. The fix/workaround was to remove a random router from the L3 agent having problems, like so: $ neutron l3-agent-router-remove It did not seem to matter exactly which of the many routers scheduled to run on the problematic L3 agent that was removed in this way. The removal itself seemed to get rid of the blockage, allowing the L3 agent to start normal operations shortly after. Excerpts from l3-agent.log: 2016-11-15 03:14:26.201 2988 INFO neutron.common.config [-] Logging enabled! 2016-11-15 03:14:26.201 2988 INFO neutron.common.config [-] /usr/bin/neutron-l3-agent version 8.3.0 2016-11-15 03:14:26.504 2988 INFO eventlet.wsgi.server [-] (2988) wsgi starting up on http:/var/lib/neutron/keepalived-state-change 2016-11-15 03:14:26.548 2988 INFO neutron.agent.l3.agent [-] Agent has just been revived. Doing a full sync. 2016-11-15 03:14:26.781 2988 INFO neutron.agent.l3.agent [-] L3 agent started 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task [req-97b76ec8-9eb6-4e23-8074-63c889c3e199 - - - - -] Error during L3NATAgentWithStateReport.periodic_sync_routers_task 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task Traceback (most recent call last): 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task File "/usr/lib/python2.7/site-packages/oslo_service/periodic_task.py", line 220, in run_periodic_tasks 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task task(self, context) 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task File "/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py", line 545, in periodic_sync_routers_task 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task self.fetch_and_sync_all_routers(context, ns_manager) 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task File "/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py", line 556, in fetch_and_sync_all_routers 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task self.plugin_rpc.get_router_ids(context)) 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task File "/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py", line 108, in get_router_ids 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task return cctxt.call(context, 'get_router_ids', host=self.host) 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task File "/usr/lib/python2.7/site-packages/neutron/common/rpc.py", line 136, in call 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task return self._original_context.call(ctxt, method, **kwargs) 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/client.py", line 158, in call 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task retry=self.retry) 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task File "/usr/lib/python2.7/site-packages/oslo_messaging/transport.py", line 90, in _send 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task timeout=timeout, retry=retry) 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 470, in send 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task retry=retry) 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task File "/usr/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py", line 461, in _send 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task raise result 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task TypeError: 'NoneType' object is not iterable 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task Traceback (most recent call last): 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 138, in _dispatch_and_reply 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task incoming.message)) 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 185, in _dispatch 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task return self._do_dispatch(endpoint, method, ctxt, args) 2016-11-15 03:14:28.297 2988 ERROR oslo_service.periodic_task 2016-11-15 03:14:28.297 2988 ERROR oslo_
[Yahoo-eng-team] [Bug 1629159] Re: delete router with error of failed unplugging ha interface
Reviewed: https://review.openstack.org/379908 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=bc03048134f12df47e1e619d21ba394db9c52dc1 Submitter: Jenkins Branch:master commit bc03048134f12df47e1e619d21ba394db9c52dc1 Author: Perry Zou Date: Fri Sep 30 02:42:56 2016 + Fix "failed unplugging ha interface" error when deleting router Deleting router namespaces happens before deleting router ha interface. So it will fail when deleting router ha interface. The change is to remove router ha interface before deleting router namespace. Change-Id: I3d936701c9dac7671f12e1966449662988a0f26a Closes-Bug: #1629159 Related-Bug: #1488730 ** 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/1629159 Title: delete router with error of failed unplugging ha interface Status in neutron: Fix Released Bug description: When deleting a Router, there are ERROR logs of failed unplugging ha interface. This happens in environment with stable/mitaka. What needs to note is that router could be deleted successfully after the ERROR. Reproduce steps: neutron router-create test neutron router-delete test monitor log in neutron-l3-agent.log This problem is different from existing defects. some existing defect addressed problem of looping deleting router. some addressed problem of race between router sync and router deleting. And some defect has similar symptom which happened on different place, such as bug 1606801. 2016-09-29 06:57:11.744 6287 DEBUG neutron.agent.linux.utils [-] Running command: ['sudo', '/usr/local/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'delete', 'qrouter-74c4a209-2f42-4f45-b409-082939df0962'] create_process /opt/bbc/openstack-2016.1-bbc234/neutron/local/lib/python2.7/site-packages/neutron/agent/linux/utils.py:84 2016-09-29 06:57:11.835 6287 DEBUG neutron.agent.linux.utils [-] Exit code: 0 execute /opt/bbc/openstack-2016.1-bbc234/neutron/local/lib/python2.7/site-packages/neutron/agent/linux/utils.py:142 2016-09-29 06:57:11.836 6287 DEBUG neutron.agent.linux.utils [-] Running command: ['sudo', '/usr/local/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'kill', '-9', '10728'] create_process /opt/bbc/openstack-2016.1-bbc234/neutron/local/lib/python2.7/site-packages/neutron/agent/linux/utils.py:84 2016-09-29 06:57:11.897 6287 DEBUG neutron.agent.linux.utils [-] Exit code: 0 execute /opt/bbc/openstack-2016.1-bbc234/neutron/local/lib/python2.7/site-packages/neutron/agent/linux/utils.py:142 2016-09-29 06:57:11.898 6287 DEBUG neutron.agent.linux.utils [-] Running command: ['sudo', '/usr/local/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec', 'qrouter-74c4a209-2f42-4f45-b409-082939df0962', 'ip', 'link', 'delete', 'ha-e210e603-0c'] create_process /opt/bbc/openstack-2016.1-bbc234/neutron/local/lib/python2.7/site-packages/neutron/agent/linux/utils.py:84 2016-09-29 06:57:11.961 6287 ERROR neutron.agent.linux.utils [-] Exit code: 1; Stdin: ; Stdout: ; Stderr: Cannot open network namespace "qrouter-74c4a209-2f42-4f45-b409-082939df0962": No such file or directory 2016-09-29 06:57:11.962 6287 ERROR neutron.agent.linux.interface [-] Failed unplugging interface 'ha-e210e603-0c' 2016-09-29 06:57:11.962 6287 DEBUG neutron.agent.linux.utils [-] Running command: ['sudo', '/usr/local/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'kill', '-15', '10910'] create_process /opt/bbc/openstack-2016.1-bbc234/neutron/local/lib/python2.7/site-packages/neutron/agent/linux/utils.py:84 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1629159/+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 1562878] Re: L3 HA: Unable to complete operation on subnet
Reviewed: https://review.openstack.org/394354
Committed:
https://git.openstack.org/cgit/openstack/rally/commit/?id=41010685c40ce765777200018faff184e515602b
Submitter: Jenkins
Branch:master
commit 41010685c40ce765777200018faff184e515602b
Author: John Schwarz
Date: Mon Nov 7 12:36:51 2016 +0200
Add missing device_owner for L3 HA's case
Patch Ieab53624dc34dc687a0e8eebd8477 added a new possible value for the
device_owner field of a port, that signifies a router's interface for a
subnet. The rally code was not changed accordingly, which causes rally
to try to delete the port using the wrong API ('neutron port-delete'
instead of 'neutron router-interface-delete'), causing cleanup errors
and leftover resources.
Closes-Bug: #1562878
Change-Id: I65933650d613e1800541dfdb33714a50f5c13db7
** Changed in: rally
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/1562878
Title:
L3 HA: Unable to complete operation on subnet
Status in neutron:
Invalid
Status in Rally:
Fix Released
Bug description:
Environment 3 controllers, 46 computes, liberty. L3 HA During execution
NeutronNetworks.create_and_delete_routers several times test failed with
"Unable to complete operation on subnet . One or more ports have an IP
allocation from this subnet. " trace in neutron-server logs
http://paste.openstack.org/show/491557/
Rally report attached.
Current problem is with HA subnet. The side effect of this problem is
bug https://bugs.launchpad.net/neutron/+bug/1562892
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1562878/+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 1641939] [NEW] class neutronclient.common.exceptions.Unauthorized
Public bug reported: Got this when trying to create an instance on a freshly installed OpenStack (Newton) based on the installation guide: http://docs.openstack.org/newton/install-guide-ubuntu/index.html. Using Xenial Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-6708a3cf-b88c-453e-88fa-9da1b5b1777a) Steps to reproduce: Create an instance via Horizon ** Affects: nova Importance: Undecided Status: New ** Attachment added: "nova-api.log" https://bugs.launchpad.net/bugs/1641939/+attachment/4777690/+files/nova-api.log -- 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/1641939 Title: class neutronclient.common.exceptions.Unauthorized Status in OpenStack Compute (nova): New Bug description: Got this when trying to create an instance on a freshly installed OpenStack (Newton) based on the installation guide: http://docs.openstack.org/newton/install-guide-ubuntu/index.html. Using Xenial Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-6708a3cf-b88c-453e-88fa-9da1b5b1777a) Steps to reproduce: Create an instance via Horizon To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1641939/+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 1637484] Re: Update user is working not properly
*** This bug is a duplicate of bug 1637530 *** https://bugs.launchpad.net/bugs/1637530 ** This bug has been marked a duplicate of bug 1637530 Python keystone client `users` method get() is not working -- 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/1637484 Title: Update user is working not properly Status in OpenStack Identity (keystone): Confirmed Bug description: Using python keystone-client to update user is working not properly. Keystone client returns new updated object. Old user was not updated. Steps to reproduce: 1. authenticate 2. create test_user: name='test_user_005' password='test' email='t...@test.com' 3. update test_user email='upda...@updated.com' Expected result: Keystone client returns new object test_user was not updated Actual result: test_user was updated Attachments: Execute script in attachment to investigate the issue Trace: === CREATE TEST USER === === UPDATE TEST USER === === TEST USER: http://192.168.0.2:35357/v3/users/89d34a7ce6c842209823d674c5d0c3b2'}, name=test_user_005> === TEST USER GET: http://192.168.0.2:35357/v3/users/89d34a7ce6c842209823d674c5d0c3b2'}, name=test_user_005>> === UPDATED TEST USER: http://192.168.0.2:35357/v3/users/89d34a7ce6c842209823d674c5d0c3b2'}, name=test_user_005> === UPDATED TEST USER GET: http://192.168.0.2:35357/v3/users/89d34a7ce6c842209823d674c5d0c3b2'}, name=test_user_005>> To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1637484/+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 1639685] Re: glance image-create creates an image with no name
This is counterintuitive, but it's by design. What's the point of a
"blank" image? It reserves a UUID for you. In any case, changing this
would be a breaking change in the API, so we can't change it there, and
we try to keep the python-glanceclient close to the API, so we won't fix
it there, either.
Thanks for taking the time to report this, though.
** Changed in: glance
Status: New => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1639685
Title:
glance image-create creates an image with no name
Status in Glance:
Won't Fix
Bug description:
I'd expected glance image-create command to return the usage syntax,
instead it did this.
[rvalavan@AlfredWallace ~]$ glance image-create
+--+--+
| Property | Value|
+--+--+
| checksum | None |
| container_format | None |
| created_at | 2016-11-07T04:07:50Z |
| disk_format | None |
| id | 5173c08b-97e5-4e73-8479-3c0a3263bc74 |
| min_disk | 0|
| min_ram | 0|
| name | None |
| owner| 7315fbd1e2d84b6fa107c02c604c70b5 |
| protected| False|
| size | None |
| status | queued |
| tags | [] |
| updated_at | 2016-11-07T04:07:50Z |
| virtual_size | None |
| visibility | private |
+--+--+
[rvalavan@AlfredWallace ~]$ glance image-list
+--+--+
| ID | Name |
+--+--+
| 5173c08b-97e5-4e73-8479-3c0a3263bc74 | |
+--+--+
[rvalavan@AlfredWallace ~]$ glance --version
2.5.0
[rvalavan@AlfredWallace ~]$ nova --version
6.0.0
After deleting the image, recreated with debug option:
[rvalavan@AlfredWallace ~]$ glance --debug image-create
DEBUG:keystoneclient.session:REQ: curl -g -i -X GET
http://192.168.154.32:5000/v2.0 -H "Accept: application/json" -H "User-Agent:
python-keystoneclient"
INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection
(1): 192.168.154.32
DEBUG:requests.packages.urllib3.connectionpool:"GET /v2.0 HTTP/1.1" 200 233
DEBUG:keystoneclient.session:RESP: [200] Date: Mon, 07 Nov 2016 04:17:11 GMT
Server: Apache/2.4.6 (CentOS) Vary: X-Auth-Token,Accept-Encoding
x-openstack-request-id: req-ba78762c-d651-475d-864f-dc54ea1aec15
Content-Encoding: gzip Content-Length: 233 Connection: close Content-Type:
application/json
RESP BODY: {"version": {"status": "deprecated", "updated":
"2016-08-04T00:00:00Z", "media-types": [{"base": "application/json", "type":
"application/vnd.openstack.identity-v2.0+json"}], "id": "v2.0", "links":
[{"href": "http://192.168.154.32:5000/v2.0/";, "rel": "self"}, {"href":
"http://docs.openstack.org/";, "type": "text/html", "rel": "describedby"}]}}
DEBUG:keystoneclient.auth.identity.v2:Making authentication request to
http://192.168.154.32:5000/v2.0/tokens
INFO:requests.packages.urllib3.connectionpool:Resetting dropped connection:
192.168.154.32
DEBUG:requests.packages.urllib3.connectionpool:"POST /v2.0/tokens HTTP/1.1"
200 1099
DEBUG:keystoneclient.session:REQ: curl -g -i -X GET
http://192.168.154.32:9292/v2/schemas/image -H "User-Agent:
python-glanceclient" -H "Content-Type: application/octet-stream" -H
"X-Auth-Token: {SHA1}63edd458acbd166ddc0f3e59bcd10fb0c9878e87"
INFO:requests.packages.urllib3.connectionpool:Starting new HTTP connection
(1): 192.168.154.32
DEBUG:requests.packages.urllib3.connectionpool:"GET /v2/schemas/image
HTTP/1.1" 200 4137
DEBUG:keystoneclient.session:RESP: [200] Content-Type: application/json;
charset=UTF-8 Content-Length: 4137 X-Openstack-Request-Id:
req-ea95ff03-78fd-4ec3-91a4-e68f86421f8d Date: Mon, 07 Nov 2016 04:17:11 GMT
Connection: keep-alive
RESP BODY: {"additionalProperties": {"type": "string"}, "name": "image",
"links": [{"href": "{self}", "rel": "self"}, {"href": "{file}", "rel":
"enclosure"}, {"href": "{schema}", "rel": "describedby"}], "properties":
{"status": {"readOnly": true, "enum": ["queued", "saving", "active", "killed",
"deleted", "pending_delete", "deactivated"], "type": "string", "description":
"Status of the image"}, "tags": {"items": {"
[Yahoo-eng-team] [Bug 1550866] Re: Glance- Invalid option 'visibility' error
No response from reporter, so I'm assuming the problem is using the client in v1-mode, in which 'visibility' doesn't exist. ** Changed in: glance Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1550866 Title: Glance- Invalid option 'visibility' error Status in Glance: Invalid Bug description: Summary: Visibility option is displayed in the 'glance help image- create' but error message is displayed if executed with visibility parameter Details: Executed the below command in order to register an image glance image-create --name "cirros-qcow2" --file ~/images/cirros-0.3.4-x86_64-disk.img --disk-format qcow2 --container-format bare --visibility public --progress Please refer to screenshots attached. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1550866/+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 1640008] Re: Getting routing table by parsing 'ip route' command fails on xenial
Reviewed: https://review.openstack.org/396770 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=7647e3e56f630708ad4da12ba1af429d49ac1fc1 Submitter: Jenkins Branch:master commit 7647e3e56f630708ad4da12ba1af429d49ac1fc1 Author: Omer Anson Date: Tue Nov 8 18:08:50 2016 +0200 Parse the output of ip route more robustly The code parsing the output of ip route assumes that the output is the destination network, and then key/value pairs. This is not necessarily the case, as the output may contain flags. This change modifies the parsing of ip route's output to look specifically for the keys of interest, and read their values exclusively. Change-Id: I34b6c0afb05550c970b1cacda8ec472294215403 Closes-Bug: 1640008 ** 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/1640008 Title: Getting routing table by parsing 'ip route' command fails on xenial Status in neutron: Fix Released Bug description: Getting routing table by parsing 'ip route' command fails on Ubuntu Xenial. The code assumes that ip route command returns the network, and then key-value pairs of data of the routing record. In xenial, it can be seen that ip also adds some flags at the end, e.g. linkdown. A reproduction of this failure can be seen on the gate, via 'check experimental'. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1640008/+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 1593875] Re: keystone auth silently fails if Rabbit is unavailable
See previous comment ** Changed in: keystone Status: Triaged => Won't Fix -- 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/1593875 Title: keystone auth silently fails if Rabbit is unavailable Status in OpenStack Identity (keystone): Won't Fix Bug description: If for any reason the service named rabbitmq-server.service is unavailable, keystone authentication fails. Looking at the output of openstack token issue --debug, you get this: Making authentication request to http://192.0.2.1:5000/v2.0/tokens Resetting dropped connection: 192.0.2.1 It just stays there for an eternity (unconfirmed) or until the user gets frustrated and kills it. The fact that keystone auth fails that way means that all OpenStack services similarly lag (Nova, Heat, etc). Curiously enough, rabbitmq-server was reported as being active and running, but I tried restarting it anyway. Keystone auth works now. Can reproduce this simply by stopping rabbitmq-server and trying to do things that require Keystone auth. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1593875/+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 1471665] Re: Successive runs of identity tempest tests take more and more time to finish
The root cause of this was too many revocation events, with the working being done here: https://review.openstack.org/#/q/topic:bug/1524030 it should be resolved. ** Changed in: keystone Status: Confirmed => 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/1471665 Title: Successive runs of identity tempest tests take more and more time to finish Status in OpenStack Identity (keystone): Fix Released Bug description: If I first run tempest on a newly-created VM with and install devstack with only keystone setup, first parallel run of tempest.api.identity.admin.v3 tests take around 20 seconds. If I run them again, they take around 38 seconds, third run would be around 48 seconds, and so on. I tried on local VM (virtualbox) as well as an AWS t2.medium instance. Only configuration worth mentioning was: ENABLED_SERVICES=key,mysql,tempest in local.conf Not sure if it's only keystone specific. Nevertheless, really annoying. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1471665/+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 1259425] Re: service-create allows 2 services with the same name
This is a limitation that we cannot fix without causing a backwards incompatible change. It is very rare to have 2 service names that are the same. ** Changed in: keystone Status: Triaged => Won't Fix -- 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/1259425 Title: service-create allows 2 services with the same name Status in devstack: Fix Released Status in OpenStack Identity (keystone): Won't Fix Bug description: While `service-get ` seems to be confused by the duplicated name. The same thing happens to `service-delete `. Of course, getting and deleting services by ID is not affected. Following http://docs.openstack.org/trunk/install- guide/install/apt/content/cinder-controller.html: $ keystone service-create --name=cinder --type=volume --description="Cinder Volume Service" +-+--+ | Property | Value | +-+--+ | description | Cinder Volume Service | | id | 54f9153b21b54a908562d85392784992 | | name| cinder | | type| volume | +-+--+ $ keystone service-create --name=cinder --type=volumev2 --description="Cinder Volume Service V2" +-+--+ | Property | Value | +-+--+ | description | Cinder Volume Service V2 | | id | dd425789606b4472b32d78a63942aefc | | name| cinder | | type| volumev2 | +-+--+ $ keystone service-get cinder global name 'exc' is not defined Debug output is here http://pastebin.com/kVJGUCwA I'm not sure whether duplicated names are allowed/recommended, but at least one of the following is needed: - service-create should check the name and stop when a service with the same name exists - service-get and service-delete should be changed so that they work with duplicated names, maybe by showing multiple services or reporting an appropriate error - The help text of service-get and service-delete should not say that name is allowed To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1259425/+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 1515825] Re: Logging out of horizon does not invalidate IdP session
As noted by many on this bug, this is the expected behaviour when using a federated identity provider. ** Summary changed: - Horizon allows login without credential when configured to use WebSSO + Logging out of horizon does not invalidate IdP session ** Changed in: keystone Status: Confirmed => Won't Fix -- 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/1515825 Title: Logging out of horizon does not invalidate IdP session Status in OpenStack Dashboard (Horizon): Invalid Status in OpenStack Identity (keystone): Won't Fix Status in OpenStack Security Advisory: Won't Fix Bug description: This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments. Steps to reproduce 1) Configure openid connect to use gmail 2) Configure horizon to use websso 3) Login via horizon using openid as IDP 4) Gmail login screen will appear, you enter credentials and then you will be logged in 4) Do some thing 5) Logout of horizion -- Do one more login 6) Login via horizon using open id as IDP (same as step 3) 7) Gmail login screen doesn't appear and horizon logs in directly ( step 4) doesn't happen Basically when you logout of horizon, the session you had with GMAIL is not invalidated. So after a person has logged out, another person can login without entering credentials This is true for AFDS too. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1515825/+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 1641988] [NEW] Math in server migrations API samples doesn't add up
Public bug reported: This is just a docs bug really because the server-migrations API samples are in the API reference docs, but the bytes processed/remaining/total doesn't really add up in these: https://github.com/openstack/nova/blob/925dc7aa128d060e0d0f9275a3b1fcdc98eecbf3/doc/api_samples /server-migrations/v2.23/migrations-get.json "memory_total_bytes": 123456, "memory_processed_bytes": 12345, "memory_remaining_bytes": 12, Based on ^ the memory_remaining_bytes value should be 11. Similar: "disk_total_bytes": 234567, "disk_processed_bytes": 23456, "disk_remaining_bytes": 23, Also: https://github.com/openstack/nova/blob/925dc7aa128d060e0d0f9275a3b1fcdc98eecbf3/doc/api_samples /server-migrations/v2.23/migrations-index.json ** Affects: nova Importance: Low Status: Triaged ** Tags: api-ref low-hanging-fruit -- 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/1641988 Title: Math in server migrations API samples doesn't add up Status in OpenStack Compute (nova): Triaged Bug description: This is just a docs bug really because the server-migrations API samples are in the API reference docs, but the bytes processed/remaining/total doesn't really add up in these: https://github.com/openstack/nova/blob/925dc7aa128d060e0d0f9275a3b1fcdc98eecbf3/doc/api_samples /server-migrations/v2.23/migrations-get.json "memory_total_bytes": 123456, "memory_processed_bytes": 12345, "memory_remaining_bytes": 12, Based on ^ the memory_remaining_bytes value should be 11. Similar: "disk_total_bytes": 234567, "disk_processed_bytes": 23456, "disk_remaining_bytes": 23, Also: https://github.com/openstack/nova/blob/925dc7aa128d060e0d0f9275a3b1fcdc98eecbf3/doc/api_samples /server-migrations/v2.23/migrations-index.json To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1641988/+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 1244423] Re: Inconsistency in the keystone api "enabled" field
Patches https://review.openstack.org/#/c/32758/ and https://review.openstack.org/#/c/27176/ resolved the issue ** Changed in: keystone Status: Triaged => 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/1244423 Title: Inconsistency in the keystone api "enabled" field Status in OpenStack Identity (keystone): Fix Released Bug description: The fix from this bug https://bugs.launchpad.net/keystone/+bug/1110435 have create an inconsistency in using the "enabled" field, because with the fix from this bug, enabled for **user** cannot accept ints as value i.e. 0 and 1, while in the other hand **project** enabled field accept both bool and 0 and 1. What confused me more is that there was a later bug https://bugs.launchpad.net/keystone/+bug/1167593 that fix something similar, and fixed support for "enabled" field for user and project. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1244423/+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 1240625] Re: User cannot set their own default project
See previous comments ** Changed in: keystone Status: Triaged => Won't Fix -- 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/1240625 Title: User cannot set their own default project Status in OpenStack Identity (keystone): Won't Fix Bug description: Setting Default project will create an assignment if it does not exist. However, if the relationship does exist, the user is stuck with the project that they were origianlly assigned to. If this project gets deleted, they may have a valid project, but no default project, and all of the problems that come along with that. If the user could set their own default project to a project that they already have a role in, the problem goes away. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1240625/+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 1528676] Re: OpenLDAP password policy not enforced for password changes
Write support is being removed, this will not be fixed. ** Changed in: keystone Status: Triaged => Won't Fix -- 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/1528676 Title: OpenLDAP password policy not enforced for password changes Status in OpenStack Identity (keystone): Won't Fix Status in OpenStack Security Advisory: Won't Fix Bug description: Hello there, I'm on Ubuntu 14.04.3, Openstack Juno and OpenLDAP v2.4.31 releases. I configured OpenLDAP as an identity backend for Keystone and configured it according to official documentation from: http://docs.openstack.org/developer/keystone/configuration.html I'd like my users to be able to change their own passwords, but at the same time OpenLDAP password policy to be enforced upon password changes. I've set to true all allow_creates, allow_updates and allow_deletes not to be restricted in any way by keystone. The problem is the following: RootDN account is used for binding when the user is changing his/her password. OpenLDAP password policy is not enforced when RootDN performs the password change. As a result, no password policy is enforced during password change. If I don't set LDAP user/password in keystone.conf, then users cannot change their own passwords at all. Please recommend how I can allow the users to change their own passwords and at the same time enforce OpenLDAP password policy. Thank you, Nodir To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1528676/+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 1582493] Re: Move validate_non_persistent_token() method from base to fernet
Lance is correct. ** 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/1582493 Title: Move validate_non_persistent_token() method from base to fernet Status in OpenStack Identity (keystone): Fix Released Bug description: Full path of validate_non_persistent_token(): keystone.token.providers.common.BaseProvider.validate_non_persistent_token() The validate_non_persistent_token() method is just for fernet, and there are some variables/methods used that do not exist in the BaseProvider like: self.token_formatter self._rebuild_federated_info() self._rebuild_federated_token_roles() So it is more suitable to move validate_non_persistent_token() to fernet. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1582493/+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 1553324] Re: potential DOS with revoke by id or audit_id
https://review.openstack.org/#/q/topic:bug/1524030 should fix this, time to determine revocation events is now flat once there are 80 revocation events. ** Changed in: keystone Status: New => 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/1553324 Title: potential DOS with revoke by id or audit_id Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: With our default policy, token revocation can be self-served. Without any rate limiting or SIEM mechanism in place, any user can potentially flood the revocation_event table to cause significant performance degradation or worst DOS. I've attached a simple script to continuously revoking one's own token and time the token validation time. On a vanilla devstack, with dogpile cache enabled, token validation time go from roughly 40ms to over 300ms with about 2K revocation events. We don't cleanup the revocation events till token expiration plus expiration_buffer, which is 30 minutes by default. With the default token TTL of 3600 seconds, a user could potentially fill up at least a few thousand events during that time. I know this may sound like a broken record, and yes, rate limiting or SIEM should be used. Perhaps we can add this to security hardening or OSSN? In the long run, I think we need to rethink how we handle revoke by ID as self-service. Now that we have shadow user accounts, maybe we can implement something to suspend that user if we detect token revocation abuse? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1553324/+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 1545736] Re: keystone role create failed when 4 byte unicode character is provided in name field
This should be fixed centrally with oslo.db. There is also no movement
on this patch in a long time, and I'm not convinced it's a realistic
problem (we handle UTF8 characters well enough in the database, just not
4byte ones).
** Changed in: keystone
Status: Confirmed => Won't Fix
--
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/1545736
Title:
keystone role create failed when 4 byte unicode character is provided
in name field
Status in OpenStack Identity (keystone):
Won't Fix
Bug description:
mysql database does not support 4 byte unicode due to its utf8
character set.
If any operation is executed with 4byte unicode name, it reports 500 error
without any proper error message to user.
This will be confusing for user as no information is present about why this
issue occurred.
Please refer below for details:
# keystone role-create --name sheel_🌋
An unexpected error prevented the server from fulfilling your request:
(pymysql.err.InternalError) (1366, u"Incorrect string value:
'\\xF0\\x9F\\x8C\\x8B' for column 'name' at row 1") [SQL: u'INSERT INTO role
(id, name, extra) VALUES (%s, %s, %s)'] [parameters:
('fc291c14e5e54e5a9ae6b8e159e002c9', u'sheel_\U0001f30b', '{}')] (Disable debug
mode to suppress these details.) (HTTP 500) (Request-ID:
req-a713a94e-5704-4eb9-92c4-86c4c91354f0)
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1545736/+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 1555137] Re: Transition from UUID/PKI to Fernet without dumping all tokens
Fernet was the recommended token in Newton and the default in Ocata. Only in Ocata do we actually support zero downtime upgrades, so you'll have to restart keystone and have downtime between upgrades anyway. This should be done as part of a maintenance window. I'm marking this as WONTFIX because i don't believe anyone on the core team will fix the issue and in Ocata and Pike (when fernet is default), this won't be an issue. ** Changed in: keystone Status: Triaged => Won't Fix -- 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/1555137 Title: Transition from UUID/PKI to Fernet without dumping all tokens Status in OpenStack Identity (keystone): Won't Fix Bug description: To minimize downtime, the conversion from persisted to ephemeral tokens should happen in two steps. The first migrates tokens over to the Fernet format, but will fall back to persisted store if the requested token is not in Fernet format. The second removes persistence. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1555137/+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 1639080] Re: Image uploads fail in Horizon if upload mode is set to direct if endpoint set to internal.
Add a note/warning in the horizon role docs. ** Also 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/1639080 Title: Image uploads fail in Horizon if upload mode is set to direct if endpoint set to internal. Status in OpenStack Dashboard (Horizon): New Status in openstack-ansible: New Bug description: With HORIZON_IMAGES_UPLOAD_MODE set to direct Horizon provides the endpoint for Glance based on OPENSTACK_ENDPOINT_TYPE. If OPENSTACK_ENDPOINT_TYPE is set to internalURL any browser outside the internal network is unable to upload images. Setting HORIZON_IMAGES_UPLOAD_MODE to legacy works regardless of what OPENSTACK_ENDPOINT_TYPE is set to, direct should only be used if OPENSTACK_ENDPOINT_TYPE is set to publicURL. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1639080/+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 1433311] Re: Fernet tokens don't support token bind
We now have fernet as keystone's default token provider and no one has specifically requested support for bind. I think we're safe to move this to Won't Fix. ** Changed in: keystone Status: Triaged => Won't Fix -- 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/1433311 Title: Fernet tokens don't support token bind Status in OpenStack Identity (keystone): Won't Fix Bug description: If you run test_v3_auth.py:TestAuth test cases against a Fernet token setup, the following tests will fail: keystone.tests.unit.test_v3_auth.TestFernetTokenProviderStuff.test_v2_v3_bind_token_intermix keystone.tests.unit.test_v3_auth.TestFernetTokenProviderStuff.test_verify_with_bound_token This is because a bind context is passed in on authentication and the bind context can't be validated since we don't pass it in the token payload explicitly. Failures look like the following: http://cdn.pasteraw.com/imxp1gulxgkqw3asjz79radfwbkv4pd To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1433311/+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 1611237] Re: Restart neutron-openvswitch-agent get ERROR "Switch connection timeout"
** Changed in: neutron Status: Confirmed => 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/1611237 Title: Restart neutron-openvswitch-agent get ERROR "Switch connection timeout" Status in neutron: Invalid Bug description: Environment: devstack master, ubuntu 14.04 After ./stack.sh finished, kill the neutron-openvswitch-agent process and then start it by /usr/bin/python /usr/local/bin/neutron- openvswitch-agent --config-file /etc/neutron/neutron.conf --config- file /etc/neutron/plugins/ml2/ml2_conf.ini The log shows : 2016-08-08 11:02:06.346 ERROR ryu.lib.hub [-] hub: uncaught exception: Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", line 54, in _launch return func(*args, **kwargs) File "/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py", line 97, in __call__ self.ofp_ssl_listen_port) File "/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py", line 120, in server_loop datapath_connection_factory) File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", line 117, in __init__ self.server = eventlet.listen(listen_info) File "/usr/local/lib/python2.7/dist-packages/eventlet/convenience.py", line 43, in listen sock.bind(addr) File "/usr/lib/python2.7/socket.py", line 224, in meth return getattr(self._sock,name)(*args) error: [Errno 98] Address already in use and ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ofswitch [-] Switch connection timeout In kilo I could start ovs-agent in this way correctly, I do not know it is right to start ovs-agent in master. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1611237/+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 1369959] Re: Repetation of "Attached to" in Column Header as well as populated field
Reviewed: https://review.openstack.org/300290 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=9d732abbafdbc9c14840c4e483d3a52a7ed459bb Submitter: Jenkins Branch:master commit 9d732abbafdbc9c14840c4e483d3a52a7ed459bb Author: yuki kasuya Date: Wed Mar 30 23:17:51 2016 +0900 Remove repetition of "Attached to" in table When volume is attached to instances, there is duplicated word "Attached to" in table header and table cell. So I fixed words to "devices on instances" in table cell. Change-Id: I51f506df306dbe04791512ea5eb51524fc9d878a Closes-Bug: #1369959 ** 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/1369959 Title: Repetation of "Attached to" in Column Header as well as populated field Status in OpenStack Dashboard (Horizon): Fix Released Bug description: In Project -> Volumes tab, if a volume is attached to an instance, under the "Attached to" header we have entry as "Attached to on ". IMHO it should be only " on " , we should not repeat the information To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1369959/+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 1619393] Re: cloud-init useradd/groupadd fails on ubuntu-core-16 with readonly /etc/passwd
** Also affects: cloud-init (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: cloud-init (Ubuntu Xenial)
Importance: Undecided => Medium
** Changed in: cloud-init (Ubuntu Xenial)
Status: New => Confirmed
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1619393
Title:
cloud-init useradd/groupadd fails on ubuntu-core-16 with readonly
/etc/passwd
Status in cloud-init:
Fix Committed
Status in cloud-init package in Ubuntu:
Fix Released
Status in cloud-init source package in Xenial:
Confirmed
Bug description:
=== Begin SRU Template ===
[Impact]
When running under ubuntu-core 16 images, /etc/passwd is read-only.
If my user-data includes any non-default username, creation fails due to
the read-only nature of the image.
This is addressed by useradd/groupadd including a command line flag,
--extrausers
which instructs the command to look for a different user/group database in
/var/lib/extrausers , which is writable in the ubuntu-core 16 image.
[Test Case]
In a snappy image that has cloud-init enabled, launch image with the
following user-data:
#cloud-config
users:
- name: bob
snapuser: b...@bobcom.io
And also:
#cloud-config
snappy:
email: b...@bobcom.io
where 'b...@bobcom.io' is your launchpad registered email address.
Assume you can log in.
[Regression Potential]
The code is intended to be backwards compatible and inert unless
cloud-config provided turns it on. It is also gated by a 'system_is_snappy'
method that checks if the system is snappy (ubuntu core).
Unit tests are provided, so regression should be somewhat reduced.
Some code was moved around to implement this, and a new config module
was added.
[Other Info]
The upstream change made here is at [1]
[1] https://git.launchpad.net/cloud-
init/commit?id=d8534561ba76db25b6fc0044eb1bfda63686e859
=== End SRU Template ===
When running under ubuntu-core 16 images, /etc/passwd is read-only.
If my user-data includes any non-default username, creation fails due to
the read-only nature of the image.
This is addressed by useradd/groupadd including a command line flag,
--extrausers
which instructs the command to look for a different user/group database in
/var/lib/extrausers , which is writable in the ubuntu-core 16 image.
The cc_user_groups module though is not aware of this.
The Distro base-class could check if the system it's running on is snappy
(see cc_snappy.py)
and if so, append the --extrausers parameter to the useradd/groupadd commands.
1) release is Xenial (ubuntu-core 16)
2) cloud-init present is: 0.7.7~bzr1256-0ubuntu1~16.04.1
3) useradd bob -m should create the user bob
4) useradd fails due to readonly /etc/{passwd,group,shadow}
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1619393/+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 1611237] Re: Restart neutron-openvswitch-agent get ERROR "Switch connection timeout"
I just hit the same bug with Xenial: http://logs.openstack.org/58/396658/1/gate/gate-grenade-dsvm-neutron- ubuntu- xenial/0538719/logs/old/screen-q-agt.txt.gz?level=WARNING#_2016-11-15_20_18_58_453 Seems like it's not the old ps in the end. :-| ** Changed in: neutron Status: Invalid => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1611237 Title: Restart neutron-openvswitch-agent get ERROR "Switch connection timeout" Status in neutron: Confirmed Bug description: Environment: devstack master, ubuntu 14.04 After ./stack.sh finished, kill the neutron-openvswitch-agent process and then start it by /usr/bin/python /usr/local/bin/neutron- openvswitch-agent --config-file /etc/neutron/neutron.conf --config- file /etc/neutron/plugins/ml2/ml2_conf.ini The log shows : 2016-08-08 11:02:06.346 ERROR ryu.lib.hub [-] hub: uncaught exception: Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", line 54, in _launch return func(*args, **kwargs) File "/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py", line 97, in __call__ self.ofp_ssl_listen_port) File "/usr/local/lib/python2.7/dist-packages/ryu/controller/controller.py", line 120, in server_loop datapath_connection_factory) File "/usr/local/lib/python2.7/dist-packages/ryu/lib/hub.py", line 117, in __init__ self.server = eventlet.listen(listen_info) File "/usr/local/lib/python2.7/dist-packages/eventlet/convenience.py", line 43, in listen sock.bind(addr) File "/usr/lib/python2.7/socket.py", line 224, in meth return getattr(self._sock,name)(*args) error: [Errno 98] Address already in use and ERROR neutron.plugins.ml2.drivers.openvswitch.agent.openflow.native.ofswitch [-] Switch connection timeout In kilo I could start ovs-agent in this way correctly, I do not know it is right to start ovs-agent in master. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1611237/+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 1629133] Re: New neutron subnet pool support breaks multinode testing.
** Also affects: trove Importance: Undecided Status: New ** Changed in: trove Status: New => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1629133 Title: New neutron subnet pool support breaks multinode testing. Status in networking-bgpvpn: New Status in devstack: Fix Released Status in Ironic: Fix Committed Status in ironic-python-agent: Confirmed Status in Magnum: In Progress Status in Manila: New Status in neutron: Incomplete Status in OpenStack DBaaS (Trove): In Progress Bug description: The new subnet pool support in devstack breaks multinode testing bceause it results in the route for 10.0.0.0/8 being set to via br-ex when the host has interfaces that are actually on 10 nets and that is where we need the routes to go out. Multinode testing is affected because it uses these 10 net addresses to run the vxlan overlays between hosts. For many years devstack-gate has set FIXED_RANGE to ensure that the networks devstack uses do not interfere with the underlying test host's networking. However this setting was completely ignored when setting up the subnet pools. I think the correct way to fix this is to use a much smaller subnet pool range to avoid conflicting with every possible 10.0.0.0/8 network in the wild, possibly by defaulting to the existing FIXED_RANGE information. Using the existing information will help ensure that anyone with networks in 10.0.0.0/8 will continue to work if they have specified a range that doesn't conflict using this variable. In addition to this we need to clearly document what this new stuff in devstack does and how people can work around it should they conflict with the new defaults we end up choosing. I have proposed https://review.openstack.org/379543 which mostly works except it fails one tempest test that apparently depends on this new subnet pool stuff. Specifically the V6 range isn't large enough aiui. To manage notifications about this bug go to: https://bugs.launchpad.net/bgpvpn/+bug/1629133/+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 1642062] [NEW] cloud-init-local.service should be RequiresMountsFor=/var/lib/cloud rather than /var/lib
Public bug reported: cloud-init-local.service writes to /var/lib/cloud/ and is more correct to have that listed here than /var/lib. ** Affects: cloud-init Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1642062 Title: cloud-init-local.service should be RequiresMountsFor=/var/lib/cloud rather than /var/lib Status in cloud-init: New Bug description: cloud-init-local.service writes to /var/lib/cloud/ and is more correct to have that listed here than /var/lib. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1642062/+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 1339028] Re: Update custom route on Router not take effect
Fix proposed to branch: master
Review: https://review.openstack.org/398004
** Changed in: neutron
Status: Expired => In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1339028
Title:
Update custom route on Router not take effect
Status in neutron:
In Progress
Bug description:
1. create a router
2. create a network with subnet 4.6.72.0/23
3. attach the above subnet to the router
4. update the router with route {destination: 4.6.72.0/23, nexthop:
4.6.72.10}, success
5. remove the above route from the router, success
6. update the router with the same route again, operation success, but the
route isn't added to the router namespace, so not take effect
This problem is caused by removing the connected route, so when adding
the route the second time, "ip route replace" command fail.
I think we need to restrict the modification of connected route.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1339028/+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 1642104] [NEW] Admin can reuse Project Volumes Snapshots Overview page
Public bug reported: We have _detail_overview.html defined twice - one for Project, one for Admin. They are exactly the same. We can reuse one. ** Affects: horizon Importance: Undecided Assignee: Cindy Lu (clu-m) Status: New ** Changed in: horizon Assignee: (unassigned) => Cindy Lu (clu-m) ** Changed in: horizon Milestone: None => ocata-1 -- 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/1642104 Title: Admin can reuse Project Volumes Snapshots Overview page Status in OpenStack Dashboard (Horizon): New Bug description: We have _detail_overview.html defined twice - one for Project, one for Admin. They are exactly the same. We can reuse one. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1642104/+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 1642108] [NEW] Displaying a wrong message in ng-launch instance
Public bug reported: APIs called when ng-launch instance modal is opened are async. Because of this, when a response time of an api is delayed user may see a wrong message. For example about Details tab, it needs to list availability zones and we request its infomation to Server. However, some case, users may see the message "There are no Availability Zones." because that request is not still finished. This make users confuse. We should distinguish whether there are no availability zones or just under requesting it. ** Affects: horizon Importance: Undecided Assignee: Kenji Ishii (ken-ishii) Status: New ** Changed in: horizon Assignee: (unassigned) => Kenji Ishii (ken-ishii) -- 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/1642108 Title: Displaying a wrong message in ng-launch instance Status in OpenStack Dashboard (Horizon): New Bug description: APIs called when ng-launch instance modal is opened are async. Because of this, when a response time of an api is delayed user may see a wrong message. For example about Details tab, it needs to list availability zones and we request its infomation to Server. However, some case, users may see the message "There are no Availability Zones." because that request is not still finished. This make users confuse. We should distinguish whether there are no availability zones or just under requesting it. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1642108/+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 1082248] Re: Use uuidutils instead of uuid.uuid4()
** Also affects: python-muranoclient Importance: Undecided Status: New ** Changed in: python-muranoclient Assignee: (unassigned) => feng.sheng...@zte.com.cn (feng-shengqin) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1082248 Title: Use uuidutils instead of uuid.uuid4() Status in Cinder: In Progress Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: Fix Released Status in kuryr: In Progress Status in kuryr-libnetwork: In Progress Status in Magnum: New Status in Mistral: Fix Released Status in Murano: In Progress Status in networking-calico: In Progress Status in networking-ovn: Fix Released Status in networking-sfc: In Progress Status in neutron: Fix Released Status in OpenStack Compute (nova): In Progress Status in python-muranoclient: New Status in Sahara: Fix Released Status in senlin: Fix Released Status in tacker: In Progress Bug description: Openstack common has a wrapper for generating uuids. We should only use that function when generating uuids for consistency. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1082248/+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 1642125] [NEW] Unexpected API Error? (unable to launch instance)
Public bug reported: trying to create instance with reserved ip, seems to be crashing. May be the mapped volume as well. Will troubleshoot and refine. using command: server create --volume b2f1db21-463a-47b8-bbc5-45c670752fd2 --flavor Orbit.large --security-group default --nic port-id=orbdev1.orbit8.com orbdev1.orbit8.com (openstack) server list +--+-++++ | ID | Name| Status | Networks | Image Name | +--+-++++ | e1492d01-748e-4c4b-81c4-320d81e2c7a7 | sddf| ACTIVE | polaris_external_15=10.1.15.34 | cirros | | e736d645-7738-4119-8ffa-88e07c52bb2f | orbdev2 | ACTIVE | polaris_external_15=10.1.15.29 || +--+-++++ (openstack) volume list +--+--+---+--+--+ | ID | Display Name | Status| Size | Attached to | +--+--+---+--+--+ | f991c440-edf4-4492-846f-bdd0928687de | | in-use| 100 | Attached to orbdev2 on /dev/vda | | b2f1db21-463a-47b8-bbc5-45c670752fd2 | | available | 200 | | +--+--+---+--+--+ (openstack) port list +--++---+--+ | ID | Name | MAC Address | Fixed IP Addresses | +--++---+--+ | 0737228d-da99-471b-ba78-621068dbc97b | rwb2.orbit8.com| fa:16:3e:11:e4:b8 | ip_address='10.1.15.56', subnet_id='4072fea3-59d7-4bd3-bbbe-b95ac66315d9'| | 13aeb33e-de25-4d4a-8a25-2ec17933ddd0 || fa:16:3e:13:ef:69 | ip_address='172.17.0.1', subnet_id='8410f6ef-d264-4509-b295-5b0a268f7cd0'| | 14ae55b8-9b40-435d-9bd1-72987a76d304 || fa:16:3e:a3:61:95 | ip_address='172.16.0.1', subnet_id='8036a43e-3cd9-402b-9898-b6314766f099'| | 1d994403-0204-4b48-a0bf-00db14a55bb6 || fa:16:3e:77:e0:74 | ip_address='50.205.206.34', subnet_id='fe5c5d21-16e6-494f-8247-bd0df84ed31c' | | 2092a1d9-95aa-475d-b069-b0ad17eed85d || fa:16:3e:e8:8e:1b | ip_address='172.16.0.2', subnet_id='8036a43e-3cd9-402b-9898-b6314766f099'| | 2404e63c-8b9b-475d-85a9-7ef0c483f6b7 || fa:16:3e:6c:e7:2b | ip_address='192.168.10.2', subnet_id='aaf18006-4f66-45aa-8003-fd3d64e68fe6' | | 2f6aad25-3091-446b-adf7-d8bbfceb4a0a || fa:16:3e:f8:c3:3b | ip_address='50.205.206.54', subnet_id='fe5c5d21-16e6-494f-8247-bd0df84ed31c' | | 31daa221-cb9c-4345-9416-7773039bbb17 || fa:16:3e:87:98:e0 | ip_address='10.1.15.26', subnet_id='4072fea3-59d7-4bd3-bbbe-b95ac66315d9'| | 4376a9e5-2c89-475a-9efb-57ae3c4e88ff || fa:16:3e:90:1f:ae | ip_address='10.1.15.34', subnet_id='4072fea3-59d7-4bd3-bbbe-b95ac66315d9'| | 45605cf4-3ebb-4fbf-94f6-29bf9ca288ef || fa:16:3e:55:d8:95 | ip_address='10.1.15.25', subnet_id='4072fea3-59d7-4bd3-bbbe-b95ac66315d9'| | 48f85efc-d02b-4e9c-8783-1ea534b0e3d3 | rwb1.orbit8.com| fa:16:3e:ea:b4:9d | ip_address='10.1.15.55', subnet_id='4072fea3-59d7-4bd3-bbbe-b95ac66315d9'| | 48fd38b1-9517-47bd-8cd6-32c5f0e5175d || fa:16:3e:5f:69:0c | ip_address='50.205.206.42', subnet_id='fe5c5d21-16e6-494f-8247-bd0df84ed31c' | | 5057a4d2-1147-47c3-a725-0cb14ea7cb29 || fa:16:3e:51:0e:85 | ip_address='192.168.10.16', subnet_id='aaf18006-4f66-45aa-8003-fd3d64e68fe6' | | 64e5d10f-c257-42b9-a911-b66d4c4d877b || fa:16:3e:6b:bb:e0 | ip_address='172.17.0.6', subnet_id='8410f6ef-d264-4509-b295-5b0a268f7cd0'| | 66c3f100-1269-41a6-9a8a-ac28e4124925 || fa:16:3e:8d:78:2e | ip_address='192.168.10.1', subnet_id='aaf18006-4f66-45aa-8003-fd3d64e68fe6' | | 6e755e56-0a9a-420f-99e6-056a51eab0b3 | rwb3.orbit8.com| fa:16:3e:ed:86:af | ip_address='10.1.15.57', subnet_id='4072fea3-59d7-4bd3-bbbe-b95ac66315d9'| | 70e27604-712e-427f-b1f4-6358e3154d7a || fa:16:3e:53:a7:80 | ip_address='10.1.15.2', subnet_id='4072fea3-59d7-4bd3-bbbe-b95ac66315d9' | | 88779531-91d6-479c-b59b-15b588fab9b3 |
[Yahoo-eng-team] [Bug 1642138] [NEW] Jump to home page after updating image info
Public bug reported: Description === On dashboard, there are some pages for image list. When i modified some image's info with ``Edit image`` in non-home page, always jumped to the home page. But ``delete image`` not. Steps to reproduce == * On non-home page, ``Edit image``. Expected result === Stay the image location page. Actual result = Jump to the home page. Environment === 1. horizon version # rpm -qa | grep horizon python-django-horizon-9.0.1-1.el7.noarch 2. httpd version # rpm -qa | grep httpd httpd-2.4.6-40.el7.centos.4.x86_64 httpd-tools-2.4.6-40.el7.centos.4.x86_64 ** 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/1642138 Title: Jump to home page after updating image info Status in OpenStack Dashboard (Horizon): New Bug description: Description === On dashboard, there are some pages for image list. When i modified some image's info with ``Edit image`` in non-home page, always jumped to the home page. But ``delete image`` not. Steps to reproduce == * On non-home page, ``Edit image``. Expected result === Stay the image location page. Actual result = Jump to the home page. Environment === 1. horizon version # rpm -qa | grep horizon python-django-horizon-9.0.1-1.el7.noarch 2. httpd version # rpm -qa | grep httpd httpd-2.4.6-40.el7.centos.4.x86_64 httpd-tools-2.4.6-40.el7.centos.4.x86_64 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1642138/+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 1640174] Re: Incorrect error message when creating port with DNS in Neuton and the extension is not configured
Got it, maybe I'll upload a patch later on with the fix to the message that the extension is missing, for now closing this bug ** Changed in: neutron Status: Incomplete => 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/1640174 Title: Incorrect error message when creating port with DNS in Neuton and the extension is not configured Status in neutron: Invalid Bug description: Trying to create a port with dns-name in neutron using the following command: 'neutron port-create --dns-name="moshe"' creates a port for that network with empty dns-name Testing with neutron port-show shows empty dns-name To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1640174/+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
