Closed
Bug 1322159
Opened 8 years ago
Closed 5 years ago
make it easier to see what an update URL was being served at any given moment
Categories
(Release Engineering Graveyard :: Applications: Balrog (backend), defect, P3)
Release Engineering Graveyard
Applications: Balrog (backend)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: bhearsum, Unassigned)
References
Details
(Whiteboard: [lang=python])
One of Balrog's big selling points is the history it provides, which (theoretically) lets us see what was going on at any point in time. In practice, this can be very tricky for a few reasons:
- To effectively see which Rule a request was hitting, you need to see the state of the entire Rules table. The current UI doesn't provide any easy way of doing this.
- Even if you're able to figure out which Rule the request was getting, the underlying Release that it maps to may have changed since the request was made, so you need to rewind the Release it maps to.
- Even once you have _that_, you may need to also rewind the Releases referenced in "partials".
I've been wondering if it might be possible to have an optional timestamp be passed in the query args of the update request. With this, we could retrieve an entire old version of the rules table to parse, retrieve older releases, etc.
Probably needs some thinking about potential security impacts, as it may make downgrade attacks possible. Perhaps we'd want to disable this feature for production domains, but set-up a new domain against the production db with it enabled. *handwave*
Reporter | ||
Comment 1•8 years ago
|
||
bug 1316948 would help here
Priority: -- → P3
Whiteboard: [lang=python]
Reporter | ||
Updated•7 years ago
|
Mentor: bhearsum
Reporter | ||
Updated•7 years ago
|
Mentor: bhearsum
Reporter | ||
Comment 2•7 years ago
|
||
I'm a bit concerned about potential DoS possibilities if we add support for rewinding the Rules to a publicly available domain -- the history tables can be expensive to query and process results from. Between that, and the potential downgrade attack concerns here, I'm leaning more towards putting this on the admin api instead of the public one.
I also realized even after rewinding the tables we may not give a fully accurate answer -- it's possible that the xml construction code may have behaved differently eg: a year ago.
This bug is probably less urgent after we fix bug 1329524, which is easier and safer anyways.
Reporter | ||
Comment 3•5 years ago
|
||
We're not going to fix this in the way described here. https://github.com/mozilla-frontend-infra/balrog-ui/pull/135 will make this a lot better. We can file separate issues for other ideas if/when they come up.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
Updated•5 years ago
|
Product: Release Engineering → Release Engineering Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•