Ticket #124 (closed task: wontfix)
De-crustify the CellServDB
| Reported by: | broder | Owned by: | broder |
|---|---|---|---|
| Priority: | low | Milestone: | The Distant Future |
| Component: | -- | Keywords: | |
| Cc: | Fixed in version: | ||
| Upstream bug: |
Description
The CellServDB we ship currently is pretty crusty.
There are MIT cells that should stay in in the off chance that the world (i.e. DNS) ends while we're not looking.
There are some non-MIT cells that have AFSDB records, and we should just use those. (Some of these records have no overlap with the servers listed in our CellServDB)
There are some non-MIT cells that still exist, but don't have AFSDB records. We should leave those in the CellServDB, but probably only after considering whether anyone's likely to use them.
There are some non-MIT cells that no longer exist, at least at the particular vlservers in our CellServDB. We should punt those.
Change History
comment:2 Changed 16 years ago by broder
- Priority changed from major to minor
- Type changed from defect to task
comment:4 Changed 13 years ago by jdreed
- Status changed from accepted to closed
- Resolution set to wontfix
This is a daunting task, and ops now regularly updates from GCO. It is not our job to clean up GCO's CellServDB. If there are specific records that are causing people to lose, we could maybe advocate for change. But this ticket is too broad in scope.
Since this apparently wasn't clear, I realize that ops maintains the CellServDB, but its crustiness creates a bad user experience for anyone who tries to access other cells, so I want to take responsibility for figuring out what the necessary cleanups are.