placement keystonemiddleware_authtoken ignores OS_PLACEMENT_CONFIG_DIR

Bug #1734491 reported by Chris Dent on 2017-11-25
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Chris Dent

Bug Description

In placement master, late November 2017, the file is responsible for building the WSGI middleware stack, including loading the keystonemiddleware.

           auth_middleware = auth_token.filter_factory(
            {}, oslo_config_project=project_name)

This mode of loading means that the middleware itself is responsible for finding and reading the project conf file (nova.conf for now).

Whereas the general the conf loading done in is aware of an OS_PLACEMENT_CONFIG_DIR env, the filter_factory loading above is not.

This can lead to some pretty confusing situations where custom config, for things like the database, from custom locations are visible in the placement service, but authtoken config is not.

Only after pulling all hair from head does it become clear what's happening.

So we should fix that. It _may_ be as simple as adding similar file handling as used in, but it's not clear if the arg will get passed through. Further experimentation required.

Set the status to "In-Progress" because this report has an assignee.

Changed in nova:
status: New → In Progress
Chris Dent (cdent) on 2017-12-04
tags: added: pike-backport-potential
melanie witt (melwitt) on 2017-12-06
Changed in nova:
importance: Undecided → Low

Submitter: Zuul
Branch: master

commit b2e02f5147d79eaf4fd935507590fec5a0ba7ccf
Author: Chris Dent <email address hidden>
Date: Tue Nov 28 12:44:44 2017 +0000

    [placement] re-use existing conf with auth token middleware

    If 'oslo_config_project' is passed to the auth_token filter
    factory, the mechanism in nova.api.openstack.placement.wsgi for
    overriding the location of the configuration file is ignored
    meaning that expected custom configuration is also ignored.

    Instead pass the already existing conf with 'olso_config_config'

    The unit test in shows that the configuration
    settings get passed to the middleware and used by testing the
    value of the 'WWW-Authenticate' header (which comes from a few
    different configuration settings, of which is 'auth_uri') in
    a response generated by the placement WSGI application.
    The same test against the previous code fails.

    Change-Id: I61d20c5d19797f7e66648c7864a632f3328be8ce
    Closes-Bug: #1734491

Changed in nova:
status: In Progress → Fix Released

This issue was fixed in the openstack/nova development milestone.

Submitter: Zuul
Branch: master

commit fc71fb891e55b2a870444650ed718c897c096edc
Author: Chris Dent <email address hidden>
Date: Fri Dec 8 14:40:59 2017 +0000

    [placement] annotate loadapp as public interface

    When Change-Id: I61d20c5d19797f7e66648c7864a632f3328be8ce was under
    review there were questions about why the interface on deploy() was not
    changed to remove the no-longer used project_name kwarg. I mistakenly
    asserted that this was because it was a public interface for building
    a Placement WSGI application. That's not the case. loadapp() is the
    public interface.

    This change annotates loadapp() as such, and removes the unused arg

    Change-Id: I9f3d03d964654ab1b9515ecd6fe35c518d5f496a
    Related-Bug: #1734491

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

Other bug subscribers