Closed Bug 1109295 Opened 10 years ago Closed 4 years ago

restructure balrog

Categories

(Release Engineering Graveyard :: Applications: Balrog (backend), defect, P3)

defect

Tracking

(Not tracked)

RESOLVED MOVED

People

(Reporter: bhearsum, Unassigned)

Details

(Whiteboard: [lang=python])

Balrog's design has evolved a bit over time, but some rough edges have crept in, particularly around having two applications share the same library. For example, it's very difficult to have global objects (such as a database), because the two applications live in different places (and for awhile, had their own database objects). We can work around that with hacks like in https://github.com/mozilla/balrog/blob/master/auslib/__init__.py, but it's not ideal.

I'm also finding that making caching only happen on the non-admin application as part of bug 671488 to be more complicated because of this.

Peter, you pointed out another issue in https://github.com/mozilla/balrog/pull/18 around needing to addsitedir() our own library. I'm not sure I 100% understand it, so I'll leave it to you to explain.

In any case, it seems like we should be looking towards some sort of structure that allows the common parts of Balrog (db.py, blobs/, maybe AUS.py) to be in an importable library, and the app-specific parts to live in their own place. We'll have to consider what this means for deployment (particularly in cases where we need a synced deployment for admin+non-admin), and there might be better options than this too.

This is low on the priority list given the feature work on the horizon, but it would be nice to do for future maintainability.
This might be easier to fix or be fixed by bug 1313742.
Priority: -- → P3
Whiteboard: [lang=python]
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → MOVED
Product: Release Engineering → Release Engineering Graveyard
You need to log in before you can comment on or make changes to this bug.