| 2020-06-27 07:36:09 |
Martin Gerhard Loschwitz |
bug |
|
|
added bug |
| 2020-06-27 07:50:55 |
Martin Gerhard Loschwitz |
description |
Horizon offers the opportunity to create a volume from a snapshot. It does not, however, properly determine the type of the originating volume of the snapshot and tries to use the default. In environments with non-default storage types (e.g. encrypted storages, like in our case), this fails and leads to an error message:
2020-06-26 16:13:12,633 36 WARNING horizon.exceptions Recoverable error: Invalid input received: Invalid volume_type provided: d4917a31-3332-4323-9b1f-9ace3dda9d9a (requested type is not compatible; recommend omitting the type argument). (HTTP 400) (Request-ID: req-40ee2f61-6a16-44f2-96d7-46f5c42f1942)
Problematic code is in cinder/forms.py of Horizon:
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/forms.py#L379
Under normal circumstances, the storage type should be set in that file in "prepare_source_fields_if_snapshot_specified" (https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/forms.py#L145)
That code would need to be triggered in the __init__ function of CreateForm (https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/forms.py#L297) which tests the GET of the original request for certain strings.
Debugging however, unveils that GET simply does not contain any of the strings checked for there anymore -- in our case, it always was "<WSGIRequest: GET '/dashboard/project/volumes/create/'>". So in fact, the whole code path starting at https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/forms.py#L314 might be death and the default will always be used. The default doesn't populate "type", however,
This of course also leads to creating volumes from volumes not working due to the same issue. |
Horizon offers the opportunity to create a volume from a snapshot. It does not, however, properly determine the type of the originating volume of the snapshot and tries to use the default. In environments with non-default storage types (e.g. encrypted storages, like in our case), this fails and leads to an error message:
2020-06-26 16:13:12,633 36 WARNING horizon.exceptions Recoverable error: Invalid input received: Invalid volume_type provided: d4917a31-3332-4323-9b1f-9ace3dda9d9a (requested type is not compatible; recommend omitting the type argument). (HTTP 400) (Request-ID: req-40ee2f61-6a16-44f2-96d7-46f5c42f1942)
Problematic code is in cinder/forms.py of Horizon:
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/forms.py#L379
Under normal circumstances, the storage type should be set in that file in "prepare_source_fields_if_snapshot_specified" (https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/forms.py#L145)
That code would need to be triggered in the __init__ function of CreateForm (https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/forms.py#L297) which tests the GET of the original request for certain strings.
Debugging however, unveils that GET simply does not contain any of the strings checked for there anymore -- in our case, it always was "<WSGIRequest: GET '/dashboard/project/volumes/create/'>". So in fact, the whole code path starting at https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/forms.py#L314 might be death and the default will always be used. The default doesn't populate "type", however,
This of course also leads to creating volumes from volumes not working due to the same issue.
Found with the help of Harald Wagener. |
|
| 2020-06-27 07:56:45 |
Martin Gerhard Loschwitz |
description |
Horizon offers the opportunity to create a volume from a snapshot. It does not, however, properly determine the type of the originating volume of the snapshot and tries to use the default. In environments with non-default storage types (e.g. encrypted storages, like in our case), this fails and leads to an error message:
2020-06-26 16:13:12,633 36 WARNING horizon.exceptions Recoverable error: Invalid input received: Invalid volume_type provided: d4917a31-3332-4323-9b1f-9ace3dda9d9a (requested type is not compatible; recommend omitting the type argument). (HTTP 400) (Request-ID: req-40ee2f61-6a16-44f2-96d7-46f5c42f1942)
Problematic code is in cinder/forms.py of Horizon:
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/forms.py#L379
Under normal circumstances, the storage type should be set in that file in "prepare_source_fields_if_snapshot_specified" (https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/forms.py#L145)
That code would need to be triggered in the __init__ function of CreateForm (https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/forms.py#L297) which tests the GET of the original request for certain strings.
Debugging however, unveils that GET simply does not contain any of the strings checked for there anymore -- in our case, it always was "<WSGIRequest: GET '/dashboard/project/volumes/create/'>". So in fact, the whole code path starting at https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/forms.py#L314 might be death and the default will always be used. The default doesn't populate "type", however,
This of course also leads to creating volumes from volumes not working due to the same issue.
Found with the help of Harald Wagener. |
Horizon offers the opportunity to create a volume from a snapshot. It does not, however, properly determine the type of the originating volume of the snapshot and tries to use the default. In environments with non-default storage types (e.g. encrypted storages, like in our case), this fails and leads to an error message:
2020-06-26 16:13:12,633 36 WARNING horizon.exceptions Recoverable error: Invalid input received: Invalid volume_type provided: d4917a31-3332-4323-9b1f-9ace3dda9d9a (requested type is not compatible; recommend omitting the type argument). (HTTP 400) (Request-ID: req-40ee2f61-6a16-44f2-96d7-46f5c42f1942)
Problematic code is in cinder/forms.py of Horizon:
https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/forms.py#L379
Under normal circumstances, the storage type should be set in that file in "prepare_source_fields_if_snapshot_specified" (https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/forms.py#L145)
That code would need to be triggered in the __init__ function of CreateForm (https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/forms.py#L297) which tests the GET of the original request for certain strings.
Debugging however, unveils that GET simply does not contain any of the strings checked for there anymore -- in our case, it always was "<WSGIRequest: GET '/dashboard/project/volumes/create/'>". So in fact, the whole code path starting at https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/volumes/forms.py#L314 might be dead and the default will always be used. The default doesn't populate "type", however,
This of course also leads to creating volumes from volumes not working due to the same issue.
Found with the help of Harald Wagener. |
|
| 2020-06-27 09:28:37 |
OpenStack Infra |
horizon: status |
New |
In Progress |
|
| 2020-06-27 09:28:37 |
OpenStack Infra |
horizon: assignee |
|
Martin Gerhard Loschwitz (martin-loschwitz) |
|
| 2020-10-14 16:33:20 |
David Coronel |
bug |
|
|
added subscriber David Coronel |
| 2020-10-14 16:44:48 |
David Coronel |
bug |
|
|
added subscriber Canonical Field High |
| 2020-10-19 07:28:10 |
Oleg Kabanov |
bug |
|
|
added subscriber Oleg Kabanov |
| 2020-10-19 18:28:22 |
Corey Bryant |
horizon: status |
In Progress |
Invalid |
|
| 2020-10-19 18:28:31 |
Corey Bryant |
bug task added |
|
cinder |
|
| 2020-10-19 18:28:56 |
Corey Bryant |
marked as duplicate |
|
1879578 |
|
