status: Report tls routes with unspecified termination type #6078

0xmichalis · 2015-11-25T14:57:39Z

deads2k · 2015-11-25T15:00:24Z

@jwforres @spadgett updating status to highlight borked routes here.

deads2k · 2015-11-25T15:09:14Z

I think this is the straw that breaks the camel's back. We need to provide advice for how to resolve these problems in a structured way. This particular one is valuable because there are only a few reasonable options for fix this problem. See #4189

Can you start adding the structure here? The marker would need an Advice or ResolutionMessage or some such thing that can describe how to fix the problem.

Even its just displayed on a separate line in the default view, it would be a starting point for us to start fixing up the markers.

0xmichalis · 2015-11-25T15:15:47Z

Can you start adding the structure here? The marker would need an Advice or ResolutionMessage or some such thing that can describe how to fix the problem.

Sure thing

0xmichalis · 2015-11-30T13:42:30Z

@deads2k this is ready for review.

deads2k · 2015-11-30T13:56:58Z

pkg/cmd/cli/cmd/status.go

 },
 }

- cmd.Flags().StringVarP(&outputFormat, "output", "o", outputFormat, "Output format. One of: dot.")
+ cmd.Flags().StringVarP(&opts.outputFormat, "output", "o", opts.outputFormat, "Output format. One of: dot.")
+ cmd.Flags().BoolVar(&opts.suggest, "suggest", opts.suggest, "Make suggestions for possible warnings/errors.")


@fabianofranz thoughts on a the flag name?

@Kargakis "Get automated suggestions for resolving errors and warnings"?

Get automated suggestions for resolving errors and warnings

Better than what I had, thanks

--suggest sounds good to me. Other ideas: --hints, --tips. We could use something more generic if we plan to add things other than suggestions in future, like --verbose.

If the final format is

* this is the error fix: this is how you fix it

then another idea is --fix or --fixes or --suggested-fixes.

fabianofranz · 2015-11-30T18:35:06Z

If there are suggestible errors, we may want a message to hint about the flag in the end, e.g. use --suggest for suggested fixes for the listed errors etc.

smarterclayton · 2015-11-30T19:52:01Z

How excessive are the fix messages going to be?

On Mon, Nov 30, 2015 at 1:35 PM, Fabiano Franz notifications@github.com
wrote:

If there are suggestible errors, we may want a message to hint about the
flag in the end, e.g. use --suggest for suggested fixes for the listed
errors etc.

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

deads2k · 2015-11-30T19:55:04Z

How excessive are the fix messages going to be?

Hard to know. I'm sure it will vary by person and by problem. Are you considering whether we should have it on by default or always have it on?

deads2k · 2015-11-30T19:55:51Z

Hard to know. I'm sure it will vary by person and by problem. Are you considering whether we should have it on by default or always have it on?

As a for instance. @Kargakis suggested oc edit. I might have actually put three complete oc patch commands that could be copied and pasted.

smarterclayton · 2015-12-01T00:31:29Z

Hrm - if a user must fix it, they need to know how to fix it. So some
verbosity is expected for anything that must be fixed. But, we don't have
to be completely proscriptive if the user can figure it out correctly.

If we think a user should always fix these, we should default the flag to on

On Nov 30, 2015, at 2:55 PM, David Eads notifications@github.com wrote:

Hard to know. I'm sure it will vary by person and by problem. Are you
considering whether we should have it on by default or always have it on?

As a for instance. @Kargakis https://github.com/kargakis suggested oc edit.
I might have actually put three complete oc patch commands that could be
copied and pasted.

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

0xmichalis · 2015-12-01T13:09:21Z

@deads2k @smarterclayton switched to one oc patch command and providing the supported termination types here. Generally I agree with @deads2k that it's hard to say how excessive the fixes will be. It seems that one line is not enough...

0xmichalis · 2015-12-01T20:41:05Z

Another thing is there are cases where we will display info level messages like "your istag is missing but a build config is pointing to it" and be able to provide suggestions like "start this build". We shouldn't prefix then with "fix: ", should we? How about "tip: " or "hint: " ?

smarterclayton · 2015-12-01T21:06:46Z

