Docs might be wrong for configuring keystone access params

Bug #1931875 reported by Dan Smith
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Confirmed
Undecided
Unassigned
oslo.limit
Fix Released
Undecided
Unassigned

Bug Description

This is a placeholder bug to discuss with Lance when he returns. I believe that while I was trying to get the initial glance unified quota stuff working, we identified some incorrect or missing bits of the setup and configuration noted here:

https://docs.openstack.org/oslo.limit/latest/user/usage.html#configuration

which ended up different in the actually-working devstack support:

https://review.opendev.org/c/openstack/devstack/+/788056/6/lib/glance

Revision history for this message
Jneeee (jnl2) wrote :

I found this bug recently too: the endpoint_id must be supplied otherwise enforce quota will fail.
I think we can get endpoint_id from keystone if the service name and service type are provided. I will push a commit relate to this.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to oslo.limit (master)

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/oslo.limit/+/865943

Changed in oslo.limit:
status: New → In Progress
Jneeee (jnl2)
Changed in oslo.limit:
assignee: nobody → Jneeee (jnl2)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/oslo.limit/+/914783

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

Reviewed: https://review.opendev.org/c/openstack/oslo.limit/+/914783
Committed: https://opendev.org/openstack/oslo.limit/commit/9575a24796e019fd66f1bb1a5ef0bcbfc167351a
Submitter: "Zuul (22348)"
Branch: master

commit 9575a24796e019fd66f1bb1a5ef0bcbfc167351a
Author: Takashi Kajinami <email address hidden>
Date: Sat Mar 30 22:25:14 2024 +0900

    Query endpoint id from keystone

    Endpoint id is not predictable so users can't configure the endpoint_id
    option until keystone endpoints are created. This requires redundant
    steps in deployment. For example both keystone and glance are run by
    httpd + mod_wsgi then you first have to deploy keystone and then create
    glance endpoints, until you can install glance and restart httpd.

    This introduces a few new options to look up the target endpoint from
    Keystone. All these options accept predictable values.

    Closes-bug: #1931875
    Change-Id: I0411d4aa6abd86cb38bf3c1999f2bae213983078

Changed in oslo.limit:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on oslo.limit (master)

Change abandoned by "Takashi Kajinami <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/oslo.limit/+/865943
Reason: This was implemented by https://review.opendev.org/c/openstack/oslo.limit/+/914783

Changed in oslo.limit:
assignee: Jneeee (jnl2) → nobody
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/oslo.limit 2.6.0

This issue was fixed in the openstack/oslo.limit 2.6.0 release.

Revision history for this message
Maximilian Stinsky (mstinsky) wrote :

Any chance to get this backported?
Before this feature it is very impractical for a deployment to configure oslo.limits.

Revision history for this message
melanie witt (melwitt) wrote :

I have added Nova to this bug to track updating Nova to consume the endpoint discovery functionality in oslo.limit 2.6.0

Changed in nova:
status: New → Confirmed
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.