DeploymentConfig export always contains reference to old Namespace

[damemi]

When exporting a DeploymentConfig to either JSON or YAML, there is a field entry added to the exported template under Spec.Triggers.ImageChangeParams.From with the Namespace the DC is currently in. Is this an intentional feature? There doesn't seem to be any documentation on it. It's possible that, when exporting a DC, a user may not want any references to the Namespace from which it was exported (such as in the case of re-creating that DC in a different Namespace).

Steps To Reproduce

1. Create a project with a deploymentconfig
2. oc export -o yaml dc
   (note: this also occurs with other oc commands such as oc get as well as JSON)

Current Result

- apiVersion: v1
  kind: DeploymentConfig
  ...
  spec:
    ...
    triggers:
    - imageChangeParams:
        ...
        from:
          kind: ImageStreamTag
          name: origin-ruby-sample:latest
          namespace: test

Expected Result

It would be nice to be able to exclude the namespace field when exporting these kind of resources.

[abhgupta]

The concrete use case that we are looking at is moving ALL resources within the project to a different project/namespace.

[bparees]

@mfojtik is oc export your team?

[mfojtik]

@bparees I think so (@pweil- ?).

@abhgupta @damemi what if the ICT.From namespace is there intentionally and you really looking for a change in the image stream tag defined in namespace other than the current namespace. For example you have a "canary" namespace, where you deploy when the image is changed and you promote the image to another namespace? Would that be a valid case?

If yes, then the solution here might be to opt-out the namespace when the namespace matches the namespace from where the DC is being exported. @deads2k @liggitt agree?

[mfojtik]

@bparees I think it is @ncdc team now ;-)

[deads2k]

If yes, then the solution here might be to opt-out the namespace when the namespace matches the namespace from where the DC is being exported. @deads2k @liggitt agree?

For most of our API, namespace="" in an object ref means "use the current namespace". There's some argument that pinning it, namespace=<current-namespace>, means "use this exactly namespace, not the current one". Exporting is one of those cases were sometimes you definitely want X and other times you definitely want notX.

Oh, and our server-side export logic only gets an "on/off" flag on requests, no details.

[bparees]

Exporting is one of those cases were sometimes you definitely want X and other times you definitely want notX.

and if you specify -o template you probably want "Y" where "Y" is "make the namespace field a parameter with a default value of either X or notX"

[bparees]

s/-o template/--as-template/

[ncdc]

@mfojtik oc export is an origin thing, so it's not me (although we'd be happy to discuss the issue)

[deads2k]

@mfojtik oc export is an origin thing, so it's not me (although we'd be happy to discuss the issue)

@ncdc note the "export" support on GETs from the kube API server.

[ncdc]

@deads2k sure, but we aren't using that in origin now. Also, this is about handling a field specific to an origin resource, which sounds like an origin problem (unless we implement something like https://trello.com/c/pqGl8CVe/276-5-api-types-should-be-able-to-express-do-not-export).

[deads2k]

@deads2k sure, but we aren't using that in origin now. Also, this is about handling a field specific to an origin resource, which sounds like an origin problem (unless we implement something like https://trello.com/c/pqGl8CVe/276-5-api-types-should-be-able-to-express-do-not-export).

We tried here: #8570, but we opened kubernetes/kubernetes#24855 to try to achieve some parity upstream first.

[0xmichalis]

We didn't use to pin the object reference namespace but ever since we started indexing configs based on those references we need them to be fully expanded. Agreed that oc export / oc get --export should strip them down.

[liggitt]

Agreed that oc export / oc get --export should strip them down.

I can see both use cases. If you're exporting the whole project and moving all resources to a new one, you want the refs localized (namespace removed). If you're just exporting a dc and expecting it to work in a new namespace, you want the ref to stay absolute

[0xmichalis]

Both are valid. I think that oc get --export should run the default (if it can be considered as default) strip everything down case and oc export should handle all the cases with additional flags. Thoughts?

[openshift-bot]

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[openshift-bot]

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

[openshift-bot]

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close