On Wed, Aug 9, 2017 at 8:49 AM, 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:8d0f81a13ec1b8f8fa4372d26075f0 > dd87578fba2ec120776133db71ce2c2074 > 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. > > The dockerImageRepository in status remains, but weirdly flips from > "project1" to "default" when doing an export. Should this remain in an > exported IS at all? And if so is there any reason why it would flip > from project1 to default? > > Our real problem however picks up in the deployment config after > import, in here we end up with the following (partial) DC: > > apiVersion: v1 > kind: DeploymentConfig > metadata: > annotations: > openshift.io/generated-by: OpenShiftNewApp > labels: > app: ruby-hello-world > name: ruby-hello-world > namespace: project2 > selfLink: /oapi/v1/namespaces/project2/deploymentconfigs/ruby-hello- > world > spec: > template: > metadata: > annotations: > openshift.io/generated-by: OpenShiftNewApp > labels: > app: ruby-hello-world > deploymentconfig: ruby-hello-world > spec: > containers: > - image: 172.30.1.1:5000/project1/ruby-hello-world@sha256: > 8d0f81a13ec1b8f8fa4372d26075f0dd87578fba2ec120776133db71ce2c2074 > imagePullPolicy: Always > name: ruby-hello-world > > So our deployment config still refers to a very specific image and > points to the old project. Is there any logic we could apply safely to > address this? > > It feels like this should boil down to something like > "ruby-hello-world@sha256:HASH", could we watch for > $REGISTRY_IP:PORT/projectname/ during export and strip that leading > portion out? What would be the risks in doing so? > Adding Cesar since he was recently looking at some of the export logic you have questions about and he's also very interested in this subject since he's working on a related piece of functionality. That said: if you've got an imagechangetrigger in the DC you should be able to strip the entire image field (it should be repopulated from the ICT imagestream reference during deployment). However: 1) you still need to straighten out the ICT reference which is also going to be pointing to an imagestreamtag in the old project/cluster/whatever 2) if you don't have an ICT reference you do need to sort this out and stripping it the way you propose is definitely not a good idea...what's going to repopulate that w/ the right prefix/project in the new cluster? What if the image field was pointing to docker.io or some other external registry? In short, you're attempting to tackle a very complex problem where the answer is frequently "it depends". We wrote some documentation discussing some of the considerations when exporting/importing resources between clusters/projects: https://docs.openshift.org/latest/dev_guide/application_lifecycle/promoting_applications.html > > All help appreciated, thanks. > > Devan > -- Ben Parees | OpenShift
_______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
