oscontainer tags #201
Labels
kind/feature
Categorizes issue or PR as related to a new feature.
lifecycle/stale
Denotes an issue or PR has remained open with no activity and has become stale.
Comments
|
So one thing I learned is that there's no Docker registry API to list untagged images. However, OpenShift "ImageStreams" do maintain this history. So we could base some of our infrastructure on that: |
cgwalters
added
the
kind/feature
|
To do image promotion on the registry, it appears we'll have to use a method similar to I'm thinking we should start pushing This would increase the amount of image tags available on the registry, unless we could come up with a pruning mechanism for the image. |
Closed
|
Wanted to migrate a relevant piece of #150 here:
|
This was referenced Sep 21, 2018
wking
added a commit
to wking/openshift-installer
that referenced
this issue
Oct 3, 2018
openshift/os@76b3ae5d (aws-test: Add a rhcos_test=smoketested tag, 2018-09-25, openshift/os#314) started adding rhcos_tag=alpha tags to tested AMIs. The likely plan for RHCOS tagging is [1], although they don't have stable docs for that yet. With this commit, we allow the user to specify whichever channel they want, and we search for that tag. If they give us nonsense, we'll now hit AWS, see no images in the nonsense channel, and report that back to the caller. Users that don't care about release channels and just want to use the latest image regardless of channel, can set 'channel' to an empty string. [1]: openshift/os#201 (comment)
|
@wking Would a file in this repo (i.e. |
Anything that actually lands in the repo would be fine. I just want something more authoritative than an issue comment to link to ;). |
|
Issues go stale after 90d of inactivity. Mark the issue as fresh by commenting If this issue is safe to close now please do so with /lifecycle stale |
openshift-ci-robot
added
the
lifecycle/stale
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We should make use of tags; today we just push
:latest, and I manually pushed a:alphatag.It'd be great to have someone look at automatically tagging :alpha after it passes tests - and also ensuring that once this is done we have corresponding images generated (and hmm....we should probably put the kickstart in the oscontainer too!)
Also, to make things more complex: I think we should defer uploading AMIs until after basic qemu sanity checking. Right now the AMI upload is 20 minutes; we could have run tons of basic qemu tests in that time.
So maybe the flow is e.g.:
treecompose ->
:latestbasic sanity tests ->
:alpha-sanity-> upload to EC2Once it's in EC2 we do a lot more extensive testing, maybe of a cluster ->
:alpha-cluster-sanityPromotion from
:alpha-cluster-sanityto e.g.:betawould be manual?Yet another tricky thing in all of this is that we will almost certainly need to (in practice) decouple OS-basics testing from kube-and-above testing.
The text was updated successfully, but these errors were encountered: