yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #75683
[Bug 1802587] [NEW] With multiple backends enabled, adding a location does not default to default store
Public bug reported:
I have multiple backends set up in an S-1 devstack and make this call:
data.json:
[
{
"op": "add",
"path": "/locations/-",
"value": {"url": "https://review.openstack.org/static/title.svg?e=6b20e64d6472edfb0e38b30442683e8a",
"metadata": {},
"validation_data": {"checksum": "24c3834b2a43a823c181a82b9727d687",
"os_hash_algo": "sha512",
"os_hash_value": "a8ddd76c5b222c772584bdc6099887cdbd9d7fbc48bc5acaa07dcd8a3ba36a32b22f502ea4789a792a66580ef316d929d0506ec3df900d44d9bd51f97ea90ae2"
}
}
}
]
demo! curl -X PATCH \
-H "x-auth-token: $TK" \
-H "Content-type: application/openstack-images-v2.1-json-patch" \
-d @data.json \
"$OS_IMAGE_URL/v2/images/$IMG"
What I expect: the default store will be used.
What happens:
<html>
<head>
<title>400 Bad Request</title>
</head>
<body>
<h1>400 Bad Request</h1>
Invalid location<br /><br />
</body>
Here's the error that's occurring. (Line numbers may be off slightly from my hacking.)
Traceback (most recent call last):
File "/opt/stack/glance/glance/location.py", line 108, in _check_location_uri
uri, backend, context=context)
File "/opt/stack/glance_store/glance_store/multi_backend.py", line 486, in get_size_from_uri_and_backend
uri, backend, conf=CONF)
File "/opt/stack/glance_store/glance_store/location.py", line 109, in get_location_from_uri_and_backend
raise exceptions.UnknownScheme(scheme=backend)
UnknownScheme: Unknown scheme 'None' found in URI
The call to store_api.get_size_from_uri_and_backend() is being made with:
uri: https://review.openstack.org/static/title.svg?e=6b20e64d6472edfb0e38b30442683e8a
backend: None
The call is happening here:
https://github.com/openstack/glance/blob/97dac0f3800ad9768e5c118656c6bbbf55fc866d/glance/location.py#L106
Maybe before the call is made, if backend == None, set backend to the default backend?
That won't actually set the location metadata, but it will get it past this call.
The workaround is to add the backend to the location metadata as part of the PATCH.
I have an http store with id == 'Wilma'.
This patch works as expected:
[
{
"op": "add",
"path": "/locations/-",
"value": {"url": "https://review.openstack.org/static/title.svg?e=6b20e64d6472edfb0e38b30442683e8a",
"metadata": {"backend": "Wilma"},
"validation_data": {"checksum": "24c3834b2a43a823c181a82b9727d687",
"os_hash_algo": "sha512",
"os_hash_value": "a8ddd76c5b222c772584bdc6099887cdbd9d7fbc48bc5acaa07dcd8a3ba36a32b22f502ea4789a792a66580ef316d929d0506ec3df900d44d9bd51f97ea90ae2"
}
}
}
]
(Note: you have to do this same workaround to get this to work in the glanceclient on Iain's current patch when multiple backends are enabled in Glance.)
Maybe this behavior is fine, that is, don't guess what store to use when
multiple backends are enabled, but instead reject the request and make
the user state it explicitly. But in that case we need a much better
error message -- "Invalid location" is pretty vague.
** Affects: glance
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1802587
Title:
With multiple backends enabled, adding a location does not default to
default store
Status in Glance:
New
Bug description:
I have multiple backends set up in an S-1 devstack and make this call:
data.json:
[
{
"op": "add",
"path": "/locations/-",
"value": {"url": "https://review.openstack.org/static/title.svg?e=6b20e64d6472edfb0e38b30442683e8a",
"metadata": {},
"validation_data": {"checksum": "24c3834b2a43a823c181a82b9727d687",
"os_hash_algo": "sha512",
"os_hash_value": "a8ddd76c5b222c772584bdc6099887cdbd9d7fbc48bc5acaa07dcd8a3ba36a32b22f502ea4789a792a66580ef316d929d0506ec3df900d44d9bd51f97ea90ae2"
}
}
}
]
demo! curl -X PATCH \
-H "x-auth-token: $TK" \
-H "Content-type: application/openstack-images-v2.1-json-patch" \
-d @data.json \
"$OS_IMAGE_URL/v2/images/$IMG"
What I expect: the default store will be used.
What happens:
<html>
<head>
<title>400 Bad Request</title>
</head>
<body>
<h1>400 Bad Request</h1>
Invalid location<br /><br />
</body>
Here's the error that's occurring. (Line numbers may be off slightly from my hacking.)
Traceback (most recent call last):
File "/opt/stack/glance/glance/location.py", line 108, in _check_location_uri
uri, backend, context=context)
File "/opt/stack/glance_store/glance_store/multi_backend.py", line 486, in get_size_from_uri_and_backend
uri, backend, conf=CONF)
File "/opt/stack/glance_store/glance_store/location.py", line 109, in get_location_from_uri_and_backend
raise exceptions.UnknownScheme(scheme=backend)
UnknownScheme: Unknown scheme 'None' found in URI
The call to store_api.get_size_from_uri_and_backend() is being made with:
uri: https://review.openstack.org/static/title.svg?e=6b20e64d6472edfb0e38b30442683e8a
backend: None
The call is happening here:
https://github.com/openstack/glance/blob/97dac0f3800ad9768e5c118656c6bbbf55fc866d/glance/location.py#L106
Maybe before the call is made, if backend == None, set backend to the default backend?
That won't actually set the location metadata, but it will get it past this call.
The workaround is to add the backend to the location metadata as part of the PATCH.
I have an http store with id == 'Wilma'.
This patch works as expected:
[
{
"op": "add",
"path": "/locations/-",
"value": {"url": "https://review.openstack.org/static/title.svg?e=6b20e64d6472edfb0e38b30442683e8a",
"metadata": {"backend": "Wilma"},
"validation_data": {"checksum": "24c3834b2a43a823c181a82b9727d687",
"os_hash_algo": "sha512",
"os_hash_value": "a8ddd76c5b222c772584bdc6099887cdbd9d7fbc48bc5acaa07dcd8a3ba36a32b22f502ea4789a792a66580ef316d929d0506ec3df900d44d9bd51f97ea90ae2"
}
}
}
]
(Note: you have to do this same workaround to get this to work in the glanceclient on Iain's current patch when multiple backends are enabled in Glance.)
Maybe this behavior is fine, that is, don't guess what store to use
when multiple backends are enabled, but instead reject the request and
make the user state it explicitly. But in that case we need a much
better error message -- "Invalid location" is pretty vague.
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1802587/+subscriptions
Follow ups