Tarun Ramakrishna Elankath

Results 51 comments of Tarun Ramakrishna Elankath

Commencing this. (will update)

There is no gRPC comm between MCM and MC controller. We are not very clear on the requirement. Considering that driver implementations are now initialized in provider specific code in...

Grooming Discussion Results: 1. Nobody knows why current overshooting freeze logic checks for machine object count instead of VM (aka instance) count. History on this was lost and not captured...

We discussed this in the grooming and note our observations and a proposed solution. Our design will need to be refined when we pick this up for implementation. #### Justification...

### Grooming - We currently transition un-healthy machines in `unknown` phase to `failed` phase by MaxReplacement=1 in every reconcile cycle. - We propose making the MaxReplacements configurable parameter for the...

This problem is solved now with since in the current drain code, we don't just wait for volume detach, but we also wait for volume attachment to another node. So,...

We need to introduce metrics for following cases: - [ ] machine drain - especially metrics related to pod eviction/deletion, number of times drain was evicted, number of times health-check...

Grooming decision: Too much refactoring needed in current code. Agree on drain being a separate controller. We should target this for controller-runtime port.

- [x] Names are already generated in function `GetMachineFromTemplate` in `controller_utils.go` - [ ] For MachineSet objects, we currently use the object name: `Name: d.Name + "-" + encodedMachineTemplateSpecHash` in...

Currently validation of objects like `MachineClass` only happen when a corresponding `Machine` for this is created. We will handle this in the controller runtime migration.