Page MenuHomePhabricator

Migrate dtcheck from Toolforge GridEngine to Toolforge Kubernetes
Closed, ResolvedPublic

Description

Kindly migrate your tool(https://grid-deprecation.toolforge.org/t/dtcheck) from Toolforge GridEngine to Toolforge Kubernetes.

Toolforge GridEngine is getting deprecated.
See: https://techblog.wikimedia.org/2022/03/14/toolforge-and-grid-engine/

Please note that a volunteer may perform this migration if this has not been done after some time.
If you have already migrated this tool, kindly mark this as resolved.

If you would rather shut down this tool, kindly do so and mark this as resolved.

Useful Resources:
Migrating Jobs from GridEngine to Kubernetes
https://wikitech.wikimedia.org/wiki/Help:Toolforge/Jobs_framework#Grid_Engine_migration
Migrating Web Services from GridEngine to Kubernetes
https://wikitech.wikimedia.org/wiki/News/Toolforge_Stretch_deprecation#Move_a_grid_engine_webservice
Python
https://wikitech.wikimedia.org/wiki/News/Toolforge_Stretch_deprecation#Rebuild_virtualenv_for_python_users

Related Objects

View Standalone Graph
This task is connected to more than 200 other tasks. Only direct parents and subtasks are shown here. Use View Standalone Graph to show more of the graph.

Event Timeline

I am unable to migrate the tool, because there is no Kubernetes backend that allows both serving static HTML files using lighttpd and running CGI scripts using Ruby. I have talked about this problem previously with @bd808 on IRC.

For reference, I current use this command: https://github.com/MatmaRex/dtcheck/blob/master/webservice-start.sh

My apologies if this ticket comes as a surprise to you. In order to ensure WMCS can provide a stable, secure and supported platform, it’s important we migrate away from GridEngine. I want to assure you that while it is WMCS’s intention to shutdown GridEngine as outlined in the blog post https://techblog.wikimedia.org/2022/03/14/toolforge-and-grid-engine/, a shutdown date for GridEngine has not yet been set. The goal of the migration is to migrate as many tools as possible onto kubernetes and ensure as smooth a transition as possible for everyone. Once the majority of tools have migrated, discussion on a shutdown date is more appropriate. See T314664: Toolforge: Decommission the Grid Engine infrastructure.

As noted in https://techblog.wikimedia.org/2022/03/16/toolforge-gridengine-debian-10-buster-migration/ some use cases are already supported by kubernetes and should be migrated. If your tool can migrate, please do plan a migration. Reach out if you need help or find you are blocked by missing features. Most of all, WMCS is here to support you.

However, it’s possible your tool needs a mixed runtime environment or some other features that aren't yet present in https://techblog.wikimedia.org/2022/03/18/toolforge-jobs-framework/. We’d love to hear of this or any other blocking issues so we can work with you once a migration path is ready. Thanks for your hard work as volunteers and help in this migration!

I reviewed this at the time of the Buster migration, and I can't migrate to Kuberenetes (without rewriting parts of the tool), for reasons in my previous comment.

Thanks for clarifying! I'm not sure if there is a ticket for this yet, or if this is a usecase expected to be resolved by buildpacks or something else. @bd808 can you confirm?

EDIT: Sorry, stale page cache, I didn't see the triage work confirming the tickets and need for buildpacks.

@matmarex we are testing buildpacks now. Do you think an upstream buildpack image will work for you?

There's a quickstart guide here.
We're also looking for feedback from the community on this service.
Kindly take a look and let us know.

I am unable to migrate the tool, because there is no Kubernetes backend that allows both serving static HTML files using lighttpd and running CGI scripts using Ruby. I have talked about this problem previously with @bd808 on IRC.

For reference, I current use this command: https://github.com/MatmaRex/dtcheck/blob/master/webservice-start.sh

@matmarex we are testing buildpacks now. Do you think an upstream buildpack image will work for you?

There's a quickstart guide here.
We're also looking for feedback from the community on this service.
Kindly take a look and let us know.

The initial buildpacks are not going to provide a lighttpd + ruby cgi solution. Really only a very custom buildpack or base image would do that. One currently available solution would be to turn the Ruby cgis into a rack application (or any other pure ruby web app framework) and have that application also serve up the static file content. That could be made to work with either the build system or the ruby27 container.

I've turned off the tool (T341821), so I was able to migrate the remaining static page to Kubernetes webservice.