Appropriately :)
Description
Description
Details
Details
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | yuvipanda | T129309 Goal: Allow using k8s instead of GridEngine as a backend for webservices | |||
| Resolved | yuvipanda | T98440 Deploy new unified webservice code | |||
| Resolved | yuvipanda | T98442 Convert tomcat-starter to python |
Event Timeline
Comment Actions
There are only 6 tomcat webservices - I wonder if we can just convert them to run as 'generic' webservices (T97230) and get rid of the tomcat type? Recent java apps also seem to prefer jetty / their own servers over tomcat...
Comment Actions
webservice-new generic start '/usr/local/bin/tomcat-starter javatest $PORT' works just fine, and also has working webservice-new restart :)
Comment Actions
(We'll also update documentation on how to make this setup from scratch, in case new tools still want to use tomcat)
Comment Actions
I have no objection; the 'tomcat' queue was created because - at the time - tomcat was the only "not-lighttpd" supported web server; de facto the tomcat queue is the precursor to the generic queue.
lighttpd is the only one that is special cased because it is the most common and keeping all lighttpd togeter allows us to be less conservative about memory allocation (given they all share the same executable and libraries by definition)
Comment Actions
I just tested this again, for the isbn tool.
webservice-new generic start '/data/project/isbn/tomcat-starter isbn'
Seems to do the trick. I'd rather us do that than support tomcat forever.
Comment Actions
Change 285066 had a related patch set uploaded (by Yuvipanda):
toollabs: Check env $PORT before $2
Comment Actions
Change 285142 had a related patch set uploaded (by Yuvipanda):
Add legacy support for tomcat webservices
Comment Actions
ok, so webservice-new tomcat start works now with ^ 'hack'. There are only 6 of these running, so we can get rid of it after we move them to newer setups!