Page MenuHomePhabricator

Request creation of wlmitaly VPS project
Closed, DeclinedPublic


Project Name: wlmitaly

Wikitech Usernames of requestors: Ferdi2005

Purpose: These are a tools to make stats about Wiki Loves Monuments Italy project and a monument finder for Italy with geolocalization.

Brief description:

These tools can improve organization quality of WLM in Italy with more detailed statistics for our subregions and local contests for local organizers (like Apulia, Latium ecc.)

These are the webapps, written by me in Ruby On Rails, so I can’t deploy them to toolserver (I also asked for help with previous tasks) because of the old ruby version for it. I don’t need a higher disk-quota.

They’re living on and but I am a volounteer and I’d prefer to close my VPS and move them to WMF CloudVPS

I need to install and can install Ruby and NGINX+Passenger (+ some gems).

How soon you are hoping this can be fulfilled: ASAP this month I hope, but I know we are in a situation of emergence, so I can wait until August with no problems.

Event Timeline

bd808 added subscribers: MusikAnimal, bd808.

because of the old ruby version for it

The Kubernetes cluster in Toolforge has a container with Ruby 2.5.5p157. Is that too old for your code as well? 2.5.5 is the latest version packaged for a stable Debian version. 2.7 is in Debian testing (bullseye), but I don't expect Toolforge to have anything based on Debian Bullseye for quite a while.

We could look into producing a Ruby 2.7 image for Toolforge using rvm or rbenv. That's functionally what you will have to do on any Cloud VPS instance you may create if 2.5.5 is too old for your needs as Debian Buster is the newest supported base OS in our environment.

(I also asked for help with previous tasks)

T216463: itwikiarticlebot ruby Kubernetes pod stuck in CrashLoopBackOff is the only one that I have found. You did not seem very interested in actually getting that one solved?

I can understand your frustration with learning to use the features provided by Toolforge in the Ruby language. I think we generally have reasonable support for PHP and Python3. The story is often not as good for Ruby, Perl, $OTHER as there have been fewer folks working in these languages and probably more importantly fewer Toolforge admins who work in them on a regular basis. I know @MusikAnimal has had complaints desires for us to give better support to Ruby in the past as well. I think this is a fixable problem, but it will require active work in cooperation between Toolforge admins and tool maintainers working in these less used in Toolforge languages to make things better. T141388: Add a easy way to run a ruby webservice on tools would be a good place to figure out what is actually needed/usable and then get that deployed for others to benefit from.

For Python projects we settled on a convention over configuration setup that has seemed to work out ok. We use uWSGI as the container for running Python webservices and the convention of $HOME/www/python/src/ being the system entrypoint. We also have a convention of $HOME/www/python/venv as the location for user managed libraries in Python. The same uWSGI can at least in theory serve as a Rack application container. I have no idea if it is actually a "good" container for ruby/Rack apps however.

@bd808 I'm really sorry, but I don't really have capabilities (or enough time) to learn Kubernetes and how to make my rails apps working with it, especially if I have to work on Wiki Loves Monuments in my region and other wiki projects.
Ruby 2.5.5 is good for my application, but I have to make my app work with Kubernetes, while ruby -v on Toolforge gives a way older version (at least the last time I tried). A Rails app is way more complex than a Ruby script and I think that if I couldn't get a simple and little working Ruby scriptm I can't get a Rails app working with Kubernetes.

I can obviously help you testing solutions to make Rails (and Ruby in general) working Toolserver, but I don't think I am enough capable
I appreciate your help and I can understand if you can't give me a CloudVPS instance because there's anyway a way to install Ruby apps on Toolservers, I'll find anyway a solution to host the applications.

I ended up using the Ruby on the gridengine, which indeed is a bit old (2.3.3) but it works great for my bots. If you want to attempt installing a newer Ruby you could, you just have to put it in your home directory. Similar issue with gems; I installed those one by one with gem install 'foo' --user-install, since Bundler apparently wants them outside the home directory.

