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
- created: 2017-08-08T12:02:04Z
If we link up with the kubernetes resource exporting by adding --export:
$ oc get is ruby-hello-world -o yaml --export
This leads to an initial question, what stripped the status tags? I
would have expected this code to live in the image stream strategy:
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:
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
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?
All help appreciated, thanks.
dev mailing list