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

adopt buildmaster and alpha tags for oscontainer #308

Merged
merged 4 commits into from
Oct 1, 2018

Conversation

miabbott
Copy link
Member

This pile of commits attempts to implement some of the versioning scheme for the oscontainer discussed in #201.

Firstly, during the treecompose pipeline, the oscontainer is no longer tagged with latest, but with buildmaster. Additionally, it is tagged with the ostree commit that was used to generate the container image.

This ostree commit is passed to the aws-test pipeline after a successful cloud pipeline run. In the aws-test pipeline, the oscontainer is pulled by the ostree commit and if the AWS tests are successful, the oscontainer is tagged with alpha and pushed to the registry.

This is probably not the best way to do this kind of image promotion and will likely be obsoleted by coreos-assembler, but I figured I would still put this out there to see how it was received.

@openshift-ci-robot openshift-ci-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Sep 21, 2018
@cgwalters
Copy link
Member

The primary downside of this is that today, the api.ci cluster will be garbage collecting untagged oscontainers. If we start pushing ostree-commits-as-tags, we'll need to implement some GC policy ourselves.

Which quickly gets into something like this: https://github.com/cgwalters/playground/blob/master/rust/imagestream-ostree-hash/src/imagestream-ostree-hash.rs

I could try to stick that code inside the coreos-assembler container?

@cgwalters
Copy link
Member

The other big topic here is that if we go to the always-pivot approach from openshift/installer#281

We'd basically stop caring too much about the AMIs, and our AWS test would be "boot and pivot". This would significantly simplify a lot of things.

I mean more generally we would need to be uploading AMIs (we will have to ship fixes to e.g. Ignition) but they can be on a much less frequent basis.

@cgwalters
Copy link
Member

At a high level...I didn't know you were working on this, I probably would have asked nicely for work to focus on the assembler 😄 But - improving the current pipeline is useful too! We just have to carefully weigh the risk/rewards.

Let's split out the two prep patches to the util API, they look clean and we can merge them now.

@miabbott
Copy link
Member Author

The primary downside of this is that today, the api.ci cluster will be garbage collecting untagged oscontainers. If we start pushing ostree-commits-as-tags, we'll need to implement some GC policy ourselves.

I think we could implement this trivially by just using skopeo delete on the images tagged with an ostree commit that didn't pass AWS tests, no?

At a high level...I didn't know you were working on this, I probably would have asked nicely for work to focus on the assembler 😄 But - improving the current pipeline is useful too! We just have to carefully weigh the risk/rewards.

Yeah, I was just tinkering in this area and wanted to measure the reception. I could try to fit this into the assembler, but I guess I'm still not clear on everything the assembler would be responsible for and how to work in pieces like this.

I'm comfortable with sending the majority of this PR to /dev/null

Let's split out the two prep patches to the util API, they look clean and we can merge them now.

Will do.

@cgwalters
Copy link
Member

I think we could implement this trivially by just using skopeo delete on the images tagged with an ostree commit that didn't pass AWS tests, no?

Yeah that'd help a lot.

Yeah, I was just tinkering in this area and wanted to measure the reception. I could try to fit this into the assembler, but I guess I'm still not clear on everything the assembler would be responsible for and how to work in pieces like this.

Right, that's a big topic. I'm still trying to land the oscontainer basics there along with some work around how the images are sync'd.

@miabbott
Copy link
Member Author

Right, that's a big topic. I'm still trying to land the oscontainer basics there along with some work around how the images are sync'd.

So let's hold off on this PR for now, with the expectation that we'll be able to do more intelligent tagging/promotion once coreos-assembler is more mature.

It's not like there is any tooling here or on the OpenShift side that is waiting for a buildmaster or alpha tag.

@miabbott
Copy link
Member Author

So let's hold off on this PR for now, with the expectation that we'll be able to do more intelligent tagging/promotion once coreos-assembler is more mature.

I chatted with @cgwalters and we decided to give this PR a shot, but first I need to try to implement the skopeo delete garbage collection mentioned above.

