- Support VM management on Horizon
- Support DNS management on Horizon
- Support VM Puppet config on Horizon
- Support sudo policy management on Horizon
- Allow projectadmins to change project roles without OSM
- Support project creation/deletion via Horizon
- Support tool creation/management on Striker
- Replace or discard 'service group' functionality on OSM
- Replace LDAP shell account name account creation customization
- Replace/remove Hiera namespace Puppet customization
|Open||None||T189531 All Wikimedia developer services should use single sign-on|
|Open||None||T161859 Make Wikitech an SUL wiki|
|Resolved||PRODUCTION ERROR||• Tgr||T195253 Special:Notifications gives a consistent PHP exception on load ("The trash icon is not registered") for users with OpenStackManager notifications|
|Open||None||T106123 Extensions needing to be removed from Wikimedia wikis|
|Open||None||T161553 Remove OpenStackManager from Wikitech|
|Resolved||Andrew||T150091 Support project creation without OpenStackManager|
|Resolved||Andrew||T159021 Wikitech error when adding users to projects|
|Resolved||Andrew||T162097 Create a Horizon panel for managing per-project sudo policies|
|Resolved||Andrew||T194191 Allow projectadmins to change project roles in Horizon|
|Resolved||MarcoAurelio||T194670 Copy maintenance/attachLdapUser.php to another extension|
|Resolved||Andrew||T194794 Add new users to Bastion group whenever they join a project|
|Open||None||T196171 Developer account creation without OpenStackManager|
- Mentioned In
- T304006: Undeploy DynamicSidebar extension from Wikimedia wikis (only Wikitech)
T269028: WikimediaDebug should avoid confusion on unsupported domains
T123162: OS-EXT-SRV-ATTR:instance_name not set for some instances
T206706: Establish documentation review process for WMCS
T211029: Sort out only one ideal hiera mechanism for Cloud VPS
T195253: Special:Notifications gives a consistent PHP exception on load ("The trash icon is not registered") for users with OpenStackManager notifications
Blog Post: Project-wide sudo policies in Horizon
T161859: Make Wikitech an SUL wiki
T53642: Get rid of SemanticMediaWiki/SRF/SF from wikitech.wikimedia.org
T153821: wikitech.wikimedia.org missing from pageviews API
T87950: Convert OpenStackManager to use extension registration
T98813: Move wikitech (silver) to HHVM
- Mentioned Here
- T113792: Change LDAP cn to something more useful (was Rename "Dzahn" to "Daniel Zahn" in Gerrit)
T53642: Get rid of SemanticMediaWiki/SRF/SF from wikitech.wikimedia.org
Shell accounts and wikitech accounts are only related by accident of implementation. The LDAP accounts could have been just as easily associated with SUL accounts from the beginning. The account creation workflow that has been implemented in https://toolsadmin.wikimedia.org/ starts with an OAuth association to an existing SUL account. LDAP accounts that existed prior to the new workflow can be associated with with a SUL account using that tool as well.
The final step of converting wikitech to a SUL wiki will require another SUL unification as was done for the main wiki farm. There is some fiddling to do at the code/configuration level, but I'm confident that we will be able to change things so that we can rename the wikitech users to match the associated SUL users without causing problems with gerrit and other systems that are currently using the LDAP cn and sn attributes which currently correspond to the on-wiki username for wikitech.
When it comes time to do the unification, we can connect many wiktech accounts to the proper SUL account using email addresses and git/svn commit histories if they have not already been linked using toolsadmin. There will be some currently unknown number of accounts where we have no SUL user to connect to and we will have to come up with a plan for how to deal with them. There is time for that. The elimination of OSM and SMW (T53642) are the first steps that we need to focus on.
A rose by any other name would smell as sweet. We can rename the apache virtual host trivially. This will probably happen at some point as we add additional functionality to Striker (the application currently hosted at the https://toolsadmin.wikimedia.org/ vhost). Note that the functionality you are worried about is currently hosted on a vhost named wikitech.wikimedia.org which honestly sounds like neither Labs nor Tool Labs to me.
If the name of the vhost is the only thing that bothers you I'm pretty sure that the application and plan are on the right track. Please try to think more in the mode of of "What Would You Do If You Weren't Afraid?" and less "Who Moved My Cheese?" when interacting with the development community who are trying to make things better for everyone. (Honestly a horrible book, but a good sentiment.)
Until we rename away from using the 'Labs' term across the suite of product offerings. :)
It's early, but there was some discussion at the Vienna hackathon between @faidon, @Volans, and I and then between @Aklapper and I about the idea of a developer.wikimedia.org application that would be the entry point for creating and managing LDAP accounts. It could also serve as the start of the documentation and discovery portal for people interested in contributing to the technical spaces in the Wikimedia movement as well as consuming the various services that the movement provides for distributing knowledge. This application probably would not include the Toolforge management functionality from Striker, but it would logically take over the basic LDAP account creation and management roles. This is all in a very early preliminary discussion state however, so don't freak out if it sounds like the worst idea you have ever heard and don't get your hopes up yet if it sounds like the greatest thing ever.
I'm still a bit concerned about what complete removal does to new account creation. We need to think through how we are going to handle the fact that without OSM the MediaWiki account creation form will make LDAP accounts, but those accounts will not have a shell name and associated LDAP attributes. I think we can setup a hook or similar that will preserve account creation, but I have not looked into exactly what that would entail. It may be that we actually need a PHP calss or two to properly integrate this with the AuthManager layer.
Striker does know how to create an LDAP record with the proper data to be used by OpenStack, MediaWiki, Gerrit, and Phabricator. That should make it easier for us to replicate the needed data collection and storage for sure.
The user interface there is currently full of talk about Toolforge which will probably be confusing to some people. It will also probably be confusing to have on-wiki account creation disabled if we decide to go that route instead. I think looking at how to either do it all in config with hooks or thinking about a slim extension that only adds the account creation parts would be easiest. I guess the 3rd option is to rip all the things out of OSM except account management. I can't imagine that OSM is really in use anywhere else since we have not heard from angry folks as we took out other functionality.