Add additional route settings to UI

[spadgett]

https://trello.com/c/WSVk6KQk

• Adds support for creating secure routs during the create flow.
• Adds support creating routes for existing services.

Fixes #6093

TODO:

• Supporting adding routes from browse routes page
• Re-use labels from service when creating route like oc expose
• Rebase when Rename project service to ProjectsService, update existing uses #6084 merges for new project service name
• Fix spec typos

Routing section during create flow:

After clicking "Show options for secure routes":

Fields are enabled and disabled depending on termination type. (Selecting Passthrough disables the Path field, etc.).

Add route from overview:

Add route from service page:

Create route from routes page:

Standalone add route page:

/cc @jwforres @jcantrill

[spadgett]

I'm building on the work already done by @jcantrill for file upload / certificates.

[spadgett]

I could switch to bootstrap-styled selects.

[jwforres]

I definitely like consistently having the fields below the label, it feels a little weird with the selects to the right and all the other inputs beneath.

I do like select dropdowns that have the same look across all browsers. How's the accessbility on the bootstrap ones? Are they still actually tags?

[jwforres]

@gruiz17 FYI

@pweil- anything missing?

[spadgett]

@jwforres It's a real select, although it doesn't actually look consistent across browsers... Not a fan of how it looks in Firefox.

http://getbootstrap.com/css/#selects

[spadgett]

I guess it's not too bad in Firefox.

[jwforres]

Hmm if its not consistently styled, is there any benefit we are getting
from it?

On Mon, Nov 23, 2015 at 8:29 AM, Sam Padgett notifications@github.com
wrote:

I guess it's not too bad in Firefox.

[image: openshift_web_console]
https://cloud.githubusercontent.com/assets/1167259/11337615/4168687c-91bc-11e5-9d59-a3faa0e07362.png

—
Reply to this email directly or view it on GitHub
#5997 (comment).

[spadgett]

It's similarly sized to the other inputs and looks OK positioned under the label. I think it makes the form look more consistent.

[spadgett]

I feel like our default should be to use the bootstrap/patternfly classes unless there's a good reason not to.

[jwforres]

So just following up here on the discussion we had in person. So we will go with the bootstrap style for the selects. We will add the ability to add routes from 1) a service page (service will be pre-set in the route's to field), 2) from the overview if the service does not have a route already, and 3) from the Routes page (we'll give you a list of services to route to, should we make this a typeahead list?)

What we will not attempt to do now is routes that don't route to a service.

[spadgett]

Added some support for creating routes outside of the create flow.

[spadgett]

Add route link on overview:

[spadgett]

@Kargakis FYI

[jwforres]

typo on spec

[jwforres]

One other thought, in the ports dropdown, should we be showing the name in addition to the port number when its a named port? http (8080) or 8080 (http)

[spadgett]

One other thought, in the ports dropdown, should we be showing the name in addition to the port number when its a named port? http (8080) or 8080 (http)

Hm, I think it will be used since that is the only value we have for targetPort. If the service points to a named port, we don't even know the number.

[jwforres]

ah yep, was thinking of how the port stuff is structured on the pod template

On Tue, Dec 1, 2015 at 3:45 PM, Sam Padgett notifications@github.com
wrote:

One other thought, in the ports dropdown, should we be showing the name in
addition to the port number when its a named port? http (8080) or 8080
(http)

Hm, I think it will be used since that is the only value we have for
targetPort. If the service points to a named port, we don't even know the
number.

—
Reply to this email directly or view it on GitHub
#5997 (comment).

[jwforres]

LGTM, can merge after the rebase against ben's stuff

[pweil-]

If the service points to a named port, we don't even know the number.

Since @Kargakis just went through an issue with expose when dealing with ports I want to make sure we don't run into the same thing here. To be clear, the port on the route is matching to a port in the endpoints - not the service. The router bypasses the service completely and routes straight to the endpoints.

Couldn't really tell where it was pulling the ports to choose from so I thought I'd mention it just in case. @Kargakis has an upstream PR that is extracting the utility he proposed to use in this origin pr https://github.com/openshift/origin/pull/5578/files#diff-ec75dfa091437a7b426570ffde9d4cb4

[spadgett]

Thanks @pweil-. We're using the endpoint port.

[pweil-]

Thanks @pweil-. We're using the endpoint port.

👍 👍 And also, the screenshots look great!

[spadgett]

@jwforres Rebased. No real changes except picking up the ProjectsService rename and resolving some minor conflicts.

[openshift-bot]

Evaluated for origin test up to 318b0b5

[jwforres]

[merge]

[openshift-bot]

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_origin/4219/) (Image: devenv-rhel7_2858)

[openshift-bot]

Evaluated for origin merge up to 318b0b5

[openshift-bot]

continuous-integration/openshift-jenkins/test FAILURE (https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_origin/7592/)

[jwforres]

[merge]

[kurktchiev]

So i know this got merged in, but I will leave my 2c here as I did last night at MeetUp at the Tower. In just about all my work flows I find myself needing to do multiple routes (say http/https) at the same time. It would be nice if you could, queue these up and add on another route and have all of the ones created in one swoop rather than having to go in and out of the creation process multiple times

[jwforres]

In your workflow are you creating routes primarily during the "Add to
Project" create flow, or after the fact when you want to expose an existing
service

On Wed, Dec 2, 2015 at 2:24 PM, Boris Kurktchiev notifications@github.com
wrote:

So i know this got merged in, but I will leave my 2c here as I did last
night at MeetUp at the Tower. In just about all my work flows I find myself
needing to do multiple routes (say http/https) at the same time. It would
be nice if you could, queue these up and add on another route and have all
of the ones created in one swoop rather than having to go in and out of the
creation process multiple times

—
Reply to this email directly or view it on GitHub
#5997 (comment).

[spadgett]

@ebalsumgo Thanks for your feedback. For the http/https case specifically, is there a reason you don't create one edge route that allows insecure traffic?

[kurktchiev]

@jwforres @spadgett it wasn't working in 3.0.2 (http/https) so thats why I got in the habit of creating multiple routes I suppose, but yes the secure/nonsecure for sure should be fine (though based on the mockup I saw last night, I would say it needs to be clearer what enabling EDGE termination actually accomplishes for you). for @jwforres specific question, I would love to have it exposed during the Add to Project phase as it would make it the easiest/simplest for my user base (read non tech savvy people).

[jwforres]

Ok i opened an issue, we can continue discussion there #6174