{"action":"created","issue":{"url":"https://api.github.com/repos/openshift/origin/issues/10120","repository_url":"https://api.github.com/repos/openshift/origin","labels_url":"https://api.github.com/repos/openshift/origin/issues/10120/labels{/name}","comments_url":"https://api.github.com/repos/openshift/origin/issues/10120/comments","events_url":"https://api.github.com/repos/openshift/origin/issues/10120/events","html_url":"https://github.com/openshift/origin/pull/10120","id":168413264,"number":10120,"title":"Enable remote layer federation","user":{"login":"miminar","id":1478803,"avatar_url":"https://avatars.githubusercontent.com/u/1478803?v=3","gravatar_id":"","url":"https://api.github.com/users/miminar","html_url":"https://github.com/miminar","followers_url":"https://api.github.com/users/miminar/followers","following_url":"https://api.github.com/users/miminar/following{/other_user}","gists_url":"https://api.github.com/users/miminar/gists{/gist_id}","starred_url":"https://api.github.com/users/miminar/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/miminar/subscriptions","organizations_url":"https://api.github.com/users/miminar/orgs","repos_url":"https://api.github.com/users/miminar/repos","events_url":"https://api.github.com/users/miminar/events{/privacy}","received_events_url":"https://api.github.com/users/miminar/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":12,"created_at":"2016-07-29T20:59:35Z","updated_at":"2016-08-01T17:42:12Z","closed_at":null,"pull_request":{"url":"https://api.github.com/repos/openshift/origin/pulls/10120","html_url":"https://github.com/openshift/origin/pull/10120","diff_url":"https://github.com/openshift/origin/pull/10120.diff","patch_url":"https://github.com/openshift/origin/pull/10120.patch"},"body":"During a cross-repo mount push where the mounted blob belongs to remote\nimage, tag the image into target image stream. This will utilize\npullthrough to federate image's blobs without storing them in the\nregistry.\n\nImage is tagged under `_pullthrough_dep_${blobdgst}` tag.\n\nA follow-up for #9819 addressing the remote layer fedration part.\n\nPlease review just the last commit. All the preceding belong to #9819."},"comment":{"url":"https://api.github.com/repos/openshift/origin/issues/comments/236652508","html_url":"https://github.com/openshift/origin/pull/10120#issuecomment-236652508","issue_url":"https://api.github.com/repos/openshift/origin/issues/10120","id":236652508,"user":{"login":"smarterclayton","id":1163175,"avatar_url":"https://avatars.githubusercontent.com/u/1163175?v=3","gravatar_id":"","url":"https://api.github.com/users/smarterclayton","html_url":"https://github.com/smarterclayton","followers_url":"https://api.github.com/users/smarterclayton/followers","following_url":"https://api.github.com/users/smarterclayton/following{/other_user}","gists_url":"https://api.github.com/users/smarterclayton/gists{/gist_id}","starred_url":"https://api.github.com/users/smarterclayton/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/smarterclayton/subscriptions","organizations_url":"https://api.github.com/users/smarterclayton/orgs","repos_url":"https://api.github.com/users/smarterclayton/repos","events_url":"https://api.github.com/users/smarterclayton/events{/privacy}","received_events_url":"https://api.github.com/users/smarterclayton/received_events","type":"User","site_admin":false},"created_at":"2016-08-01T17:42:12Z","updated_at":"2016-08-01T17:42:12Z","body":">  Image itself should carry the locations where its blobs reside.\r\n\r\nTo clarify - the image is a good mechanism for associating blobs with alternate locations, but the actual serving is based on the blob.  The CDN and federation case (typically public) is that you should retrieve specific blobs from certain locations because of **policy** or **performance**.  In those cases images might be the way to identify the layers (all the layers of these images in this image stream) but the outcome is not image based (it's layer based).\r\n\r\nSo to summarize:\r\n\r\n1. Images are a good mechanism to track where source blobs are located\r\n2. An image stream is a good way to identify a set of images that should be considered candidates for federation.  However, pruning needs to take that into account\r\n3. We need to consider whether we need local federation, or just global federation.  Local federation has security issues unless it's also local because you can force someone to go to a different server.  So for now, global federation seems more common than local federation.\r\n4. We should be using \"copy on tag\" rather than \"referential tag via image stream\" for materializing a copy.  Not all pull through is federation.\r\n5. CDN use cases may want a local copy of a federated layer for safety.  Layer federation for legal policy does not want a local copy to be **served**.  So copy on tag is sufficient for both, and only layer federation for legal policy needs the bit \"don't serve this under any condition\".\r\n\r\nThe structure for materializing blob layers into an image stream has to handle referential counting, so it probably can't collapse common layers from images.  I.e. it has to be:\r\n\r\n```\r\nstatus:\r\n  tags: \r\n  - name: foo\r\n    events:\r\n    - image: sha256:abc1\r\n  layers:\r\n    \"sha256:abc1\":\r\n    - digest: ...\r\n       size: ...\r\n```\r\n\r\nThe good news is that structure could be populated via a controller or migration if necessary, so if we hit transient failures during tagging (can't access the image metadata) we could backfill the data."}}
{"actor":{"display_login":"smarterclayton"}}