-
Notifications
You must be signed in to change notification settings - Fork 58
assembly of reconfigurator state should have limits #9197
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
base: main
Are you sure you want to change the base?
Conversation
I tested this manually against
Set the env variable based on the output above so I don't have to keep specifying it:
Then I created a sequence of blueprints and made each successive one the target, like this:
In the end I had this list:
First, I'll export with the default pretty large limit:
That got all of them, as expected. Then I'll export with a lower limit:
That saved only the expected number, and only the most recent ones. I wanted to try the workflow of archiving in batches. So I started by archiving with limit 8:
That file has the expected 8, including the current target, meaning it deleted 7:
And they're gone:
If we archive again, whatever the limit, we'll fetch them all and delete all but the current target:
Again, we've got the latest 4, including the target and three that we deleted:
and all but the target are gone now:
Here's the history now:
I think this is all working as expected. |
This is a first step towards including Reconfigurator state in support bundles. I wanted callers to be able to cap how big these files could be so that the process doesn't take an unbounded amount of time or space. Then I realized that this also allows folks to use
omdb reconfigurator archive
to clean up enormous numbers of blueprints in batches by just re-running the tool with whatever limit they want.There are two things less than ideal about this:
I think this is all okay because:
omdb reconfigurator archive
regularly with each update, we should never have that many blueprints in a system that we care about. So we'll generally still be grabbing everything.I consider all of this sort of a stopgap. We really need to do #7278 so that support doesn't have to run tools to archive/prune old blueprints.