I don't like either tip or hint because they are too informal or too likely
to be viewed pejoratively. Perhaps we can go with try: or note: or info:

On Dec 1, 2015, at 3:41 PM, Michail Kargakis notifications@github.com
wrote:

Another thing is there are cases where we will display info level messages
like "your istag is missing but a build config is pointing to it" and be
able to provide suggestions like "start this build". We shouldn't prefix
then with "fix: ", should we? How about "tip: " or "hint: " ?

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

0xmichalis · 2015-12-02T10:38:15Z

I like try since it replaces the first verb in the suggestion sentence plus it's small. Currently:

[vagrant@localhost sample-app]$ oc create -f ../../pkg/api/graph/test/route-cruft.yaml 
route "etcd-cruft" created
service "doesntmatter" created

[vagrant@localhost sample-app]$ oc status
In project test on server https://localhost:8443

svc/doesntmatter - 172.30.173.91:5432 -> 8080
  exposed by route/etcd-cruft

Warnings:
  * route/etcd-cruft has a tls configuration but no termination type specified.

There are some suggestions for the info/warnings/errors listed above.
Run 'oc status --suggest' to see them.

To see more, use 'oc describe <resource>/<name>'.
You can use 'oc get all' to see a list of other objects.

[vagrant@localhost sample-app]$ oc status --suggest
In project test on server https://localhost:8443

svc/doesntmatter - 172.30.173.91:5432 -> 8080
  exposed by route/etcd-cruft

Warnings:
  * route/etcd-cruft has a tls configuration but no termination type specified.
    try: oc patch route/etcd-cruft -p '{"spec":{"tls":{"termination":"<type>"}}}' (replace <type> with a valid termination type: edge, passthrough, reencrypt)

To see more, use 'oc describe <resource>/<name>'.
You can use 'oc get all' to see a list of other objects.

0xmichalis · 2015-12-02T10:42:47Z

How about using two lines for the suggestion? One where we suggest the fix, and optionally one more that describes any changes that need to happen in the command to be properly functional (like what I am doing above) ?

deads2k · 2015-12-02T12:44:16Z

How about using two lines for the suggestion? One where we suggest the fix, and optionally one more that describes any changes that need to happen in the command to be properly functional (like what I am doing above) ?

I like "try:" and I think its clear enough on the one line.

Everyone happy with the flag --suggest and happy enough with the output?

smarterclayton · 2015-12-02T13:06:27Z

Note acronyms (tls) should ALWAYS be capitalized (TLS)

On Dec 2, 2015, at 5:38 AM, Michail Kargakis notifications@github.com
wrote:

I like try since it replaces the first verb in the suggestion sentence plus
it's small. Currently:

[vagrant@localhost sample-app]$ oc create -f
../../pkg/api/graph/test/route-cruft.yaml
route "etcd-cruft" created
service "doesntmatter" created

[vagrant@localhost sample-app]$ oc status
In project test on server https://localhost:8443

svc/doesntmatter - 172.30.173.91:5432 -> 8080
exposed by route/etcd-cruft

Warnings:

route/etcd-cruft has a tls configuration but no termination type specified.

There are some suggestions for the info/warnings/errors listed above.
Run 'oc status --suggest' to see them.

To see more, use 'oc describe /'.
You can use 'oc get all' to see a list of other objects.

[vagrant@localhost sample-app]$ oc status --suggest
In project test on server https://localhost:8443

svc/doesntmatter - 172.30.173.91:5432 -> 8080
exposed by route/etcd-cruft

Warnings:

route/etcd-cruft has a tls configuration but no termination type specified.
try: oc patch route/etcd-cruft -p
'{"spec":{"tls":{"termination":""}}}' (replace with a
valid termination type: edge, passthrough, reencrypt)

To see more, use 'oc describe /'.
You can use 'oc get all' to see a list of other objects.

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

deads2k · 2015-12-02T13:16:41Z

code lgtm.

Waiting before merge to allow later risers a chance to comment on flag name and text.

0xmichalis · 2015-12-02T13:17:26Z

(updated to TLS)

spadgett · 2015-12-02T13:39:21Z

Is there a corresponding issue already for the web console?

Edit: Opened #6162

