rkt fetch doesn't ever fetch updated image if download locally #2937
Comments
|
+1 |
|
Thanks for reporting this. It was also discussed on irc some days ago. I can see two primary issues:
|
|
@sgotti Thanks. I would say that having a exit status or some kind of way to tell if fetch updated the image would also be a "must have" for admins scripting their rkt workflows. |
Automatic merge from submit-queue rkt: Force `rkt fetch` to fetch from remote to conform the image pull policy. Fix #27646 Use `--no-store` option for `rkt fetch` to force it to fetch from remote. However, `--no-store` will fetch the remote image regardless of whether the content of the image has changed or not. This causes performance downgrade when the image tag is ':latest' and the image pull policy is 'always'. The issue is tracked in rkt/rkt#2937.
Braindump: this can be exposed to the user via a
That is perhaps a bit less straightforward for compatibility reasons, as a non-zero exit status is normally interpreted as an error by the shell. But the same scripting features can be achieved just with a boolean exit status and the above pull-policy. |
|
Here's a potential plan, that I'll get started on if no one objects: I can implement the For ACIs, I think the implementation will be fairly straightforward, but it's a little messier with docker images. Ideally rkt would only fetch docker layers that have changed, but since today rkt has docker2aci squash layers that's not really possible. rkt can't just update the modified layers above a large ubuntu base layer, because it can't separate the thing in its store out into the different layers after it's been squashed. rkt could instead tell docker2aci to not squash the layers, and put each separately in its store. In AppC land the layers (dependencies) are stored separately already, so this doesn't seem too crazy to me. docker2aci would have to add an annotation to the top layer marking it as such, so that when rkt is told to run With this change, rkt could then pass a list of hashes (determined by pattern matching on image names in its store) to docker2aci when it asks it to fetch an image, and docker2aci would only need to fetch and save out any missing layers for the image its told to fetch. One downside to this would be polluting the image store with a bunch of hashes not really intended for humans to read, but rkt could filter out images from a docker source not marked as top layers (again determined by manifest annotations). |
|
@dgonyeo That sounds like a fair plan. Extending the current store to also store intermediate layer hashes seems necessary anyways for efficient handling of OCI images. The only small concern from my side is that your outlined plan would also involve converting each intermediate layer to the current ACI format. This would solve this issue in the short-term, but this logic would only live as long as we don't land support for foreign image formats in the store as outlined in https://github.com/coreos/rkt/blob/v1.22.0/Documentation/proposals/oci.md. |
|
@dgonyeo there's another solution that I think is both simpler to implement and reason about. It isn't as ideal, but I think it gets the 90%. I think it would be enough for This would let us defer proper layer semantics a bit further while fixing the most painful/common cases of redownload. My concerns about each layer -> aci is that we're working on getting OCI support (layers and all I assume) as a first class citizen without integration, so the work on docker2aci there might be wasted. WDYT @dgonyeo? |
|
I agree with @euank's comment above, that's also what I had in mind. Other things to mention:
|
|
Fixed by #3554 |
Uh oh!
There was an error while loading. Please reload this page.
Environment
Ubuntu 14.04
What did you do?
Trying to download an updated image using rkt fetch for a quay.io repo with a docker image. We label our images with stuff like a format like ${image}:${env} where env can be like prod, integration, dev. That way when somebody promotes an image (using the quay.io UI) and a period update task is run, the nodes update to the latest version of that environment's image.
We've come to expect that behavior previous when we were using docker.
I can get it to work by specifying --no-store, but i refetches all images including shared base images. (like the base JVM image we created)
What did you expect?
That default rkt fetch would see if there's an updated image and fetch the changed layers only. At the very least there should be a flag to do that.
Also rkt should return a status code that can be tested in the shell using $? to see if there has been change... so our further scripts can notice if they should bounce the container.
What did you see instead?
The text was updated successfully, but these errors were encountered: