placement inadvertently imports many python modules it does not need

Bug #1743120 reported by Chris Dent on 2018-01-13
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Chris Dent

Bug Description

The placement WSGI app has its own WSGI framework and is the only script/binary that placement uses. From the outset, it has been intended that a deployment could run multiple placement servers, distributed across multiple hosts/pods/whatever, with some form of load balancing proxy in front.

In that model, it would be ideal for the app to require as few python module as possible, and have as small a footprint, at least starting up, as possible.

Currently, that's not the case, for two reasons:

* Placement makes use of the FaultWrapper WSGI middleware to catch unexpected exceptions and turn them into status 500 HTTP responses. FaultWrapper imports nova.utils and nova.utils imports a lot of stuff.

* Placement is within the nova/api/openstack package hierarchy and nova/api/openstack/ contains active code and imports which placement does not need.

These problems can be addressed:

* FaultWrapper is overkill for the placement WSGI app. FaultWrapper is capable of decoding a variety of exceptions into a variety of status responses. This is not required by placement. The only exceptions that can make it to FaultWrapper in placement are those that would result in a 500. A simpler middleware can handle this.

* nova/api/openstack/ should be emptied, the contents moved to a file which is explicitly imported by those modules that actually want it. Presumably, this could also provide an avenue for lightening the metadata API.

Note that this is not the only case of inadvertent imports, but is one of the main vectors. Others will be identified and additional bugs created.

Fix proposed to branch: master

Changed in nova:
status: Triaged → In Progress
Chris Dent (cdent) wrote :

This going to be fairly complicated to make much headway on, unless the resource_provider objects are moved out from under nova/objects. there registers all those objects, each of which imports things from all over the nova hierarchy. One notable example are the ec2 objects which import nova/api/ec2/ec2utils which imports dogpile so it can memoize some operations (are they ever called?).

Also, nova/ imports oslo_service and eventlet, neither of which placement wants to see. This could perhaps be moved back to nova/cmd and wherever else is actually required.

Chris Dent (cdent) wrote :

I messed up the bug reference, so there's also:

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

Other bug subscribers