-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[main] Add new method to track originating cluster of Backup #613
base: main
Are you sure you want to change the base?
Conversation
4967e19
to
f0b6b30
Compare
4040156
to
9ac7ecb
Compare
@jbiers - So i'm not moving it to in review yet, since this was a very rough first pass try. However if you can take some time to get familiar with the changes and review the list of concerns I thought of (as well as consider/add your own) - that'd be great help to keep the ball rolling on this. In other words, while I could work on this more I'd love your feedback first before I spend more time on it. |
@alexandreLamarre - I've added you as a reviewer her as I'd like to get your take on this. When you have time LMK if you'd like to sync up and chat about in a huddle. Or feel free to review in your own time and give me feedback here. |
This partial solves for #612
However it's important to note that while I wrote an RFE for this too - the root here is seeking to fix a bug. The bug is that "BRO itself doesn't do anything to give indications when In-Place Restore is acceptable to use".
The short version of the fix, is we add a few new status details and expose them via
kubectl
. And later make a change torancher/dashboard
to ensure UI can also benefit from this new context by adding a column.To be discussed:
2.10.x
release?k8s
seems to be OK with full on schema additions (ofspec
too) as long as they're optional/nullalble. This is hopefully less impactful since users cannot controlstatus
.originCluster
not existing on status,