Change Details

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 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.

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.

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.