Page MenuHomePhabricator

Make webservice backend default to kubernetes
Open, MediumPublic


Tracking ticket for things that need to happen before the webservice default backend can be kubernetes.


Related Gerrit Patches:
operations/software/tools-webservice : masterMake Kubernetes the default backend and warn when guessing
operations/dns : masterprometheus: add v6 reverse records

Event Timeline

Restricted Application added a project: Cloud-Services. · View Herald TranscriptJan 3 2017, 6:32 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Change 337422 had a related patch set uploaded (by Dzahn):
prometheus: add AAAA for 1003/1004, v6 PTR for all

Change 337422 merged by Filippo Giunchedi:
prometheus: add v6 reverse records

scfc triaged this task as Medium priority.Feb 16 2017, 11:09 PM
scfc removed a project: Patch-For-Review.
scfc moved this task from Triage to Backlog on the Toolforge board.
scfc added a subscriber: scfc.

-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.

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

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:

  1. Look for --backend=... in cli arguments
  2. Look for 'backend' in $HOME/service.manifest
  3. Look for --backend=... in $HOME/.webservicerc
  4. 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 <>

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.