Origin: oc expose won't let me specify a specific port for a route

[thesteve0]

I have a service which has three different ports 9091, 9090, and 3000. I want the external route to go to 3000 so I tried two different methods with oc expose:

pousty@localhost scope$ oc expose svc crunchy-scope --port=3000
error: cannot use --port when generating a route
spousty@localhost scope$ oc expose svc crunchy-scope --target-port=3000
error: cannot use --target-port when generating a route

First bug - there is no doc on either of those items saying you can't use them with route. Second - there doesn't seem to be a doc'ed way to do what I want.

If I just do

oc expose svc crunchy-scope

It binds to 9091 and it doesn't work properly

[kargakis]

cc: @deads2k @fabianofranz

[deads2k]

@kargakis isn't this oc create route edge crunchy-scope-route --service=crunch-scope --port=3000?

[kargakis]

oc create route edge and every other create route subcommand for that matter is for secured routes. Only oc expose creates unsecured routes atm

[deads2k]

oc create route edge and every other create route subcommand for that matter is for secured routes. Only oc expose creates unsecured routes atm

Ok, but otherwise that is the command? The fact that both --port and --target-port are options on oc expose gives me pause about trying to use it. I'd probably be a happier person with oc create route insecure.

[kargakis]

Ok, but otherwise that is the command?

Otherwise, yes.

The fact that both --port and --target-port are options on oc expose gives me pause about trying to use it. I'd probably be a happier person with oc create route insecure.

I would expect an example whould do the job but I don't feel strong. @fabianofranz @smarterclayton preferences on:

oc expose svc/foo --port

vs

oc create route insecure foo --service=foo --port

[deads2k]

@kargakis what would oc expose svc crunchy-scope --target-port=3000 do?

[kargakis]

@deads2k what it already does ie. returns an error that you cannot use --target-port when exposing services via routes

[deads2k]

@deads2k what it already does ie. returns an error that you cannot use --target-port when exposing services via routes

I hate this command so much. For those of us following along at home, what is difference between --container-port, --port, and --target-port for each of the different things that oc expose does?

[deads2k]

I hate this command so much. For those of us following along at home, what is difference between --container-port, --port, and --target-port for each of the different things that oc expose does?

Also, the fact that I have to ask is indicative of the insanity that is oc expose.

[kargakis]

lol

I think this boils down to the fact that we wanted expose to work for routes too. Which makes sense but upstream had already overloaded the command to work just for services.

ps. opened https://github.com/kubernetes/kubernetes/issues/25039 upstream

[thesteve0]

I get the hatred of two commands that do the same thing. That said I also have to say:

oc expose svc crunchy-scope --port=3000

is much easier for me to understand than:

oc create route insecure foo --service=foo --port

But then again there is another trello card where we are trying to bring some more sanity to the oc create, oc get, oc ... And if that happens then the oc create route makes more logical sense.

So... if we can get more logical command structure I am all for 'oc create route'. But why wouldn't it be oc new rather than oc create? How are they different?

[liggitt]

oc create route [edge | passthrough | reencrypt]:

oc expose:

[deads2k]

oc create route [edge | passthrough | reencrypt]:

oc expose:

Wait, I think I see a flag there in the wrong position. :)

[smarterclayton]

I agree with Steve in that the verb is what you know first - before you know about routes. Create assumes you know about routes, expose is the way you interact with the system.

Expose should have less flags.

[smarterclayton]

But the one flag it should have... is --ports

[deads2k]

But the one flag it should have... is --ports

Don't worry, not only do you have it once, you have three times! --port --target-port --container-port, use them wisely (and differently in each generator of course). :)

I've never seen us reduce the number of flags on a command, but if we could get it small enough it would help a lot.

[smarterclayton]

At minimum we can hide them in help and then run "rm -rf /" if you try to
use them.

On May 6, 2016, at 8:08 PM, David Eads [email protected] wrote:

But the one flag it should have... is --ports

Don't worry, not only do you have it once, you have three times! --port
--target-port --container-port, use them wisely (and differently in each
generator of course). :)

I've never seen us reduce the number of flags on a command, but if we could
get it small enough it would help a lot.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/openshift/origin/issues/8699#issuecomment-217590890

[kargakis]

lol