Awesome info Maciej, thanks. Our issue was somewhat postponed as I think we've just decided to assume we're restoring users back to the same cluster and project name they were archived from for our first phase, so we'll have to deal with this at some point but it might be a little further out.
On Fri, Aug 11, 2017 at 4:05 AM, Maciej Szulik <[email protected]> wrote: > > > On Wed, Aug 9, 2017 at 2:49 PM, Devan Goodwin <[email protected]> wrote: >> >> We are working on a more robust project export/import process (into a >> new namespace, possibly a new cluster, etc) and have a question on how >> to handle image streams. >> >> Our first test was with "oc new-app >> https://github.com/openshift/ruby-hello-world.git";, this results in an >> image stream like the following: >> >> $ oc get is ruby-hello-world -o yaml >> apiVersion: v1 >> kind: ImageStream >> metadata: >> annotations: >> openshift.io/generated-by: OpenShiftNewApp >> creationTimestamp: 2017-08-08T12:01:22Z >> generation: 1 >> labels: >> app: ruby-hello-world >> name: ruby-hello-world >> namespace: project1 >> resourceVersion: "183991" >> selfLink: /oapi/v1/namespaces/project1/imagestreams/ruby-hello-world >> uid: 4bd229be-7c31-11e7-badf-989096de63cb >> spec: >> lookupPolicy: >> local: false >> status: >> dockerImageRepository: 172.30.1.1:5000/project1/ruby-hello-world >> tags: >> - items: >> - created: 2017-08-08T12:02:04Z >> dockerImageReference: >> >> 172.30.1.1:5000/project1/ruby-hello-world@sha256:8d0f81a13ec1b8f8fa4372d26075f0dd87578fba2ec120776133db71ce2c2074 >> generation: 1 >> image: >> sha256:8d0f81a13ec1b8f8fa4372d26075f0dd87578fba2ec120776133db71ce2c2074 >> tag: latest >> >> >> If we link up with the kubernetes resource exporting by adding --export: >> >> $ oc get is ruby-hello-world -o yaml --export >> apiVersion: v1 >> kind: ImageStream >> metadata: >> annotations: >> openshift.io/generated-by: OpenShiftNewApp >> creationTimestamp: null >> generation: 1 >> labels: >> app: ruby-hello-world >> name: ruby-hello-world >> namespace: default >> selfLink: /oapi/v1/namespaces/default/imagestreams/ruby-hello-world >> spec: >> lookupPolicy: >> local: false >> status: >> dockerImageRepository: 172.30.1.1:5000/default/ruby-hello-world >> >> >> This leads to an initial question, what stripped the status tags? I >> would have expected this code to live in the image stream strategy: >> >> https://github.com/openshift/origin/blob/master/pkg/image/registry/imagestream/strategy.go >> but this does not satisfy RESTExportStrategy, I wasn't able to >> determine where this is happening. > > > Sorry for late reply. Wrt to image streams you're hitting this issue > https://github.com/openshift/origin/issues/15492 > Basically this is caused by the fact that the push to internal registry > updates (or creates) an appropriate image stream. > But the stream has only status, since no actual spec was ever created and > can't be created b/c you can't re-import > that image. During export we can't return you a reliable registry endpoint > that you can then take and import on a > different cluster. That's why we're clearing the tags from status and only > return those from spec. That's the current > design. But there's some hope when we'll fully introduce the public pull > spec I've started working in https://github.com/openshift/origin/pull/15643 > When this is all be in place we'll be able to return a spec that is > importable on a different cluster. Assuming user > provides appropriate auth secrets to be used during import. > > I hope that sheds some light on the topic of IS :) > Maciej _______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
