Move oc export functionality on the server

[0xmichalis]

Forked from #8448 (comment)

cc: @smarterclayton @deads2k

[0xmichalis]

Does this mean that we should deprecate oc export in favor of oc get --export or should we update the former (at least for now)?

cc: @fabianofranz

[smarterclayton]

oc export has other uses - I don't think oc get --export is enough, or even
solves 80% of the problem. The problem with export is that it can't deal
with multiple conditions.

On Mon, Apr 11, 2016 at 10:36 AM, Michail Kargakis <[email protected]

wrote:

Does this mean that we should deprecate oc export in favor of oc get
--export or should we update the former (at least for now)?

cc: @fabianofranz https://github.com/fabianofranz

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#8459 (comment)

[deads2k]

The problem with export is that it can't deal
with multiple conditions.

Can you elaborate on this? Which conditions are you thinking about?

[smarterclayton]

Generally it's "is this for this cluster, or another cluster"? As well as
"is this a 'locked' version or a development copy"?

For instance, what happens when I export an image stream? Do you want to
export spec tags that point to exact images (by UID)? Export spec tags
that point to the original upstream and schedule their import? Do you want
to export a deployment config with triggers? Without triggers? Route
exporting is broken if you export to another cluster (since spec.host is
defaulted by the server but we can't tell whether the end user intended it
to be set, so it's hard to say whether it can be exported across.

On Mon, Apr 11, 2016 at 11:10 AM, David Eads [email protected]
wrote:

The problem with export is that it can't deal
with multiple conditions.

Can you elaborate on this? Which conditions are you thinking about?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#8459 (comment)

[deads2k]

@smarterclayton ok, so the objection is to the lack of expressive-ness in a boolean flag, not to the idea (pushed upstream) of moving export logic server-side to avoid lots of a client-side logic.

I think I'd want the boolean flag to cleanly handle a case of oc get --export all -n source -o yaml | oc create -n destination -f -.

[0xmichalis]

/lifecycle frozen

[0xmichalis]

/sig master