[Yahoo-eng-team] [Bug 1715270] Re: Remove usage of kwarg retry_on_request in API
** Changed in: tripleo Status: In Progress => 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/1715270 Title: Remove usage of kwarg retry_on_request in API Status in OpenStack Compute (nova): Fix Released Status in tripleo: Invalid Bug description: As Retry on request is always enabled in oslo.db, so kwarg retry_on_request is deprecated for removal in new release Queens. https://bugs.launchpad.net/oslo.db/+bug/1714440 http://git.openstack.org/cgit/openstack/oslo.db/tree/oslo_db/api.py#n109 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1715270/+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 1188218] Re: Support standard ceilometer compute metrics with nova baremetal
** Changed in: tripleo Status: Incomplete => 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/1188218 Title: Support standard ceilometer compute metrics with nova baremetal Status in Ceilometer: Fix Released Status in Ironic: Fix Released Status in OpenStack Compute (nova): Won't Fix Status in tripleo: Invalid Bug description: I guess this is a subset of bug #1004468 and https://blueprints.launchpad.net/ceilometer/+spec/non-libvirt-hw However, it's a bit different for nova-baremetal. There is no hypervisor we can query for CPU, disk and network statistics so we can't just add another plugin for ceilometer's compute agent. Instead, we will need an agent which runs inside each baremetal instance and posts samples to ceilometer's public /meters/ API At a first glance, these look like the counters which require a guest agent: cpu CPU time used cpu_util CPU utilisation disk.read.requestNumber of read requests disk.write.request Number of write requests disk.read.bytes Volume of read in B disk.write.bytes Volume of write in B network.incoming.bytes number of incoming bytes on the network network.outgoing.bytes number of outgoing bytes on the network network.incoming.packets number of incoming packets network.outgoing.packets number of outgoing packets For the other compute counters, we can add baremetal support to the ceilometer compute agent - e.g. these counters: instance Duration of instance instance: Duration of instance (openstack types) memory Volume of RAM in MB cpus Number of VCPUs disk.root.size Size of root disk in GB disk.ephemeral.size Size of ephemeral disk in GB One thing to consider is access control to these counters - we probably don't usually allow tenants to update these counters in, but in this case the tenant will require that ability. It's unclear whether this guest agent would live in ceilometer, nova baremetal or ironic. It's interfacing with (what should be) a very stable ceilometer API, so there's no particular need for it to live in ceilometer. I'm also adding a tripleo task, since I expect tripleo will want these metrics available for things like auto-scaling or simply resource monitoring. We'd need at least a diskimage-builder element which includes the guest agent. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1188218/+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 1777475] Re: Undercloud vm in state error after update of the undercloud.
** Changed in: tripleo Status: Triaged => 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/1777475 Title: Undercloud vm in state error after update of the undercloud. Status in OpenStack Compute (nova): New Status in tripleo: Fix Released Bug description: Hi, after an update of the undercloud, the undercloud vm is in error: [stack@undercloud-0 ~]$ openstack server list +--+--+++++ | ID | Name | Status | Networks | Image | Flavor | +--+--+++++ | 9f80c38a-9f33-4a18-88e0-b89776e62150 | compute-0| ERROR | ctlplane=192.168.24.18 | overcloud-full | compute| | e87efe17-b939-4df2-af0c-8e2effd58c95 | controller-1 | ERROR | ctlplane=192.168.24.9 | overcloud-full | controller | | 5a3ea20c-75e8-49fe-90b6-edad01fc0a48 | controller-2 | ERROR | ctlplane=192.168.24.13 | overcloud-full | controller | | ba0f26e7-ec2c-4e61-be8e-05edf00ce78a | controller-0 | ERROR | ctlplane=192.168.24.8 | overcloud-full | controller | +--+--+++++ Originally found starting there https://bugzilla.redhat.com/show_bug.cgi?id=1590297#c14 It boils down to a ordering issue between openstack-ironic-conductor and openstack-nova-compute, a simple reproducer is: sudo systemctl stop openstack-ironic-conductor sudo systemctl restart openstack-nova-compute on the undercloud. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1777475/+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 1649616] Re: Keystone Token Flush job does not complete in HA deployed environment
** Changed in: tripleo 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/1649616 Title: Keystone Token Flush job does not complete in HA deployed environment Status in Ubuntu Cloud Archive: In Progress Status in Ubuntu Cloud Archive mitaka series: Fix Released Status in Ubuntu Cloud Archive newton series: Fix Released Status in Ubuntu Cloud Archive ocata series: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) newton series: In Progress Status in OpenStack Identity (keystone) ocata series: In Progress Status in puppet-keystone: Triaged Status in tripleo: Fix Released Status in keystone package in Ubuntu: In Progress Status in keystone source package in Xenial: Fix Released Status in keystone source package in Yakkety: Fix Released Status in keystone source package in Zesty: Fix Released Bug description: [Impact] * The Keystone token flush job can get into a state where it will never complete because the transaction size exceeds the mysql galara transaction size - wsrep_max_ws_size (1073741824). [Test Case] 1. Authenticate many times 2. Observe that keystone token flush job runs (should be a very long time depending on disk) >20 hours in my environment 3. Observe errors in mysql.log indicating a transaction that is too large Actual results: Expired tokens are not actually flushed from the database without any errors in keystone.log. Only errors appear in mysql.log. Expected results: Expired tokens to be removed from the database [Additional info:] It is likely that you can demonstrate this with less than 1 million tokens as the >1 million token table is larger than 13GiB and the max transaction size is 1GiB, my token bench-marking Browbeat job creates more than needed. Once the token flush job can not complete the token table will never decrease in size and eventually the cloud will run out of disk space. Furthermore the flush job will consume disk utilization resources. This was demonstrated on slow disks (Single 7.2K SATA disk). On faster disks you will have more capacity to generate tokens, you can then generate the number of tokens to exceed the transaction size even faster. Log evidence: [root@overcloud-controller-0 log]# grep " Total expired" /var/log/keystone/keystone.log 2016-12-08 01:33:40.530 21614 INFO keystone.token.persistence.backends.sql [-] Total expired tokens removed: 1082434 2016-12-09 09:31:25.301 14120 INFO keystone.token.persistence.backends.sql [-] Total expired tokens removed: 1084241 2016-12-11 01:35:39.082 4223 INFO keystone.token.persistence.backends.sql [-] Total expired tokens removed: 1086504 2016-12-12 01:08:16.170 32575 INFO keystone.token.persistence.backends.sql [-] Total expired tokens removed: 1087823 2016-12-13 01:22:18.121 28669 INFO keystone.token.persistence.backends.sql [-] Total expired tokens removed: 1089202 [root@overcloud-controller-0 log]# tail mysqld.log 161208 1:33:41 [Warning] WSREP: transaction size limit (1073741824) exceeded: 1073774592 161208 1:33:41 [ERROR] WSREP: rbr write fail, data_len: 0, 2 161209 9:31:26 [Warning] WSREP: transaction size limit (1073741824) exceeded: 1073774592 161209 9:31:26 [ERROR] WSREP: rbr write fail, data_len: 0, 2 161211 1:35:39 [Warning] WSREP: transaction size limit (1073741824) exceeded: 1073774592 161211 1:35:40 [ERROR] WSREP: rbr write fail, data_len: 0, 2 161212 1:08:16 [Warning] WSREP: transaction size limit (1073741824) exceeded: 1073774592 161212 1:08:17 [ERROR] WSREP: rbr write fail, data_len: 0, 2 161213 1:22:18 [Warning] WSREP: transaction size limit (1073741824) exceeded: 1073774592 161213 1:22:19 [ERROR] WSREP: rbr write fail, data_len: 0, 2 Disk utilization issue graph is attached. The entire job in that graph takes from the first spike is disk util(~5:18UTC) and culminates in about ~90 minutes of pegging the disk (between 1:09utc to 2:43utc). [Regression Potential] * Not identified To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1649616/+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 1649616] Re: Keystone Token Flush job does not complete in HA deployed environment
** Also affects: puppet-keystone Importance: Undecided Status: New ** Also affects: tripleo Importance: Undecided Status: New -- 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/1649616 Title: Keystone Token Flush job does not complete in HA deployed environment Status in OpenStack Identity (keystone): In Progress Status in puppet-keystone: New Status in tripleo: New Bug description: The Keystone token flush job can get into a state where it will never complete because the transaction size exceeds the mysql galara transaction size - wsrep_max_ws_size (1073741824). Steps to Reproduce: 1. Authenticate many times 2. Observe that keystone token flush job runs (should be a very long time depending on disk) >20 hours in my environment 3. Observe errors in mysql.log indicating a transaction that is too large Actual results: Expired tokens are not actually flushed from the database without any errors in keystone.log. Only errors appear in mysql.log. Expected results: Expired tokens to be removed from the database Additional info: It is likely that you can demonstrate this with less than 1 million tokens as the >1 million token table is larger than 13GiB and the max transaction size is 1GiB, my token bench-marking Browbeat job creates more than needed. Once the token flush job can not complete the token table will never decrease in size and eventually the cloud will run out of disk space. Furthermore the flush job will consume disk utilization resources. This was demonstrated on slow disks (Single 7.2K SATA disk). On faster disks you will have more capacity to generate tokens, you can then generate the number of tokens to exceed the transaction size even faster. Log evidence: [root@overcloud-controller-0 log]# grep " Total expired" /var/log/keystone/keystone.log 2016-12-08 01:33:40.530 21614 INFO keystone.token.persistence.backends.sql [-] Total expired tokens removed: 1082434 2016-12-09 09:31:25.301 14120 INFO keystone.token.persistence.backends.sql [-] Total expired tokens removed: 1084241 2016-12-11 01:35:39.082 4223 INFO keystone.token.persistence.backends.sql [-] Total expired tokens removed: 1086504 2016-12-12 01:08:16.170 32575 INFO keystone.token.persistence.backends.sql [-] Total expired tokens removed: 1087823 2016-12-13 01:22:18.121 28669 INFO keystone.token.persistence.backends.sql [-] Total expired tokens removed: 1089202 [root@overcloud-controller-0 log]# tail mysqld.log 161208 1:33:41 [Warning] WSREP: transaction size limit (1073741824) exceeded: 1073774592 161208 1:33:41 [ERROR] WSREP: rbr write fail, data_len: 0, 2 161209 9:31:26 [Warning] WSREP: transaction size limit (1073741824) exceeded: 1073774592 161209 9:31:26 [ERROR] WSREP: rbr write fail, data_len: 0, 2 161211 1:35:39 [Warning] WSREP: transaction size limit (1073741824) exceeded: 1073774592 161211 1:35:40 [ERROR] WSREP: rbr write fail, data_len: 0, 2 161212 1:08:16 [Warning] WSREP: transaction size limit (1073741824) exceeded: 1073774592 161212 1:08:17 [ERROR] WSREP: rbr write fail, data_len: 0, 2 161213 1:22:18 [Warning] WSREP: transaction size limit (1073741824) exceeded: 1073774592 161213 1:22:19 [ERROR] WSREP: rbr write fail, data_len: 0, 2 Disk utilization issue graph is attached. The entire job in that graph takes from the first spike is disk util(~5:18UTC) and culminates in about ~90 minutes of pegging the disk (between 1:09utc to 2:43utc). To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1649616/+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 1667679] Re: Setting quota fails saying admin project is not a valid project
This is because checking for the validity of the project_id was recently added to nova with this patch https://github.com/openstack/nova/commit/f6fbfc7ff07b790ef052a759552c69429b3d79c7 However, it seems that it's tied to using keystone v3, while it should be using the keystoneclient's functions and attempt to be version agnostic. ** Also 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/1667679 Title: Setting quota fails saying admin project is not a valid project Status in OpenStack Compute (nova): New Status in tripleo: New Bug description: This is what's in the logs http://logs.openstack.org/15/359215/63 /check-tripleo/gate-tripleo-ci-centos-7-ovb- ha/3465882/console.html#_2017-02-24_11_07_08_893276 2017-02-24 11:07:08.893276 | 2017-02-24 11:07:02.000 | 2017-02-24 11:07:02,929 INFO: + openstack quota set --cores -1 --instances -1 --ram -1 b0fe52b0ac15450ba0a38ac9acd8fea8 2017-02-24 11:07:08.893365 | 2017-02-24 11:07:08.000 | 2017-02-24 11:07:08,674 INFO: Project ID b0fe52b0ac15450ba0a38ac9acd8fea8 is not a valid project. (HTTP 400) (Request-ID: req-9e0a00b7-75ae-41d5-aeed-705bb1a54bae) 2017-02-24 11:07:08.893493 | 2017-02-24 11:07:08.000 | 2017-02-24 11:07:08,758 INFO: [2017-02-24 11:07:08,757] (os-refresh-config) [ERROR] during post-configure phase. [Command '['dib-run-parts', '/usr/libexec/os-refresh-config/post-configure.d']' returned non-zero exit status 1] To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1667679/+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 1663187] Re: Nova Placement API on IPv6 unreachable from compute nodes
Seems to me that this is also a nova issue, as the interface to be used should be configurable. ** Also 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/1663187 Title: Nova Placement API on IPv6 unreachable from compute nodes Status in OpenStack Compute (nova): New Status in tripleo: In Progress Bug description: logs at http://logs.openstack.org/periodic/periodic-tripleo-ci-centos-7-ovb- updates/024c997/console.html#_2017-02-09_08_41_30_014769 show the error "No valid host was found" The deployment completed and updated successfully To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1663187/+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 1632538] Re: Using generate_service_certificate and undercloud_public_vip in undercloud.conf breaks nova
Emilien, this wasn't a tripleo issue by itself; but an issue with a library version. This has been fixed already. ** Changed in: tripleo Status: Triaged => 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/1632538 Title: Using generate_service_certificate and undercloud_public_vip in undercloud.conf breaks nova Status in OpenStack Compute (nova): Incomplete Status in OpenStack Compute (nova) newton series: Incomplete Status in tripleo: Invalid Status in python-rfc3986 package in Ubuntu: Fix Released Status in python-rfc3986 source package in Xenial: Fix Committed Status in python-rfc3986 source package in Yakkety: Fix Committed Status in python-rfc3986 source package in Zesty: Fix Released Bug description: Enabling SSL on the Undercloud using generate_service_certificate results in all Nova services on the undercloud (api, cert, compute, conductor, scheduler), all failing with errors similar to the following: 2016-10-11 22:28:27.327 66082 CRITICAL nova [req-b5f37af3-96fc-42e2-aaa6-52815aca07fe - - - - -] ConfigFileValueError: Value for option url is not valid: invalid URI: 'https://rdo-ci-fx2-06-s5.v103.rdoci.lab.eng.rdu.redhat.com:13696' 2016-10-11 22:28:27.327 66082 ERROR nova Traceback (most recent call last): 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/bin/nova-cert", line 10, in 2016-10-11 22:28:27.327 66082 ERROR nova sys.exit(main()) 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/nova/cmd/cert.py", line 49, in main 2016-10-11 22:28:27.327 66082 ERROR nova service.wait() 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/nova/service.py", line 415, in wait 2016-10-11 22:28:27.327 66082 ERROR nova _launcher.wait() 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_service/service.py", line 328, in wait 2016-10-11 22:28:27.327 66082 ERROR nova status, signo = self._wait_for_exit_or_signal() 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_service/service.py", line 303, in _wait_for_exit_or_signal 2016-10-11 22:28:27.327 66082 ERROR nova self.conf.log_opt_values(LOG, logging.DEBUG) 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2630, in log_opt_values 2016-10-11 22:28:27.327 66082 ERROR nova _sanitize(opt, getattr(group_attr, opt_name))) 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 3061, in __getattr__ 2016-10-11 22:28:27.327 66082 ERROR nova return self._conf._get(name, self._group) 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2672, in _get 2016-10-11 22:28:27.327 66082 ERROR nova value = self._do_get(name, group, namespace) 2016-10-11 22:28:27.327 66082 ERROR nova File "/usr/lib/python2.7/site-packages/oslo_config/cfg.py", line 2715, in _do_get 2016-10-11 22:28:27.327 66082 ERROR nova % (opt.name, str(ve))) 2016-10-11 22:28:27.327 66082 ERROR nova ConfigFileValueError: Value for option url is not valid: invalid URI: 'https://rdo-ci-fx2-06-s5.v103.rdoci.lab.eng.rdu.redhat.com:13696' 2016-10-11 22:28:27.327 66082 ERROR nova I believe the failure happens inside the [neutron] section of /etc/nova/nova.conf. This does not look related to the scheme (https) being used as the result of enabling SSL because doing a one-off test with the openstack-nova-conductor service after changing the schema to http results in the same startup failure. Another one-off test substituting an IP address instead of a FQDN inside of nova.conf with the openstack-nova-conductor service as before results in openstack-nova-conductor starting properly but eventually failing with a connection-related failure due to the one- off data used (an IP address of 1.2.3.4). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1632538/+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 1590608] Re: Services should use http_proxy_to_wsgi middleware
this is also needed in Heat's CFN endpoint. The API endpoint uses it already. ** Also affects: heat Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1590608 Title: Services should use http_proxy_to_wsgi middleware Status in Aodh: In Progress Status in Barbican: New Status in Ceilometer: In Progress Status in Cinder: Fix Released Status in Glance: Fix Released Status in Gnocchi: In Progress Status in heat: In Progress Status in OpenStack Identity (keystone): Fix Released Status in neutron: In Progress Status in OpenStack DBaaS (Trove): In Progress Bug description: It's a common problem when putting a service behind a load balancer to need to forward the Protocol and hosts of the original request so that the receiving service can construct URLs to the loadbalancer and not the private worker node. Most services have implemented some form of secure_proxy_ssl_header = HTTP_X_FORWARDED_PROTO handling however exactly how this is done is dependent on the service. oslo.middleware provides the http_proxy_to_wsgi middleware that handles these headers and the newer RFC7239 forwarding header and completely hides the problem from the service. This middleware should be adopted by all services in preference to their own HTTP_X_FORWARDED_PROTO handling. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1590608/+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 1590608] Re: Services should use http_proxy_to_wsgi middleware
this was added to cinder here https://review.openstack.org/#/c/305152/ ** Changed in: cinder Status: New => 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/1590608 Title: Services should use http_proxy_to_wsgi middleware Status in Aodh: New Status in Barbican: New Status in Ceilometer: New Status in Cinder: Fix Released Status in Glance: Fix Released Status in Gnocchi: New Status in OpenStack Identity (keystone): Fix Released Status in neutron: In Progress Status in OpenStack DBaaS (Trove): In Progress Bug description: It's a common problem when putting a service behind a load balancer to need to forward the Protocol and hosts of the original request so that the receiving service can construct URLs to the loadbalancer and not the private worker node. Most services have implemented some form of secure_proxy_ssl_header = HTTP_X_FORWARDED_PROTO handling however exactly how this is done is dependent on the service. oslo.middleware provides the http_proxy_to_wsgi middleware that handles these headers and the newer RFC7239 forwarding header and completely hides the problem from the service. This middleware should be adopted by all services in preference to their own HTTP_X_FORWARDED_PROTO handling. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1590608/+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 1590608] Re: Services should use http_proxy_to_wsgi middleware
** Also affects: neutron Importance: Undecided Status: New ** Also affects: aodh Importance: Undecided Status: New ** Also affects: ceilometer Importance: Undecided Status: New ** Also affects: gnocchi Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1590608 Title: Services should use http_proxy_to_wsgi middleware Status in Aodh: New Status in Barbican: New Status in Ceilometer: New Status in Cinder: Fix Released Status in Glance: Fix Released Status in Gnocchi: New Status in OpenStack Identity (keystone): Fix Released Status in neutron: In Progress Status in OpenStack DBaaS (Trove): In Progress Bug description: It's a common problem when putting a service behind a load balancer to need to forward the Protocol and hosts of the original request so that the receiving service can construct URLs to the loadbalancer and not the private worker node. Most services have implemented some form of secure_proxy_ssl_header = HTTP_X_FORWARDED_PROTO handling however exactly how this is done is dependent on the service. oslo.middleware provides the http_proxy_to_wsgi middleware that handles these headers and the newer RFC7239 forwarding header and completely hides the problem from the service. This middleware should be adopted by all services in preference to their own HTTP_X_FORWARDED_PROTO handling. To manage notifications about this bug go to: https://bugs.launchpad.net/aodh/+bug/1590608/+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 1573766] Re: Enable the paste filter HTTPProxyToWSGI by default
Had added cinder, but now I noticed there was already a bug report filed there too https://bugs.launchpad.net/cinder/+bug/1573766 So I'll use that one instead for Cinder. This still applies for Nova though. ** Also affects: cinder Importance: Undecided Status: New ** No longer affects: cinder -- 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/1573766 Title: Enable the paste filter HTTPProxyToWSGI by default Status in OpenStack Compute (nova): In Progress Bug description: oslo middleware provides a paste filter that sets the correct proxy scheme and host. This is needed for the TLS proxy case. Without this then enabling the TLS proxy in devstack will fail configuring tempest because 'nova flavor-list' returns a http scheme in Location in a redirect it returns. I've proposed a temporary workaround in devstack using: +iniset $NOVA_API_PASTE_INI filter:ssl_header_handler past e.filter_factory oslo_middleware.http_proxy_to_wsgi:HTTPProxyToWSGI.factory +iniset $NOVA_API_PASTE_INI composite:openstack_compute_ap i_v21 keystone "ssl_header_handler cors compute_req_id faultwrap sizelimit autht oken keystonecontext osapi_compute_app_v21" But this isn't a long-term solution because two copies of the default paste filters will need to be maintained. See https://review.openstack.org/#/c/301172 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1573766/+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 1350273] [NEW] Filtering services by name doesn't work
Public bug reported: doing a query for listing services filtering by name doesn't work in the SQL backend. This is due to a couple of things: * 'name' doesn't appear in the filterprotected decorator in keystone.catalog.controllers line 250 * the sql model for the service doesn't have an explicit name attribute in keystone.catalog.backends.sql This is an issue since some clients (namely python-openstackclient) give the option to create endpoints with the service name as a parameter (you can give the service id, name or type), even though it is not possible to retrieve a service from keystone using the name. ** Affects: keystone Importance: Undecided Assignee: Juan Antonio Osorio Robles (juan-osorio-robles) Status: New ** Changed in: keystone Assignee: (unassigned) = Juan Antonio Osorio Robles (juan-osorio-robles) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1350273 Title: Filtering services by name doesn't work Status in OpenStack Identity (Keystone): New Bug description: doing a query for listing services filtering by name doesn't work in the SQL backend. This is due to a couple of things: * 'name' doesn't appear in the filterprotected decorator in keystone.catalog.controllers line 250 * the sql model for the service doesn't have an explicit name attribute in keystone.catalog.backends.sql This is an issue since some clients (namely python-openstackclient) give the option to create endpoints with the service name as a parameter (you can give the service id, name or type), even though it is not possible to retrieve a service from keystone using the name. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1350273/+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 1278738] Re: trusts in keystone fail in driver when impersonation is not provided
** 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 Keystone.
https://bugs.launchpad.net/bugs/1278738
Title:
trusts in keystone fail in driver when impersonation is not provided
Status in OpenStack Identity (Keystone):
Fix Released
Bug description:
When creating trusts in Keystone, if 'impersonation' is not provided
Keystone fails out in the backend code. This should probably be handed
at the controller level to be consistent across all backends.
lbragstad@precise64:~/curl-examples$ cat create_trust.json
{
trust: {
expires_at: 2014-02-27T18:30:59.99Z,
project_id: c7e2b98178e64418bb884929d3611b89,
impersonation: true,
roles: [
{
name: admin
}
],
trustee_user_id: bf3a4c9ef46d44fa9ce57349462b1998,
trustor_user_id: 406e6d96a30449069bf4241a00308b23
}
}
lbragstad@precise64:~/curl-examples$ cat create_trust_bad.json
{
trust: {
expires_at: 2014-02-27T18:30:59.99Z,
project_id: c7e2b98178e64418bb884929d3611b89,
roles: [
{
name: admin
}
],
trustee_user_id: bf3a4c9ef46d44fa9ce57349462b1998,
trustor_user_id: 406e6d96a30449069bf4241a00308b23
}
}
Using impersonation in the create_trust.json file returns a trust
successfully:
lbragstad@precise64:~/curl-examples$ curl -si -H X-Auth-Token:$TOKEN -H
Content-type:application/json -d @create_trust.json
http://localhost:5000/v3/OS-TRUST/trusts
HTTP/1.1 201 Created
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 675
Date: Sun, 09 Feb 2014 04:36:56 GMT
{trust: {impersonation: true, roles_links: {self:
http://10.0.2.15:5000/v3/OS-
TRUST/trusts/12ce9f7214f04c018384f654f5ea9aa5/roles, previous:
null, next: null}, trustor_user_id:
406e6d96a30449069bf4241a00308b23, links: {self:
http://10.0.2.15:5000/v3/OS-
TRUST/trusts/12ce9f7214f04c018384f654f5ea9aa5}, roles: [{id:
937488fff5444edb9da1e93d20596d4b, links: {self:
http://10.0.2.15:5000/v3/roles/937488fff5444edb9da1e93d20596d4b},
name: admin}], expires_at: 2014-02-27T18:30:59.99Z,
trustee_user_id: bf3a4c9ef46d44fa9ce57349462b1998, project_id:
c7e2b98178e64418bb884929d3611b89, id:
12ce9f7214f04c018384f654f5ea9aa5}}
When using the request without impersonation defined I get:
lbragstad@precise64:~/curl-examples$ curl -si -H X-Auth-Token:$TOKEN -H
Content-type:application/json -d @create_trust_bad.json http://localhos
t:5000/v3/OS-TRUST/trusts
HTTP/1.1 500 Internal Server Error
Vary: X-Auth-Token
Content-Type: application/json
Content-Length: 618
Date: Sun, 09 Feb 2014 04:33:08 GMT
{error: {message: An unexpected error prevented the server from
fulfilling your request. (OperationalError) (1048, \Column 'impersonation
' cannot be null\) 'INSERT INTO trust (id, trustor_user_id, trustee_user_id,
project_id, impersonation, deleted_at, expires_at, extra) VALUES
(%s, %s, %s, %s, %s, %s, %s, %s)' ('b49ac0c7558a4450949c22c840db9794',
'406e6d96a30449069bf4241a00308b23', 'bf3a4c9ef46d44fa9ce57349462b1998',
'c7e2b98178e64418bb884929d3611b89', None, None, datetime.datetime(2014, 2,
27, 18, 30, 59, 99), '{\roles\: [{\name\: \admin\}]}'),
code: 500, title: Internal Server Error}}
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1278738/+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
