Glance v1 API makes requests to the v2 registry

Bug #1516706 reported by Stuart McLaren
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Glance
Fix Released
Medium
Dharini Chandrasekar

Bug Description

If I configure storage quotas with:

user_storage_quota = 6

And I enable the v2 registry:

data_api = glance.db.registry.api

Then a v1 image create:

$ glance --os-image-api-version 1 image-create --name x3 --disk-format raw --container-format bare --file /etc/fstab
413 Request Entity Too Large: Denying attempt to upload image because it exceeds the quota: The size of the data 145 will exceed the limit. -5794 bytes remaining. (HTTP 413)

Generates the following request to the v2 registry:

POST /rpc HTTP/1.1.
Host: 0.0.0.0:9191.
Accept-Encoding: identity.
Content-Length: 151.
x-auth-token: bee70651417c474dac02d6e4e4a5b9fc.
.
[{"command": "user_get_storage_usage", "kwargs": {"image_id": "c4252759-9c2f-4858-b23a-1b4c87f7b155", "owner_id": "411423405e10431fb9c47ac5b2446557"}}]

Amusingly, this works.

But I'm pretty sure it's not what we intended.

wangxiyuan (wangxiyuan)
Changed in glance:
assignee: nobody → wangxiyuan (wangxiyuan)
Revision history for this message
wangxiyuan (wangxiyuan) wrote :

I tested it in my env. When use glance.db.registry.api in glance-api.conf, api will sent a rpc message to registry. Then registry use db.sqlalchemy.api to get the data from db.

So, Stuart, what the problem? Could you describe more detail?

Revision history for this message
Stuart McLaren (stuart-mclaren) wrote :

My understanding is that

* the v1 Glance API code should only every make calls to the v1 Glance registry
* the v2 Glance API code should only ever make calls to the v2 Glance registry

What we are seeing is

* the v1 Glance API code making a call to the v2 Glance registry (ie /rpc).

Revision history for this message
wangxiyuan (wangxiyuan) wrote :

As I know, the v2 Glance API talks to DB directly, and glance-registry are not used anymore with v2 Glance API. That means we can run Glance without glance-registry well when use v2 API.

Am I missing something? Please let me know.

wangxiyuan (wangxiyuan)
Changed in glance:
assignee: wangxiyuan (wangxiyuan) → nobody
Changed in glance:
assignee: nobody → Dharini Chandrasekar (dharini-chandrasekar)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to glance (master)

Fix proposed to branch: master
Review: https://review.openstack.org/416766

Changed in glance:
status: New → In Progress
Changed in glance:
importance: Undecided → Medium
Revision history for this message
Nikhil Komawar (nikhil-komawar) wrote :

Some more clarification on the bug:

With the current defaults, v1 registry will be invoked irrespective of the API enabled (v1 or v2). The operator needs to be explicit about which registry they need to enable even if they have chosen to operator a specific API.

Revision history for this message
Nikhil Komawar (nikhil-komawar) wrote :

As a part of the solution, as a courtesy informative measure it may make sense to LOG.warn when a operator chooses to enable incorrect API and registry combination (v1 API with v2 registry and visa versa). The services should fail to start with a good warning.

tags: added: ocata-rc-potential
Ian Cordasco (icordasc)
Changed in glance:
milestone: none → pike-1
Revision history for this message
Hemanth Makkapati (hemanth-makkapati) wrote :

I don't think the issue here is a mere misconfiguration. Agreed that it shows up only when both v1 and v2 are enabled. And, this is especially evident when v2 is configured to run with registry, which is the default setting.

When v2 registry is enabled, we need the 'data_api' config to be set to 'glance.db.registry.api'. This is where things crossover from v1 to v2.

Looks like v1 uses the data_api for certain operations during image upload.
https://github.com/openstack/glance/blob/48ee8ef4793ed40397613193f09872f474c11abe/glance/api/v1/upload_utils.py#L87

And, at a couple of other places, too.

https://github.com/openstack/glance/blob/48ee8ef4793ed40397613193f09872f474c11abe/glance/common/store_utils.py#L51-L52
https://github.com/openstack/glance/blob/48ee8ef4793ed40397613193f09872f474c11abe/glance/common/store_utils.py#L87-L91

V1 uses the same config in the assumption that it is talking to the database directly. It is actually talking to v2 registry, which in turn talks to the database. This, I think, is the root-cause here.

I see two concerns here:
* The same config 'data_api' is used in two versions with different interpretations.
* V1 is actually talking to the database directly, which I thought was prohibited.

Finally, if I understand correctly, I don't think just adding a validation around 'enable_v1_api', 'enable_v1_registry', 'enable_v2_api' and 'enable_v2_registry' will solve this issue.

Thoughts?

Revision history for this message
Nikhil Komawar (nikhil-komawar) wrote :

Great findings Hemanth. I missed those parts of v1 in case of explicit use.

Revision history for this message
Dharini Chandrasekar (dharini-chandrasekar) wrote :

Hi Hemanth. Thanks a lot for the comment.

So the issue is the call to db.get_api().
v1 api ends up either talking directly to db (which should not be the case) or it ends up talking to registry v2 client (which again is not what it should be doing) cos of whatever has been given to data_api.
So basically the 5 opts enable_v1_api, enable_v2_api, enable_v2_api, enable_v2_registry and data_api are not working well together.

I think we should be making a decision in db.get_api() or after the call to db.get_api() as to whether return 'data_api' as it is (we want this when v2 reg is making the call) or if we need to direct it to v1 registry client which will then route to db.
In brief, a couple of additional checks whenever db.get_api is called from either v1/images or v2/images.

And regarding the proposed change , I agree that it will not let registry to serve all alone. But I also feel that we need to have a warning issues at the least that v1 registry is running alone without v1 api.

Let me know what you think.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Fix proposed to branch: master
Review: https://review.openstack.org/431709

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on glance (master)

Change abandoned by Dharini Chandrasekar (<email address hidden>) on branch: master
Review: https://review.openstack.org/416766
Reason: Abandoning this change in favor of Ifef36859b3f7692769a6991364b6063c9f7cc451

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to glance (master)

Reviewed: https://review.openstack.org/431709
Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=c74e6bb8ddee8ad1ad2479f3fcfd8396dedef55b
Submitter: Jenkins
Branch: master

commit c74e6bb8ddee8ad1ad2479f3fcfd8396dedef55b
Author: Dharini Chandrasekar <email address hidden>
Date: Thu Feb 9 18:34:02 2017 +0000

    Prevent v1_api from making requests to v2_registry

    In glance v2, when one opts to use v2_registry, it is required that
    'data_api' is set to 'glance.db.registry.api'. This is returned by
    method 'get_api()' which currently simply returns whatever is provided
    to 'data_api'. This is suitable for v2. But when using v1, this same
    method is used to fetch the db api. This returns 'glance.db.registry.api'
    which inturn relies on the registry rpc client (v2).
    To prevent this, this patch proposes to change what get_api()
    will return based on whether it is serving v1 api or v2 api.

    Change-Id: Ifef36859b3f7692769a6991364b6063c9f7cc451
    Closes-Bug: 1516706

Changed in glance:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/glance 15.0.0.0rc1

This issue was fixed in the openstack/glance 15.0.0.0rc1 release candidate.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.