0xmichalis · 2015-12-02T14:06:54Z

@spadgett mind opening one for #6092 too?

spadgett · 2015-12-02T14:15:59Z

@Kargakis Thanks, added a comment to #6162. I think we can add both warnings at once in the UI.

smarterclayton · 2015-12-02T15:11:06Z

Hold on merge, I have a few comments about this in general.

On Dec 2, 2015, at 8:16 AM, David Eads notifications@github.com wrote:

code lgtm.

Waiting before merge to allow later risers a chance to comment on flag name
and text.

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

smarterclayton · 2015-12-03T19:52:03Z

I'm no longer convinced we want to show all suggestions by default. I think we should display the count of suggestions and fixes at the end and make it obvious, then instruct to use --suggest or -v (verbose) to get the details. We should not show the "oc describe" line in this case. If the user specifies -v, show both suggestions and fixes. This gives us more room for items.

I would want the count to say "warning: 3 issues identified, use -v to see suggestions"

0xmichalis · 2015-12-03T20:27:13Z

I would want the count to say "warning: 3 issues identified, use -v to see suggestions"

We already use warnings for warning level messages. Any other more appropriate word here?

smarterclayton · 2015-12-03T20:49:51Z

Aren't these warnings?

On Thu, Dec 3, 2015 at 3:27 PM, Michail Kargakis notifications@github.com
wrote:

I would want the count to say "warning: 3 issues identified, use -v to see
suggestions"

We already use warnings for warning level messages. Any other more
appropriate word here?

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

deads2k · 2015-12-09T18:47:21Z

If we have -v, it seems like --suggest is extraneous. If I want suggestions, I think I'd also want the warnings.

0xmichalis · 2015-12-09T18:49:25Z

If we have -v, it seems like --suggest is extraneous. If I want suggestions, I think I'd also want the warnings.

Should I change it to --verbose or use only the shorthand?

deads2k · 2015-12-09T18:54:28Z

Should I change it to --verbose or use only the shorthand?

Well, I've never wanted to type --verbose. Take your pick, I don't feel strongly. Just don't wire --suggest to -v, because I'd lose my mind :)

smarterclayton · 2015-12-10T00:36:07Z

Let's just remove --suggest. -v is what users expect.

On Dec 9, 2015, at 1:54 PM, David Eads notifications@github.com wrote:

Should I change it to --verbose or use only the shorthand?

Well, I've never wanted to type --verbose. Take your pick, I don't feel
strongly. Just don't wire --suggest to -v, because I'd lose my mind :)

0xmichalis · 2015-12-10T11:34:43Z

Removed --suggest in favor of -v and --verbose (is there a way to define only a shorhand?) and bumped a couple of markers to error severity. PTAL

deads2k · 2015-12-10T13:24:16Z