As for the webservice and/or cron, try putting whatever commands you need in a wrapper script (, and make sure it adds dependencies to the PATH:

export PATH="$HOME/.rbenv/bin:$PATH"
rbenv local 2.5.5
ruby start.rb  # Or however you start your webservice

If you're not using rbenv (maybe you built the Ruby from source), you might need to export the gem location to PATH too, e.g.

export PATH="$HOME/.gem/ruby/2.5.0/bin:$PATH"

Did you try it with Rails @MusikAnimal? I think it's quite more complex (and must use bundler 😔)

I'll try anyway this for my bots, thanks, this is so useful!

No I have never attempted Rails, though I did have a Sinatra app at one point. That was in the very early days of Tool Labs, and it was definitely not a breeze to set up. But, I did finally get it working with a Unicorn server.

Apparently one of the few Rubyists on Toolforge is successfully using bundler (T141388#6057429), so I guess it is possible! To be honest, I haven't tried in ages. I just found a solution that worked for my bots and stuck with it. I assume you will need to use --user-install to install bundler itself, though.

This request was discussed in the 2020-04-15 WMCS team meeting. We are recommending Toolforge rather than a VPS project. We will prioritize work on T141388: Add a easy way to run a ruby webservice on tools to make using Toolforge easier for folks who want to run Ruby apps which follow the rack standard and use bundler for gem management. We believe that this will make experiences better for many people in the Wikimedia technical community.

Change 589086 had a related patch set uploaded (by Bstorm; owner: Bstorm):
[operations/docker-images/toollabs-images@master] rails: ruby needs nodejs and bundler to be useful

Change 589086 merged by jenkins-bot:
[operations/docker-images/toollabs-images@master] rails: ruby needs nodejs and bundler to be useful

Mentioned in SAL (#wikimedia-cloud) [2020-04-15T23:20:55Z] <bd808> Building ruby25-sssd/base and children (T141388, T250118)

@Ferdi2005 thanks to a lot of work by @Bstorm, T141388: Add a easy way to run a ruby webservice on tools is workable now. She and I were both able to setup "hello world" rails apps using the new container. We need to write up some docs, but here's a rough dump of what I did to take from nothing to a running app:

$ cat <<EOF >service.template
backend: kubernetes
type: ruby25
canonical: true
$ mkdir -p www/ruby/{src,vendor}
$ webservice shell
:# Everything until the `exit` below happens in the ruby25 container started by `webservice shell`
$ cd www/ruby/src
$ bundle init
$ vim Gemfile
$ bundle install --path $HOME/www/ruby/vendor
$ bundle exec rails new .
$ bundle exec rails generate controller pages
$ vim app/controllers/pages_controller.rb
$ vim app/views/pages/home.html.erb
$ RAILS_ENV=production bundle exec rails assets:precompile
$ exit
:# Exited the ruby25 container and now back on the bastion directly
$ cat <<EOF >$HOME/
cd $HOME/www/ruby/src
exec bundle exec rails server -p 8000 -e production
$ chmod a+x $HOME/
$ webservice ruby25 start -- $HOME/
:# $HOME/service.template has the ruby25 type in it, but `webservice` gets confused when using extra args if you leave it off

I would be happy to work with you here and/or in the #wikimedia-cloud IRC channel to debug issues you might have trying to get your apps running as tools.

bd808 changed the task status from Open to Stalled.Jul 21 2020, 10:05 PM
bd808 lowered the priority of this task from High to Medium.
bd808 removed a project: Patch-For-Review.

@Ferdi2005 just pinging again on this. Please let us know if there is anything we can do to help migrate your services.

@Ferdi2005: Any news here? Is this still wanted?

Unfortunately closing this Phabricator task as no further information has been provided in the last eight months.

@Ferdi2005: If this is still wanted, then please set the status of this task back to "Open" via the Add Action...Change Status dropdown. Thanks!