Tracking ticket for things that need to happen before the webservice default backend can be kubernetes.
Description
Description
Details
Details
Event Timeline
Comment Actions
Change 337422 had a related patch set uploaded (by Dzahn):
prometheus: add AAAA for 1003/1004, v6 PTR for all
Comment Actions
-1. There are many differences between SGE webservices and Kubernetes ones, and thus changing the default offers quite a surprise for users. IMHO we shouldn't open that box. I think it is useful to document and promote the Kubernetes backend where possible, but silently changing behaviour for existing setups can only cause harm.
Comment Actions
What if instead we require --backend=... and stop with an error if it is not provided? If that were combined with T148872: Make webservice command read default cli arguments from ~/.webservicerc it would be simple for each tool author to add a $HOME/.webservicerc and pin to the backend of their choosing. The error message would really only be needed on webservice start and could give a nice set of pros/cons and wiki links to read more.
Comment Actions
Change 443190 had a related patch set uploaded (by Nehajha; owner: Nehajha):
[operations/software/tools-webservice@master] Removing gridengine as default and encouraging the use of Kubernetes
Comment Actions
The potential for confusion that @scfc pointed out in T154504#3034899 is still true today, but the more that @Harej and I discuss this, the more we are finding reasons to switch the default from gridengine to Kubernetes. Here's the business logic that I hope makes the most sense, is easiest for long term users to adjust to, and makes things hopefully simple for new users:
- Look for --backend=... in cli arguments
- Look for 'backend' in $HOME/service.manifest
- Look for --backend=... in $HOME/.webservicerc
- If no backend found yet, default to 'kubernetes' and emit this warning to the user:
WARNING: No explict backend provided. Using default of 'kubernetes' For help refer to <https://wikitech.wikimedia.org/wiki/Help:Toolforge/Web>
The biggest potential problem I can see with this plan is that webservice stop clears the backend state from service.manifest. This means the most likely place for existing tools to trip over this is if issuing a webservice stop; [do something]; webservice start.
Comment Actions
Change 443190 had a related patch set uploaded (by BryanDavis; owner: Nehajha):
[operations/software/tools-webservice@master] Make Kubernetes the default backend and warn when guessing
Comment Actions
Change 443190 merged by jenkins-bot:
[operations/software/tools-webservice@master] Make Kubernetes the default backend and warn when guessing
Comment Actions
Mentioned in SAL (#wikimedia-cloud) [2020-04-08T23:35:38Z] <bstorm_> deploy toollabs-webservice v0.66 T154504 T234617
Comment Actions
Mentioned in SAL (#wikimedia-cloud) [2020-04-08T23:49:21Z] <bd808> Running rebuild_all for Docker images to pick up toollabs-webservice v0.66 (T154504, T234617)
Comment Actions
Mentioned in SAL (#wikimedia-cloud) [2020-04-09T04:29:55Z] <bd808> Running rebuild_all for Docker images to pick up toollabs-webservice v0.66 [try #2] (T154504, T234617)