pkg/cmd/cli/describe/projectstatus.go

 if errorMarkers := allMarkers.BySeverity(osgraph.ErrorSeverity); len(errorMarkers) > 0 {
 fmt.Fprintln(out, "Errors:")
 for _, marker := range errorMarkers {
+ errors++


errors = len(errorMarkers) ?

I knew something was wrong with this.

0xmichalis · 2015-12-10T13:56:00Z

Updated as per latest comments

[vagrant@localhost sample-app]$ oc status
In project test on server https://localhost:8443

svc/database - 172.30.104.128:5434 -> 3306
  dc/database deploys docker.io/openshift/mysql-55-centos7:latest 
    #1 deployment running for 3 seconds

svc/doesntmatter - 172.30.43.51:5432 -> 8080
  exposed by route/etcd-cruft

svc/frontend - 172.30.219.167:5432 -> 8080
  dc/frontend deploys imagestreamtag/origin-ruby-sample:latest <-
    bc/ruby-sample-build builds https://github.com/openshift/ruby-hello-world.git with test/ruby-22-centos7:latest 
      not built yet
    #1 deployment waiting on image or update
  exposed by route/route-edge

Errors:
  * route/etcd-cruft has a TLS configuration but no termination type specified.

1 error and 1 warning identified, use 'oc status -v' to see details.

[vagrant@localhost sample-app]$ oc status -v 
In project test on server https://localhost:8443

svc/database - 172.30.104.128:5434 -> 3306
  dc/database deploys docker.io/openshift/mysql-55-centos7:latest 
    #1 deployment running for 8 seconds

svc/doesntmatter - 172.30.43.51:5432 -> 8080
  exposed by route/etcd-cruft

svc/frontend - 172.30.219.167:5432 -> 8080
  dc/frontend deploys imagestreamtag/origin-ruby-sample:latest <-
    bc/ruby-sample-build builds https://github.com/openshift/ruby-hello-world.git with test/ruby-22-centos7:latest 
      #1 build running for 4 seconds
    #1 deployment waiting on image or update
  exposed by route/route-edge

Errors:
  * route/etcd-cruft has a TLS configuration but no termination type specified.
    try: oc patch route/etcd-cruft -p '{"spec":{"tls":{"termination":"<type>"}}}' (replace <type> with a valid termination type: edge, passthrough, reencrypt)
Warnings:
  * The image trigger for dc/frontend will have no effect because imagestreamtag/origin-ruby-sample:latest does not exist but bc/ruby-sample-build points to imagestreamtag/origin-ruby-sample:latest.

To see more, use 'oc describe <resource>/<name>'.
You can use 'oc get all' to see a list of other objects.

deads2k · 2015-12-10T13:59:33Z

lgtm [merge]

0xmichalis · 2015-12-10T15:30:48Z

FAIL
coverage: 59.2% of statements
FAIL    github.com/openshift/origin/pkg/cmd/cli/describe    0.647s

Updated our tests to run in verbose mode.

0xmichalis · 2015-12-10T16:32:08Z

#6259 flake

re[merge]

0xmichalis · 2015-12-10T17:40:27Z

@bparees @csrwng have you seen this before?
https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_origin/4285/consoleFull

failed  TestBuildDeleteController

0xmichalis · 2015-12-10T18:02:40Z

[merge]

openshift-bot · 2015-12-10T18:05:23Z

[Test]ing while waiting on the merge queue

csrwng · 2015-12-10T18:09:51Z

@Kargakis @deads2k Seems like an issue initializing the default cluster policy?

I1210 12:17:13.688094   29314 ensure.go:174] No cluster policy found.  Creating bootstrap policy based on: /tmp/openshift-integration/openshift.local.config/master/policy.json
I1210 12:17:13.688193   29314 decoder.go:141] decoding stream as JSON
I1210 12:17:19.970676   29314 trace.go:57] Trace "Update *api.ClusterPolicy" (started 2015-12-10 12:17:13.73913983 -0500 EST):
[6.231512754s] [6.231512754s] END
E1210 12:17:19.970707   29314 ensure.go:177] Error creating bootstrap policy: clusterpolicy "default" cannot be updated: the object has been modified; please apply your changes to the latest version and try again
E1210 12:17:19.971543   29314 ensure.go:161] Unable to create default security context constraint privileged.  Got error: User "system:openshift-master" cannot create securitycontextconstraints at the cluster scope
E1210 12:17:19.972140   29314 ensure.go:161] Unable to create default security context constraint nonroot.  Got error: User "system:openshift-master" cannot create securitycontextconstraints at the cluster scope
E1210 12:17:19.972712   29314 ensure.go:161] Unable to create default security context constraint hostmount-anyuid.  Got error: User "system:openshift-master" cannot create securitycontextconstraints at the cluster scope

openshift-bot · 2015-12-10T18:10:30Z

Evaluated for origin test up to 73597be

deads2k · 2015-12-10T18:11:23Z

@Kargakis @deads2k Seems like an issue initializing the default cluster policy?

Not one I've seen before. Maybe.

smarterclayton · 2015-12-10T18:17:19Z

I think I opened a test-flake issue for this right around 3.1

On Thu, Dec 10, 2015 at 1:11 PM, David Eads notifications@github.com
wrote:

@Kargakis https://github.com/kargakis @deads2k
https://github.com/deads2k Seems like an issue initializing the default
cluster policy?

Not one I've seen before. Maybe.

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

openshift-bot · 2015-12-10T19:00:27Z

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

openshift-bot · 2015-12-10T19:25:23Z

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

