You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What would you like to be added:
I would like etcd-backup-restore to be refactored, ie, re-written, with components that can be individually turned on/off and provide well-defined interfaces and channels that can be easily consumed by other components within and outside the system. I would like this new replacement of etcd-backup-restore to be lean, modular, well-tested and extensible. I would like the etcd bootstrapping process to be simplified and more maintainable. I would the memory footprint for etcd DB restoration to be reduced. I would like garbage collection of snapshots to be simple and easy to understand.
Why is this needed:
The issues mentioned above cannot be solved within the old repository, sue to various reasons such as testability, backward compatibility concerns, component-wise changes to the code, which require changes in every other component anyway. The only way to roll out a new version of etcd-backup-restore is to fully re-write its components from scratch, possibly re-using existing code snippets from the old code. The name "etcd-backup-restore" is no longer relevant since the code does much more than just backups and restorations - it takes care of maintenance of the etcd DB, along with updation of k8s resources such as member leases and EtcdMember resources that are used by druid for computing etcd cluster status and performing other actions such as compaction or remediations, as specified in the EtcdMember proposal. Accordingly, the name "etcd-backup-restore" needs to be evolved into something that correctly depicts what the code does, which is to manage or look after the etcd, like a steward.
Task List:
Basic project structure
Components (enabled/disabled by individual config flags on default command; metrics and metering registered per component; additional endpoints registered per component as required)
How to categorize this issue?
/area quality robustness usability open-source
/kind enhancement cleanup api-change task
What would you like to be added:
I would like etcd-backup-restore to be refactored, ie, re-written, with components that can be individually turned on/off and provide well-defined interfaces and channels that can be easily consumed by other components within and outside the system. I would like this new replacement of etcd-backup-restore to be lean, modular, well-tested and extensible. I would like the etcd bootstrapping process to be simplified and more maintainable. I would the memory footprint for etcd DB restoration to be reduced. I would like garbage collection of snapshots to be simple and easy to understand.
Why is this needed:
The issues mentioned above cannot be solved within the old repository, sue to various reasons such as testability, backward compatibility concerns, component-wise changes to the code, which require changes in every other component anyway. The only way to roll out a new version of etcd-backup-restore is to fully re-write its components from scratch, possibly re-using existing code snippets from the old code. The name "etcd-backup-restore" is no longer relevant since the code does much more than just backups and restorations - it takes care of maintenance of the etcd DB, along with updation of k8s resources such as member leases and EtcdMember resources that are used by druid for computing etcd cluster status and performing other actions such as compaction or remediations, as specified in the EtcdMember proposal. Accordingly, the name "etcd-backup-restore" needs to be evolved into something that correctly depicts what the code does, which is to manage or look after the etcd, like a steward.
Task List:
v3.4.26
tov3.4.32
tov3.5.x
etcd-druid#445The text was updated successfully, but these errors were encountered: