Wikitech has long been a weird special-case wiki, receiving only partial attention from SREs and causing intermittent problems to different teams as different edge cases appear. Wikitech also suffers from being a random jumble of tools, serving several unrelated purposes that are best solved elsewhere.
Here are the things wikitech does, today:
- Host some of WMF’s technical documentation
- Ensure that that documentation is available in case of a datacenter disaster (via wikitech-static replica)
- Provide a web UI for creation and editing of developer accounts
- Provide a web UI for management of cloud-vps and toolforge ssh keys
- Provide an API endpoint for validation of 2fa auth for developer accounts, currently used by striker and horizon
Ideally, Bitu and IDM will address tasks 3-5. Here are some potential futures for the content that is now on Wikitech, addressing cases 1 and 2. These could be end states, or steps along the road to the ideal end state.
All of the following options except for B require functions 3-5 to be moved to idm+bitu before transitional work can begin.
A: SUL wiki hosted on wikikube. This is generally regarded as the ideal end state, but we probably can’t skip straight to his case; we likely need to pass through B, C, or D on the way.
- Pro (long-term): Wikitech account management is subsumed into existing SUL management
- Pro (long-term): Wiki management becomes a trivial subcase of existing wiki hosting
- Con (transitional): Requires reconciling existing wikitech accounts with totally divergent SUL accounts
B: Fishbowl wiki hosted on wikikube, accounts in ldap. This option could be a final state OR a temporary state on the way to the SUL option.
- Pro (long-term): Wiki management becomes subcase of existing wiki hosting
- Pro (transitional): No need to reconcile SUL accounts with wikitech accounts
- Pro (transitional): This wiki could still support use cases 3-5, decoupling us from blockers in bitu and idm.
- Con (transitional): Wikikube SREs are alternately willing/unwilling to entertain this solution.
- Con (long-term): Allowing r/w ldap access from wikitech/wikikube may continue to introduce surprising edge cases for product maintenance.
- Con (long-term): We’d need to continue to maintain and support mediawiki ldap extensions in the wikikube cluster
C: Fishbowl wiki hosted on wikikube, accounts in mariadb. This option could be a final state OR a temporary state on the way to the SUL option.
- Pro (long-term): Wiki management becomes a trivial subcase of existing wiki hosting
- Pro (transitional): No need to reconcile SUL accounts with wikitech accounts
- Con (transitional): Would require password resets for every wikitech account
- Con (long term): Everyone presently with two accounts(SUL and developer) would have three accounts: SUL, developer, wikitech.
- Con (long term): Management of this new account type would require ongoing administrative work. E.g. someone would need to either approve new accounts, or detect and remove spammer accounts.
D: SUL wiki hosted on existing WMCS hardware. This option only really makes sense as a temporary state on the way to the SUL + wikikube option.
- Pro (long-term): Wikitech account management is subsumed into existing SUL management
- Con (transitional): Requires reconciling existing wikitech accounts with totally divergent SUL accounts
- Con (long-term): Requires exposing the centralauth database (and all the other SUL wiki databases) to the WMCS hardware
E: Wikitech is abolished, content migrated to a different existing wiki (e.g. mediawiki.org). This option may be impossible without violating copyrights of existing content
- Pro (long-term): Nothing new to maintain or manage, ever!
- Con (transitional): Migrating the content while preserving accurate history and attribution may be difficult or impossible.
- Con (long-term): Existing value (if any) of the separation between Wikitech and Mediawiki.org would be lost. E.g. it might be less obvious which subset of the content to host on wikitech-static.
- Con (long-term): WMF staff control of the wiki hosting WMF operational docs is lost and staff will need to earn authority via community participation
- Con (long-term): Further muddies the purpose of mediawiki.org by adding two new documentation use cases of WMF operational docs and Cloud VPS/Toolforge support docs.