Now that we have been using netbox for a while, are we ready to decom racktables or does it still need to stay for some reason?
Background is that it is one of the 3 apps on miscweb[12]001 and we want to upgrade that to Buster sometime in 2020.
It shares a server with scholarships (T243037) and iegreview. Maybe all 3 are not used anymore.
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| racktables: fix php.ini path for buster support | operations/puppet | production | +6 -1 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Stalled | None | T302086 Set scap minimum python version to 3.7 | |||
| Resolved | None | T247045 Migrate all of production metal and VMs to Buster or later | |||
| Resolved | Dzahn | T247648 miscweb1001/2001 - upgrade to buster or decom | |||
| Resolved | Dzahn | T247646 migrate racktables to a buster VM (was: decom racktables?) |
Good question!
I'd prefer to keep it until approximately 5 years (our server lifecycle timespan) since the migration, for historical queries and in case one of the data migration steps failed.
We migrated to Netbox in September 2018, so that date +5Y would place Racktables' demise in September 2023. According to our OS policy, we will support buster for 4 years since its release (July 2019), so that puts the buster deprecation date in July 2023. That's close enough and means that proceeding with a buster upgrade now -if possible- would keep that in a supported base system, and be the last one for this service.
If there are security concerns (vulnerabilities etc.), restricting access via Apache basic auth to only a handful of individuals (DC Ops + myself) is acceptable.
All that said, if the upgrade or maintenance burden becomes too high (e.g. incompatibilities with PHP 7.3), happy to revisit that decision. A static copy (like what we did with Bugzilla) could work too, but I fear it's going to be more work than just maintaining it as-is. Unfortunately, Racktables' database schema is a bit of a mess so relying on an SQL dump is not very meaningful...
Hope this all makes sense :)
I think deploying it on Buster will be unproblematic, the current host is already on Stretch, so the big incompatibilities between PHP 5 and 7 are already addressed. Racktables is also still maintained (last maintenance release in November 2019)
Faidon wrote:
Hope this all makes sense :)
Moritz wrote:
Buster will be unproblematic
Yes, it does. Thanks for detailed responses. I'll try to move it to another buster VM first then. Renamed the ticket accordingly.
Change 583899 had a related patch set uploaded (by Dzahn; owner: Dzahn):
[operations/puppet@production] racktables: fix php.ini path for buster support
Change 583899 merged by Dzahn:
[operations/puppet@production] racktables: fix php.ini path for buster support
Mentioned in SAL (#wikimedia-operations) [2020-03-27T10:45:47Z] <mutante> miscweb1002 - upload and unpack RackTables-0.21.4 (T247646 T247648)
racktables has now been migrated to miscweb1002.eqiad.wmnet on buster. The stretch VM has been decom'ed.
The racktables version itself has been upgraded to 0.21.4 and the installer/upgrade script changed DB tables. Manuel gave the mysql user temp. SUPER privileges so that i was able to run it.
A mysqldump file from before the upgrade and old app files have been kept on miscweb1002 in /root/racktables/ just in case.