Requirements/constraints from T133252: Create application "Striker" to manage Diffusion repositories for a Tool Labs project:

• The application will be written in Python using the Django framework.
• The final application must be hosted in the Wikimedia production network rather than Labs/Tool Labs in order to provide LDAP authentication.

Wouldn't phabricator be the ideal tool for this job? It already authenticates to ldap and to SUL via oauth and supports associating accounts from both. For people who have logged in to phabricator with both LDAP and SUL, it's already got the association stored on the phab user profile page. I could probably dump that data fairly easily into a format that other tools could use to learn the about the associations.

In T134188#2257462, @mmodell wrote:

Wouldn't phabricator be the ideal tool for this job? It already authenticates to ldap and to SUL via oauth and supports associating accounts from both. For people who have logged in to phabricator with both LDAP and SUL, it's already got the association stored on the phab user profile page. I could probably dump that data fairly easily into a format that other tools could use to learn the about the associations.

Phab does this one piece, yes. The correlation of existing accounts is the first step of many described in the roadmap. Do you think Phabricator would be a good fit for the full roadmap or even specifically the next step of self-service git repository creation and management that is tied to the LDAP group membership data (T133252: Create application "Striker" to manage Diffusion repositories for a Tool Labs project)? @chasemp provided some fairly compelling reasons in T133252#2235001 why Phab was not the right platform for developing that solution. Continuing further down the roadmap the basic app developed here will be expanded to create and manage LDAP user accounts and tool shared accounts. That seems to be even further from the scope of Phabricator and the feature set that the upstream is likely to feel is stable.

@bd808: As long as the tool stays away from unstable / internal phabricator APIs then I don't see it as a big issue. Chase isn't wrong about potential maintenance burdens but it's proportional to how much the tools depends on parts of phabricator that are likely to change significantly.

Since the repository management piece is going to depend on a moving target anyway (the phabricator repository management APIs) I'd say it's already going to have some of the drawbacks, even if it's done via conduit - we will likely have to maintain the conduit API endpoint anyway and keep it up to date with phabricator internal changes.

In T134188#2257518, @mmodell wrote:

@bd808: As long as the tool stays away from unstable / internal phabricator APIs then I don't see it as a big issue. Chase isn't wrong about potential maintenance burdens but it's proportional to how much the tools depends on parts of phabricator that are likely to change significantly.

Using Phabricator as a basis of the applications described in this ticket and T133252 would solve two potential issues from T133252:

• Associating LDAP, SUL and Phabricator user accounts
• Conduit API access being potentially insufficient for Diffusion repo management.

It would not however provide any direct benefits for other challenges on the roadmap:

• LDAP account creation and management that is compatible with all of the existing LDAP consumers (wikitech, Horizon/Nova, Labs instances, Phabricator, Gerrit, Apache/Nginx basic auth)
• Tool account creation and management compatible with the existing Tool Labs infrastructure
• Integration with the future PaaS workflow replacement for SGE (start/stop processes, monitor and report on tool health)

Using Phabricator would actively block other goals:

• Code sharing/reuse with the Horizon dashboard
• Code sharing/reuse with cli tools used inside Tool Labs for tool lifecycle management

All of phabricator additionally is subject to rapid change from the upstream project. There is no such thing as a long term stable Phabricator system on which to base this suite of Tool Labs functionality. The amount of tutorials, sample code, ready-made components, etc available for Phabricator development is functional zero in comparison to Django. These aren't knocks against Phabricator as a product, but they are large concerns for me when looking at building a new product that should have at least a 3-5 year lifespan on Wikimedia's production servers.

@bd808: I see that there are a lot of trade-offs. I don't intend to second guess the direction you are headed here.

I guess the complexity of re-creating the pieces solved by phabricator might not outweigh the potential costs. Seems like a close call to me but probably not close enough to spend more time debating it ;)

Anyway my original offer still stands - it would not be much work to create an API method that you can call to fetch the SUL -> LDAP associations from phabricator.