On Wed, Aug 9, 2017 at 9:58 AM, Ben Parees <bpar...@redhat.com> wrote:
>
>
> On Wed, Aug 9, 2017 at 8:49 AM, Devan Goodwin <dgood...@redhat.com> 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.
>>
>> 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:

Ok good, so during export we can iterate the image change triggers, if
we see one we can match up on containerName and strip container.image
for that name.

>
> 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

Ok I think we can handle this explicitly. More below though.

> 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?

I definitely wouldn't advocate blindly doing so, but rather on export
I believe we can determine the cluster registry IP (if there is one),
and then watch for it as we export objects, and parameterize it. At
this point it feels like we need to be thinking about generating a
template rather than a flat list of kube API resources. (which is what
our app does right now)

To clarify I have been attempting to do as much of this using the
built in kube API "export" param, but the suggestion above feels like
it should not be there. Our main driver will be an app in-cluster (for
monitoring capacity and archiving dormant projects), so we do have a
place to apply extra logic like this. I'm now thinking our app should
layer this logic in after we fetch the resources using kube's export
param, and then generate a template.

Side topic, it would be nice if this functionality was available in oc
somewhere (potentially as some new command in future), would just need
to solve lookup of the integrated registry IP so we could extract it
to a param.

>
> 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

This is very useful, as is the feedback, thanks! If anyone has
additional edge cases in mind please let us know, or if you believe
this is simply not possible and we shouldn't be trying. However at
this point I'm still feeling like we can proceed here with the goal of
doing as much as we can, try to ensure the users project makes it into
it's new location and if something is broken because we missed it, or
it simply has to be broken because we can't make assumptions, they can
fix it themselves.

>
>
>>
>>
>> All help appreciated, thanks.
>>
>> Devan
>
>
>
>
> --
> Ben Parees | OpenShift
>

_______________________________________________
dev mailing list
dev@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev

Reply via email to