Jump to navigation Jump to search
This page holds notes and ideas regarding the Stretch migration of Toolforge, specially related to k8s.
Meeting attendats: Andrew, Chase, Arturo.
- refactor toolforge puppet code (Brooke already started)
- get puppet compiler for VMs so we can actually test puppet code
- k8s: allocate a couple of weeks to play with callbacks and kubeadmin and evaluate if they are the way to go.
Thinks to take into account
- probably going directly to Stretch is the way to go.
- By the time we end, Buster may be stable already
- (and Jessie old-old-stable)
- k8s: jump versions when moving to eqiad1?
- 1.4 --> 1.12
- does the new version works for custom ingress controllers?
- does kubdeadm works for us?
- integration with nova-proxy?
- try in a cloudvps project, in a pre-defined time slot
- lots of Yuvi hacks. What do we do with them
- try to do the same admission controller but without the custom Yuvi code. Mind k8s versioning.
- native UidEnforcer probably already in place
- native RegisterEnforcer ??
- HostPathEnforcer: probably use new callback JSON mechanisms
- same for HostAutoMounter
- kubeadmin is probably the way to go. Already using for PAWS.
- ingress controller for k8s
- currently using kubeproxy, nginx
- it worth migrate to some native k8s ingress controller
- co-existence of k8s clusters
- write puppte code from scratch, a new deployment side-by-side with the old
- both grids co-exists and users start launching things in the new one
- a script or something to make sure nothing from the same tool is runnin gin the old grid
- currently using vxlan overlay. We can probably carry over the same model.