0xmichalis · 2015-12-10T19:35:14Z

[ ERR] Gave up waiting for: 'oc get rc/failing-dc-1 --template={{.metadata.annotations}} | grep openshift.io/deployment.phase:Failed'
!!! Error in hack/../test/end-to-end/core.sh:283
    'return 1' exited with status 1
Call stack:
    1: hack/../test/end-to-end/core.sh:283 main(...)
Exiting with status 1

[FAIL] !!!!! Test Failed !!!!

We need to bump the timeout for this test. Opened #6262

[merge]

openshift-bot · 2015-12-10T19:40:20Z

Evaluated for origin merge up to 73597be

…ion-in-tls-config Merged by openshift-bot

0xmichalis mentioned this pull request Nov 25, 2015

Require tls termination in route tls configuration #6076

Merged

deads2k reviewed Nov 30, 2015
View reviewed changes

spadgett mentioned this pull request Dec 2, 2015

UI should warn when route has TLS config, but no termination #6162

Closed

status: Report tls routes with unspecified termination type

8f61adf

deads2k reviewed Dec 10, 2015
View reviewed changes

Add suggestions in oc status

73597be

openshift-bot pushed a commit that referenced this pull request Dec 10, 2015

Merge pull request #6078 from kargakis/report-routes-w/o-tls-terminat…

4889a85

…ion-in-tls-config Merged by openshift-bot

openshift-bot merged commit 4889a85 into openshift:master Dec 10, 2015

0xmichalis deleted the report-routes-w/o-tls-termination-in-tls-config branch December 10, 2015 21:12

status: Report tls routes with unspecified termination type #6078

status: Report tls routes with unspecified termination type #6078

Conversation

0xmichalis commented Nov 25, 2015

deads2k commented Nov 25, 2015

deads2k commented Nov 25, 2015

0xmichalis commented Nov 25, 2015

0xmichalis commented Nov 30, 2015

deads2k Nov 30, 2015

Choose a reason for hiding this comment

0xmichalis Nov 30, 2015

Choose a reason for hiding this comment

fabianofranz Nov 30, 2015

Choose a reason for hiding this comment

fabianofranz Nov 30, 2015

Choose a reason for hiding this comment

fabianofranz commented Nov 30, 2015

smarterclayton commented Nov 30, 2015

deads2k commented Nov 30, 2015

deads2k commented Nov 30, 2015

smarterclayton commented Dec 1, 2015

0xmichalis commented Dec 1, 2015

0xmichalis commented Dec 1, 2015

smarterclayton commented Dec 1, 2015

0xmichalis commented Dec 2, 2015

0xmichalis commented Dec 2, 2015

deads2k commented Dec 2, 2015

smarterclayton commented Dec 2, 2015

deads2k commented Dec 2, 2015

0xmichalis commented Dec 2, 2015

spadgett commented Dec 2, 2015

0xmichalis commented Dec 2, 2015

spadgett commented Dec 2, 2015

smarterclayton commented Dec 2, 2015

smarterclayton commented Dec 3, 2015

0xmichalis commented Dec 3, 2015

smarterclayton commented Dec 3, 2015

deads2k commented Dec 9, 2015

0xmichalis commented Dec 9, 2015

deads2k commented Dec 9, 2015

smarterclayton commented Dec 10, 2015

0xmichalis commented Dec 10, 2015

deads2k Dec 10, 2015

Choose a reason for hiding this comment

0xmichalis Dec 10, 2015

Choose a reason for hiding this comment

0xmichalis commented Dec 10, 2015

deads2k commented Dec 10, 2015

0xmichalis commented Dec 10, 2015

0xmichalis commented Dec 10, 2015

0xmichalis commented Dec 10, 2015

0xmichalis commented Dec 10, 2015

openshift-bot commented Dec 10, 2015

csrwng commented Dec 10, 2015

openshift-bot commented Dec 10, 2015

deads2k commented Dec 10, 2015

smarterclayton commented Dec 10, 2015

openshift-bot commented Dec 10, 2015

openshift-bot commented Dec 10, 2015

0xmichalis commented Dec 10, 2015

openshift-bot commented Dec 10, 2015