| 2018-09-15 15:01:53 |
Liang Fang |
bug |
|
|
added bug |
| 2018-09-15 15:03:33 |
Liang Fang |
bug task added |
|
glance |
|
| 2018-09-15 15:04:14 |
Liang Fang |
bug task added |
|
python-glanceclient |
|
| 2018-09-15 15:32:17 |
Sean McGinnis |
cinder: status |
New |
Incomplete |
|
| 2018-09-15 15:46:11 |
Liang Fang |
cinder: assignee |
|
Liang Fang (liangfang) |
|
| 2018-09-15 15:46:20 |
Liang Fang |
glance: assignee |
|
Liang Fang (liangfang) |
|
| 2018-09-15 15:46:24 |
Liang Fang |
python-glanceclient: assignee |
|
Liang Fang (liangfang) |
|
| 2018-09-15 15:51:25 |
Liang Fang |
description |
When uploading a volume to glance as an image, the glance server don't know the image size, so the backend storage server(such as ceph) need to resize the image every time it received new chunk of data(by default 64K). So there will be huge times of resize operations that will terribly impact the performance. The patch aims to tell the image size to glance server at the initial phase of uploading, so that glance backend such as ceph can allocate an image with exact size, and don't need to resize the image again and again
This is an known issue which can be found in driver files of all kinds of backend storage system:
In file: glance_store/_drivers/rbd.py, function: add
In file: glance_store/_drivers/cinder.py, function: add
In file: glance_store/_drivers/sheepdog.py, function: add
In all these files, there're comments like below:
# If the image size provided is zero we need to do
# a resize for the amount we are writing. This will
# be slower so setting a higher chunk size may
# speed things up a bit. |
When uploading a volume to glance as an image, the glance server don't know the image size, so the backend storage server(such as ceph) need to resize the image every time it received new chunk of data(by default 64K). So there will be huge times of resize operations that will terribly impact the performance.
This is an known issue which can be found in driver files of all kinds of backend storage system:
In file: glance_store/_drivers/rbd.py, function: add
In file: glance_store/_drivers/cinder.py, function: add
In file: glance_store/_drivers/sheepdog.py, function: add
In all these files, there're comments like below:
# If the image size provided is zero we need to do
# a resize for the amount we are writing. This will
# be slower so setting a higher chunk size may
# speed things up a bit. |
|
| 2018-09-16 15:51:12 |
OpenStack Infra |
cinder: status |
Incomplete |
In Progress |
|
| 2018-09-17 03:31:54 |
OpenStack Infra |
glance: status |
New |
In Progress |
|
| 2018-09-17 06:43:17 |
OpenStack Infra |
python-glanceclient: status |
New |
In Progress |
|
| 2018-09-17 06:57:15 |
Liang Fang |
description |
When uploading a volume to glance as an image, the glance server don't know the image size, so the backend storage server(such as ceph) need to resize the image every time it received new chunk of data(by default 64K). So there will be huge times of resize operations that will terribly impact the performance.
This is an known issue which can be found in driver files of all kinds of backend storage system:
In file: glance_store/_drivers/rbd.py, function: add
In file: glance_store/_drivers/cinder.py, function: add
In file: glance_store/_drivers/sheepdog.py, function: add
In all these files, there're comments like below:
# If the image size provided is zero we need to do
# a resize for the amount we are writing. This will
# be slower so setting a higher chunk size may
# speed things up a bit. |
When uploading a volume to glance as an image, the glance server don't know the image size, so the backend storage server(such as ceph) need to resize the image every time it received new chunk of data(by default 64K). So there will be huge times of resize operations that will terribly impact the performance.
- regarding cinder, it has not calculate the image size and pass the correct size to glanceclient
- regarding glanceclient, it has not carried the size in (http/https) request which sending to glance server
- regarding glance, it has not extract the size from the request during the deserial phase, so even the subsequent api contains argument "size", the value is always 0.
This is an known issue which can be found in driver files of all kinds of backend storage system:
In file: glance_store/_drivers/rbd.py, function: add
In file: glance_store/_drivers/cinder.py, function: add
In file: glance_store/_drivers/sheepdog.py, function: add
In all these files, there're comments like below:
# If the image size provided is zero we need to do
# a resize for the amount we are writing. This will
# be slower so setting a higher chunk size may
# speed things up a bit. |
|
| 2018-09-20 15:59:05 |
Jay Bryant |
cinder: importance |
Undecided |
Medium |
|
| 2019-04-18 10:05:17 |
Liang Fang |
bug task deleted |
python-glanceclient |
|
|
| 2019-04-18 10:07:19 |
Liang Fang |
description |
When uploading a volume to glance as an image, the glance server don't know the image size, so the backend storage server(such as ceph) need to resize the image every time it received new chunk of data(by default 64K). So there will be huge times of resize operations that will terribly impact the performance.
- regarding cinder, it has not calculate the image size and pass the correct size to glanceclient
- regarding glanceclient, it has not carried the size in (http/https) request which sending to glance server
- regarding glance, it has not extract the size from the request during the deserial phase, so even the subsequent api contains argument "size", the value is always 0.
This is an known issue which can be found in driver files of all kinds of backend storage system:
In file: glance_store/_drivers/rbd.py, function: add
In file: glance_store/_drivers/cinder.py, function: add
In file: glance_store/_drivers/sheepdog.py, function: add
In all these files, there're comments like below:
# If the image size provided is zero we need to do
# a resize for the amount we are writing. This will
# be slower so setting a higher chunk size may
# speed things up a bit. |
When uploading a volume to glance as an image, the glance server don't know the image size, so the backend storage server(such as ceph) need to resize the image every time it received new chunk of data(by default 64K). So there will be huge times of resize operations that will impact the performance.
- regarding cinder, it has not calculate the image size and pass the correct size to glance
- regarding glance, it should allow the client to set image size.
This is an known issue which can be found in driver files of all kinds of backend storage system:
In file: glance_store/_drivers/rbd.py, function: add
In file: glance_store/_drivers/cinder.py, function: add
In file: glance_store/_drivers/sheepdog.py, function: add
In all these files, there're comments like below:
# If the image size provided is zero we need to do
# a resize for the amount we are writing. This will
# be slower so setting a higher chunk size may
# speed things up a bit. |
|
| 2019-05-02 16:53:14 |
Erno Kuvaja |
glance: importance |
Undecided |
High |
|
| 2019-05-02 16:53:14 |
Erno Kuvaja |
glance: milestone |
|
next |
|
| 2019-05-02 16:53:41 |
Erno Kuvaja |
bug task added |
|
glance-store |
|
| 2019-05-02 16:53:57 |
Erno Kuvaja |
glance-store: importance |
Undecided |
High |
|
| 2019-05-02 16:54:14 |
Erno Kuvaja |
bug task deleted |
glance |
|
|
| 2020-03-20 09:40:11 |
Ivan Borisov |
bug task added |
|
glance |
|
| 2020-03-20 09:50:00 |
Ivan Borisov |
bug |
|
|
added subscriber Ivan Borisov |
| 2020-08-17 17:57:57 |
Erno Kuvaja |
glance-store: assignee |
|
Erno Kuvaja (jokke) |
|
| 2020-08-17 17:58:37 |
Erno Kuvaja |
glance-store: status |
New |
Triaged |
|
| 2020-08-17 18:01:32 |
OpenStack Infra |
glance-store: status |
Triaged |
In Progress |
|
| 2020-11-20 14:29:53 |
OpenStack Infra |
tags |
|
in-stable-ussuri |
|
