Activity log for bug #1584070

Date Who What changed Old value New value Message
2016-05-20 14:07:43 Kairat Kushaev bug added bug
2016-05-20 14:08:08 Kairat Kushaev mos: assignee MOS Puppet Team (mos-puppet)
2016-05-20 14:08:13 Bug Checker Bot tags need-info
2016-05-20 14:08:14 Kairat Kushaev mos: importance Undecided High
2016-05-20 14:08:20 Kairat Kushaev mos: milestone 9.0
2016-05-20 14:08:28 Kairat Kushaev nominated for series mos/10.0.x
2016-05-20 14:08:28 Kairat Kushaev bug task added mos/10.0.x
2016-05-20 14:08:47 Kairat Kushaev nominated for series mos/9.0.x
2016-05-20 14:08:47 Kairat Kushaev bug task added mos/9.0.x
2016-05-20 14:08:54 Kairat Kushaev mos/9.0.x: milestone 9.0
2016-05-20 14:09:04 Kairat Kushaev mos/10.0.x: assignee MOS Puppet Team (mos-puppet)
2016-05-20 14:35:16 Kairat Kushaev mos/10.0.x: importance Undecided High
2016-05-20 14:43:03 Kairat Kushaev description Verification on iso #372 (9.0-mos.all). Shotgun report: http://paste.openstack.org/show/497853 Use glance with Swift backend only. This bug was detected during https://bugs.launchpad.net/mos/+bug/1576035 check. Steps: [on all controllers] 1. Change token expiration from 3600 to 60. 2. Restart apache2,glance-api,glance-registry. [on slave by cli] 1. Create new image file by command: fallocate -l 4G temp.img 2. Upload into glance: glance image-create --file temp.img --progress --container-format bare --disk-format qcow2 Excepted result: Successfully uploaded. Actual result: Upload failed. API logs: https://paste.mirantis.net/show/2287/ The root cause of the following: during uploading of big images Glance splits images to chunks. Each chunk upload requires token. So when token expires uploading fails. Glance store has a mechanism to prevent such error but we need to use keystone v3 to create trust for swift driver in glance_store. So in order to use re-auth in glance_store we need to do the following: 1. add another reference to /etc/glance/glance-swift.conf file. Example: [ref2] user = services:glance key = k5QOJ3Jia7b6DXWSBXrcFBub user_domain_id = default project_domain_id = default auth_version = 3 auth_address = http://10.109.13.2:5000/v3 Please note that we are using v3 for authentication. Also we can replace old reference (ref1) with the reference above if there are no active images in database. 2. Change default_swift_reference to ref2 in glance-api.conf. In that case glance can upload any images to swift without auth errors. Verification on iso #372 (9.0-mos.all). Shotgun report: http://paste.openstack.org/show/497853 Use glance with Swift backend only. This bug was detected during https://bugs.launchpad.net/mos/+bug/1576035 check. Steps: [on all controllers] 1. Change token expiration from 3600 to 60. 2. Restart apache2,glance-api,glance-registry. [on slave by cli] 1. Create new image file by command: fallocate -l 4G temp.img 2. Upload into glance: glance image-create --file temp.img --progress --container-format bare --disk-format qcow2 Excepted result:  Successfully uploaded. Actual result:  Upload failed. API logs: https://paste.mirantis.net/show/2287/ The root cause of the following: during uploading of big images Glance splits images to chunks. Each chunk upload requires token. So when token expires uploading fails. Glance store has a mechanism to prevent such error but we need to use keystone v3 to create trust for swift driver in glance_store. So in order to use re-auth in glance_store we need to do the following: 1. add another reference to /etc/glance/glance-swift.conf file. Example: [ref2] user = services:glance key = <some_key> user_domain_id = default project_domain_id = default auth_version = 3 auth_address = http://<keystone_url>:5000/v3 Please note that we are using v3 for authentication. Also we can replace old reference (ref1) with the reference above if there are no active images in database. 2. Change default_swift_reference to ref2 in glance-api.conf. In that case glance can upload any images to swift without auth errors.
2016-05-23 13:01:36 Roman Podoliaka mos/10.0.x: status New Confirmed
2016-05-23 13:01:38 Roman Podoliaka mos/9.0.x: status New Confirmed
2016-05-23 13:01:44 Roman Podoliaka tags need-info area-puppet need-info
2016-05-23 14:33:06 Roman Podoliaka mos/10.0.x: milestone 10.0
2016-05-23 14:33:08 Roman Podoliaka mos/9.0.x: milestone 9.0
2016-05-23 14:46:30 Denis Egorenko mos/10.0.x: assignee MOS Puppet Team (mos-puppet) Denis Egorenko (degorenko)
2016-05-23 14:46:31 Denis Egorenko mos/9.0.x: assignee MOS Puppet Team (mos-puppet) Denis Egorenko (degorenko)
2016-05-23 14:57:54 Denis Egorenko mos/10.0.x: status Confirmed In Progress
2016-05-25 09:05:49 Denis Egorenko mos/10.0.x: status In Progress Fix Committed
2016-05-25 09:05:52 Denis Egorenko mos/9.0.x: status Confirmed In Progress
2016-05-30 08:31:14 Denis Egorenko mos/9.0.x: status In Progress Fix Committed
2016-06-01 11:39:50 Denis Egorenko mos/9.0.x: status Fix Committed Fix Released
2017-11-10 15:11:41 Denis Meltsaykin mos/9.x: status Fix Released Confirmed
2017-11-10 15:11:47 Denis Meltsaykin mos/9.x: milestone 9.0 9.2-mu-4
2017-11-10 15:12:17 Denis Meltsaykin mos/9.x: assignee Denis Egorenko (degorenko)
2017-11-10 15:12:30 Denis Meltsaykin mos/9.x: assignee MOS Maintenance (mos-maintenance)
2017-11-10 15:20:09 Dmitry Sutyagin bug added subscriber Dmitry Sutyagin
2017-11-13 13:44:09 Denis Meltsaykin mos/9.x: status Confirmed In Progress
2017-11-21 14:08:13 Denis Meltsaykin mos/9.x: assignee MOS Maintenance (mos-maintenance) Denis Meltsaykin (dmeltsaykin)
2017-11-21 14:08:24 Denis Meltsaykin mos/9.x: status In Progress Fix Committed
2017-12-04 12:36:20 Dmitry mos/9.x: status Fix Committed Fix Released