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.

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

Prune update #839

Merged
merged 2 commits into from
Nov 1, 2019
Merged

Prune update #839

merged 2 commits into from
Nov 1, 2019

Conversation

vrutkovs
Copy link
Member

@vrutkovs vrutkovs commented Oct 10, 2019

This PR reworks coreos-assembler prune and adds new commands:

  • bump_timestamp used during the build to update builds.json timestamp
  • cleanup-bucket to remove unreferenced builds in the bucket
  • prune is now python and removes old builds from build.json (this won't be started during build procedure)

TODO:

  • Fetch arches from unreferenced builds (currently x86_64 is hardcoded)
  • Cleanup azure and gcp instances
  • Removed --skip-prune option breaks RHCOS pipeline

@vrutkovs vrutkovs requested review from jlebon and cgwalters October 10, 2019 16:37
@jlebon
Copy link
Member

jlebon commented Oct 10, 2019

Woah, that's a lot of commits.

bash wrapper was replaced with python version

Awesome! 👍

Can we start with splitting this out into some prep PRs with fewer changes? (Roughly keeping the "new features" here, and splitting out the "cleanups", both loosely defined :) ).

@cgwalters
Copy link
Member

Definitely agree on splitting out a prep cleanup PR first, looks like you already have things split up nicely!

One other big topic is...before this, cmd-prune was just about the local storage. Having it turn from a local-only command into a remote command is...tricky.

See also #823 which introduced some notion of "local state" vs "remote state" into cosa.

I wonder if what we really want is cmd-remote-prune or so? Or, I guess just error out if one has local changes?

@miabbott
Copy link
Member

miabbott commented Oct 11, 2019

Love the direction this is heading. One thing I'll mention is that we need a way to indicate that some builds should never be pruned; i.e. official releases. Maybe needs changes to builds.json schema to have a field for this?

Doesn't (and probably shouldn't) have to be fully implemented here, but something to keep in mind.

@vrutkovs
Copy link
Member Author

some builds should never be pruned; i.e. official releases.

Agree, the defaults are to keep all builds and remove just unreferenced builds (stored in S3, but not found in builds.json). Perhaps its worth splitting this into a dedicated subcommand instead?

@jlebon
Copy link
Member

jlebon commented Oct 11, 2019

One thing I'll mention is that we need a way to indicate that some builds should never be pruned; i.e. official releases.

We can also use tags for that. The prune logic already saves those.

Also slightly leaning towards a new command for this, though no strong opinion either way.

@vrutkovs vrutkovs force-pushed the prune-rewrite branch 15 times, most recently from 3864f6f to 2706252 Compare October 15, 2019 11:28
@vrutkovs vrutkovs changed the title WIP Prune update Prune update Oct 15, 2019
@vrutkovs
Copy link
Member Author

One thing I'll mention is that we need a way to indicate that some builds should never be pruned; i.e. official releases. Maybe needs changes to builds.json schema to have a field for this?

Prune won't remove tagged builds

Also slightly leaning towards a new command for this, though no strong opinion either way.

Implemented this - bump-timestamp won't touch the builds and simply prepare builds/builds.json. prune and cleanup-bucket won't be called in the pipeline (yet) and would remove builds or unreferenced keys in the bucket

@vrutkovs vrutkovs force-pushed the prune-rewrite branch 2 times, most recently from 08eb5b3 to aff4b07 Compare October 15, 2019 12:59
@cgwalters
Copy link
Member

Agree, the defaults are to keep all builds and remove just unreferenced builds (stored in S3, but not found in builds.json).

One thing to keep in mind (doesn't/shouldn't be done in this PR) is that we also need "unreferenced tagged resource" pruning for e.g. AMIs.

@vrutkovs vrutkovs force-pushed the prune-rewrite branch 3 times, most recently from aeba046 to 8ed89a1 Compare October 30, 2019 10:58
@vrutkovs
Copy link
Member Author

All issues fixed, PTAL

Copy link
Member

@jlebon jlebon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one comment, otherwise LGTM! Can you rebase, drop the debugging bits, and clean up the commit history?

.cci.jenkinsfile Outdated
@@ -24,15 +24,34 @@ coreos.pod([image: 'registry.fedoraproject.org/fedora:30', privileged: true, kvm
cosa_cmd("init https://github.com/coreos/fedora-coreos-config")
cosa_cmd("fetch")
cosa_cmd("build")
cosa_cmd("kola run")
//cosa_cmd("kola run")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please drop this now that #879 landed

.cci.jenkinsfile Outdated
// cosa_cmd("buildextend-openstack")
// cosa_cmd("buildextend-vmware")
// cosa_cmd("compress")
// cosa_cmd("buildupload --dry-run s3 --acl=public-read my-nonexistent-bucket/my/prefix")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also need to uncomment this before we merge.

#!/usr/bin/python3 -u

'''
This script removes previous builds. DO NOT USE on production pipelines
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mmmm. I think it's a bit more nuanced than that. For RHCOS we can prune bootimages not pinned by the installer, for example.

But...this gets to an interesting topic. I've been thinking we should explicitly copy/promote bootimages we want to pin to a separate "stream". But anyways, just noting this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prune won't touch "tagged" builds - seems this field should be updated with pinned images used in installer

@vrutkovs vrutkovs force-pushed the prune-rewrite branch 2 times, most recently from 631adbc to c6fcef4 Compare October 30, 2019 17:23
@vrutkovs
Copy link
Member Author

Are we happy with test results? I'm going to drop prune debug commit and squash into a series of commits

@vrutkovs vrutkovs force-pushed the prune-rewrite branch 8 times, most recently from 4da4bc0 to db277a5 Compare October 31, 2019 17:42
Copy link
Member

@jlebon jlebon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we squash the commits down? How about just two:

  • one that reworks cmd-prune + auxiliary
  • one that introduces cmd-remote-prune

Copy link
Member

@jlebon jlebon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, this looks good to me. Thanks a lot for working on this! There are a few extraneous lines that need to be cleaned up, but not going to block on it.

Will leave it open for a bit for folks to have a chance to have a final look.

@jlebon
Copy link
Member

jlebon commented Oct 31, 2019

Just offhand, a few follow-up steps I see for remote-prune after this:

  • Instead of relying on AMIs listed in the build metadata, we should query EC2 directly for the list of AMIs and cross-check. That way, if we're interrupted or they're desynchronized somehow, we don't leak images.
  • Support other clouds as well.

* Split "insert_build" helper out of cmd-prune
* Rework cmd-prune in python
* Add prune tests
This subcommand cleans up unreferenced builds on remote location. 
Currently only s3 buckets are implemented
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants