Handle Backend class imports gracefully
The S3 Backend needs to use boto. While nova uses boto throughout, none of glance uses it at all. It would probably be best that people who use other backends aren't required to also import boto, if only so that we have the precedent that when someone writes JoesWeirdAssBackend clients who don't use JoesWeirdAssBackend aren't required to use JoesWeirdAssBac
The first is to put the imports into the backend class definition, either by adding an __init__ method and instantiating backends or by throwing it into a method called by the @classmethods. The other way is to make glance.
A third way is to import a faked library when one doesn't exist, which is also ugly, but could be used effectively in the test suite.
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Medium
- Drafter:
- Christopher MacGown
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Superseded
- Series goal:
- Declined for bexar
- Implementation:
-
Informational
- Milestone target:
- None
- Started by
- Completed by
- Thierry Carrez
Whiteboard
So, there are actually two different problems to solve with this blueprint:
1) How to gracefully load (and handle import problems) for libraries that:
a) We do want to require (like SQLAlchemy)
b) We don't want to require (like Boto)
2) How to gracefully test ALL backends even when the real library does not happen to be installed on the test machine
For #2, using pymox and stubout would be Jay's recommendation (we do it for Swift already...)
pvo - will you be discussing this at the summit, since Chris is not attending?
I'm going to probably suggest that RickH talk about this but he doesn't know that yet. : ) --pvo
Is this still a valid blueprint? I think we solved this at the summit. Right? --pvo
We solved it at the summit insofar as we decided to use the dynamic import stuff in common. The swift backend needs to be written to make use of it though. --chris
See https:/
