Skip to content
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.

Sign up for GitHub

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

Jump to bottom

build pruning configuration api #13640

Closed
bparees opened this issue Apr 5, 2017 · 6 comments
Closed

build pruning configuration api #13640

bparees opened this issue Apr 5, 2017 · 6 comments
Assignees
@coreydaley
Labels
component/build kind/question needs-api-review priority/P2

Comments

@bparees
Copy link
Contributor

bparees commented Apr 5, 2017 •
edited
Loading

We're working on https://trello.com/c/048p7YRO this sprint, and as part of that we need to add pruning configuration fields to the buildconfig. Specifically the user needs to tell us how many builds to keep.

We have a few apis in mind and would like @openshift/api-review to weigh in on the preferred implementation:

  1. user just indicates to keep N builds, we keep the last N builds.
  2. user indicates to keep N builds, we keep N builds and at least the last successful build if it's not part of N
  3. user indicates to keep N builds, we keep N builds and at least the last failed build if it's not part of N
  4. user indicates to keep N builds, we keep N builds and at least the last failed+successful builds if they are not part of N
  5. user indicates to keep N failed builds and M successful builds, we do that.

(5) aligns with the arguments oadm prune currently takes and is the most flexible option, so that's our preferred approach (ie introduce 2 new fields on BuildConfig, KeepFailedBuilds and KeepSuccessfulBuilds or some such names)

Default values will be infinity in all cases (again unless we are advised otherwise by @openshift/api-review)

/cc @coreydaley
@0xmichalis
Copy link
Contributor

0xmichalis commented Apr 5, 2017 •
edited
Loading

Another option is to follow the implementation of the cleanup policy for CronJobs where options for both successful and failed jobs are provided: kubernetes/kubernetes#40932

@bparees
Copy link
Contributor Author

bparees commented Apr 5, 2017

@Kargakis isn't that pretty much option 5 above?

@smarterclayton
Copy link
Contributor

smarterclayton commented Apr 5, 2017 via email

@0xmichalis
Copy link
Contributor

@bparees yeah, for some unknown reason I skipped that

@pweil-
Copy link

pweil- commented Apr 7, 2017

5 seems easiest to reason about. 1 still makes you understand that N might not be high enough to have a successful build still around.

@bparees bparees assigned coreydaley and unassigned bparees Apr 11, 2017
@bparees
Copy link
Contributor Author

bparees commented Apr 11, 2017

sounds like consensus on option 5 and copy the names from what other components use.

@coreydaley coreydaley mentioned this issue Apr 17, 2017
Merged
simo5 pushed a commit to simo5/origin that referenced this issue Dec 5, 2017
@coreydaley @deads2k
(WIP) Cleanup policy for builds
a86e9ec 
Adds ability to set successfulBuildsHistoryLimit and failedBuildsHistoryLimit on
buildConfigs which will prune old builds.

Closes openshift#13640
Completes https://trello.com/c/048p7YRO/1044-5-cleanup-policy-for-builds-builds
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@coreydaley coreydaley

Labels
component/build kind/question needs-api-review priority/P2
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@smarterclayton @0xmichalis @bparees @coreydaley @pweil-