I've split out the utility functions in to a separate PR (#309)

@miabbott
Copy link
Member Author

/hold

@openshift-ci-robot openshift-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Sep 21, 2018
@miabbott miabbott force-pushed the version_tagging branch 4 times, most recently from 0b34a81 to 120d657 Compare September 26, 2018 20:16
@miabbott
Copy link
Member Author

The commits on this PR are kind of a mess right now because I rebased on top of #312 and force pushed.

However, I think the changes in #312 will simplify some of what I'm doing here, so I want to wait for that to land before trying to get this reviewed/merged again.

@miabbott
Copy link
Member Author

/hold cancel

@openshift-ci-robot openshift-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Sep 27, 2018
@miabbott
Copy link
Member Author

I'm pretty sure this should work; though kind of hard to test since it involves manipulating the production registry.

@miabbott
Copy link
Member Author

Rebased ⬆️

podman push ${OSCONTAINER_IMG}:buildmaster
podman push ${OSCONTAINER_IMG}:${composeMeta.commit}
skopeo inspect docker://${OSCONTAINER_IMG}:buildmaster | jq '.Digest' > imgid.txt
podman inspect --format='{{.Id}}' ${OSCONTAINER_IMG}:buildmaster > imgid.txt
Copy link
Member

Choose a reason for hiding this comment

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

Duplicate writes to imgid.txt?

Copy link
Member Author

Choose a reason for hiding this comment

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

Ugh, screwed up my rebase.

@@ -32,6 +35,7 @@ node(NODE) {
sshUserPrivateKey(credentialsId: params.ARTIFACT_SSH_CREDS_ID, keyFileVariable: 'KEY_FILE'),
]) {
utils.rsync_file_in_dest(ARTIFACT_SERVER, KEY_FILE, "${images}/cloud/latest/meta.json", "${WORKSPACE}/meta.json")
ostree_commit = utils.sh_capture("jq -r '.[\"ostree-commit\"]' ${WORKSPACE}/meta.json")
Copy link
Member

Choose a reason for hiding this comment

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

This isn't new (you're building on code right below), but probably we should just use readJSON rather than calling out to jq - Groovy is a real programming language.

Copy link
Member Author

Choose a reason for hiding this comment

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

Okay, I'll include another commit to use that in this area.

# Tag the container image to alpha, then GC the image tagged with the ostree commit
podman pull ${OSCONTAINER_IMG}:${ostree_commit}
podman tag ${OSCONTAINER_IMG}:${ostree_commit} ${OSCONTAINER_IMG}:alpha
podman push ${OSCONTAINER_IMG}:alpha
Copy link
Member

Choose a reason for hiding this comment

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

We don't actually need to pull locally here, we can just skopeo copy right?

Copy link
Member Author

Choose a reason for hiding this comment

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

Ooh, fancy!

In an effort to get closer to what has been discussed in
openshift#150, the tagging scheme has been changed so that the
latest container image out of the pipeline is tagged with
`buildmaster` and the commit ID.  The usage of the commit ID allows
for other parts of the piepline to easily refer to it for other
operations.
In openshift#150, it was discussed that an `alpha` tag should be
made for the oscontainer (and cloud image) after it passes the tests
run in AWS.  This change accomplishes this goal by pulling the
oscontainer by commit ID, tagging it as `alpha` and pushing it to the
registry.  (After a successful test, obviously)

If the AWS tests fail, the image tagged with the ostree commit is
garbage collected and no alpha promotion happens.
To bootstrap the change to `buildmaster`, we need to do a quick test
if the tag exists on the registry.  If it exists, we can pull from it,
otherwise we need to use `latest`
@miabbott
Copy link
Member Author

New commits incorporating feedback from @cgwalters ⬆️

@cgwalters
Copy link
Member

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Oct 1, 2018
@openshift-merge-robot openshift-merge-robot merged commit 33efc9b into openshift:master Oct 1, 2018
@wking wking mentioned this pull request Oct 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lgtm Indicates that a PR is ready to be merged. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants