Tracking ticket for things that need to happen before the webservice default backend can be kubernetes.
|operations/software/tools-webservice : master||Make Kubernetes the default backend and warn when guessing|
|operations/dns : master||prometheus: add v6 reverse records|
|Open||• bd808||T232536 Toolforge Kubernetes internal API down, causing `webservice` and other tooling to fail|
|Open||None||T236565 "tools" Cloud VPS project jessie deprecation|
|Open||None||T214513 Upgrade Toolforge Kubernetes|
|Open||None||T154504 Make webservice backend default to kubernetes|
|Open||None||T154506 Make webservice backend for lighttpd default to kubernetes|
- Mentioned In
- T190696: [Gsoc 2018] Proposal for Toolforge webservice command Improvement
T190638: GSoC 2018 proposal for Improvements for the Toolforge 'webservice' command
T177603: Proposal: Improvements for the Toolforge 'webservice' command
T175768: Improvements for the Toolforge 'webservice' command
T160353: Still issues with node.js webservice
- Mentioned Here
- T148872: Make webservice command read default cli arguments from ~/.webservicerc
-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.
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.
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.