New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@RouteURL injection doesn't work when routerHost isn't configured. #802

Closed
Ladicek opened this Issue Sep 12, 2017 · 3 comments

Comments

Projects
None yet
4 participants
@Ladicek
Contributor

Ladicek commented Sep 12, 2017

Issue Overview

@RouteURL injection doesn't work, it complains that

java.lang.RuntimeException: Could not set RouteURL value on field private java.net.URL io.openshift.booster.OpenshiftIT.url
Caused by: java.lang.IllegalArgumentException: Must specify routerHost!

This is consistent with what documentation says (http://arquillian.org/arquillian-cube/#_enrichers), but it doesn't make any sense. The route is read directly from the OpenShift API, the configured routerHost isn't even used in RouteURLEnricher, it's just being checked.

If I remove the check, build Arquillian Cube myself and use the built snapshot, it works just fine.

Expected Behaviour

routerHost configuration isn't required for injecting @RouteURL.

Current Behaviour

@RouteURL injection doesn't work when routerHost isn't configured.

Steps To Reproduce
  1. build current Arquillian Cube master locally, the following testing project depends on 1.8.1-SNAPSHOT
  2. git clone -b arquillian-cube https://github.com/Ladicek/wfswarm-rest-http.git
  3. mvn clean verify -Popenshift,openshift-it -Dnamespace.use.current=true
Additional Information

CC @rcernich as original author of RouteURLEnricher

@Ladicek Ladicek changed the title from `@RouteURL` injection doesn't work when `routerHost` isn't configured. to @RouteURL injection doesn't work when routerHost isn't configured. Sep 12, 2017

@jwendell

This comment has been minimized.

Show comment
Hide comment
@jwendell

jwendell Sep 12, 2017

Collaborator

+1. This is only necessary when the routes provided by Openshift cannot be resolved by default (think of addresses like <service>.<random-namespace-name>.svc.cluster.local).

If the route can be resolved somehow (valid dns, entry in /etc/hosts, etc), then specifying routerHost is not mandatory.

I'll put some comments on the PR.

Collaborator

jwendell commented Sep 12, 2017

+1. This is only necessary when the routes provided by Openshift cannot be resolved by default (think of addresses like <service>.<random-namespace-name>.svc.cluster.local).

If the route can be resolved somehow (valid dns, entry in /etc/hosts, etc), then specifying routerHost is not mandatory.

I'll put some comments on the PR.

@Ladicek

This comment has been minimized.

Show comment
Hide comment
@Ladicek

Ladicek Sep 12, 2017

Contributor

service-name.namespace-name.svc.cluster.local is a valid hostname of a service. I thought that routes always have publically resolvable names, otherwise there's no point in creating a route in the first place? Anyway, thanks for review!

Contributor

Ladicek commented Sep 12, 2017

service-name.namespace-name.svc.cluster.local is a valid hostname of a service. I thought that routes always have publically resolvable names, otherwise there's no point in creating a route in the first place? Anyway, thanks for review!

@rcernich

This comment has been minimized.

Show comment
Hide comment
@rcernich

rcernich Sep 12, 2017

Contributor

The names have to be resolved by somebody, which means integration with some DNS service. It's been a while since I've used any of the development packages of OpenShift and I don't know if they now integrate a DNS server for resolving routes directly. Because of that, @RouteURL was implemented in such a way that a user could specify the host IP being used for the router so we could resolve the route names directly. That said, perhaps replacing the error with a log message would work better.

Contributor

rcernich commented Sep 12, 2017

The names have to be resolved by somebody, which means integration with some DNS service. It's been a while since I've used any of the development packages of OpenShift and I don't know if they now integrate a DNS server for resolving routes directly. Because of that, @RouteURL was implemented in such a way that a user could specify the host IP being used for the router so we could resolve the route names directly. That said, perhaps replacing the error with a log message would work better.

@lordofthejars lordofthejars added the bug label Sep 13, 2017

@lordofthejars lordofthejars added this to the 1.9.0 milestone Sep 13, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment