Skip to content
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

Add support for OpenShift routes #93

Merged

Conversation

jpkrohling
Copy link
Contributor

@jpkrohling jpkrohling commented Nov 7, 2018

Closes #88

Signed-off-by: Juraci Paixão Kröhling [email protected]

Signed-off-by: Juraci Paixão Kröhling <[email protected]>
@jpkrohling jpkrohling requested a review from objectiser November 7, 2018 13:41
@jpkrohling
Copy link
Contributor Author

This change is Reviewable

@codecov
Copy link

codecov bot commented Nov 7, 2018

Codecov Report

Merging #93 into master will increase coverage by 0.03%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #93      +/-   ##
==========================================
+ Coverage   99.35%   99.39%   +0.03%     
==========================================
  Files          18       19       +1     
  Lines         776      822      +46     
==========================================
+ Hits          771      817      +46     
  Misses          5        5
Impacted Files Coverage Δ
pkg/controller/all-in-one.go 100% <100%> (ø) ⬆️
pkg/route/query.go 100% <100%> (ø)
pkg/controller/production.go 100% <100%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 61150a9...2eb0d4c. Read the comment docs.

Copy link
Contributor

@objectiser objectiser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only done a partial review at present, as might be good to resolve a couple of the points first in case may lead to significant changes.

README.adoc Outdated
@@ -149,18 +149,13 @@ NAME HOSTS ADDRESS PORTS AGE
simplest-query * 192.168.122.34 80 3m
----

IMPORTANT: an `Ingress` object is *not* created when the operator is started with the `--openshift=true` flag as, such as when using the resource `operator-openshift.yaml`.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the "as" following flag can be removed?

----

Check the hostname/port with the following command:
When using the `operator-openshift.yaml` resource, the Operator will automatically create a `Route` object for the query services. Check the hostname/port with the following command:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Possibly the route should only be created if ingress.enabled is true? So it has similar behaviour but just has a platform specific outcome.

ports:
- containerPort: 60000
name: metrics
args: ["start", "--openshift=true"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any way this can be auto-detected? Avoid having separate operator.yaml if possible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have started a discussion in the Operator SDK mailing list about this, but I think we want a flag anyway, to explicitly set a target, bypassing the auto-detection.

@@ -32,6 +32,7 @@ type JaegerSpec struct {
Agent JaegerAgentSpec `json:"agent"`
Storage JaegerStorageSpec `json:"storage"`
Ingress JaegerIngressSpec `json:"ingress"`
Route JaegerRouteSpec `json:"route"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned above - it would be good if route and ingress could be treated as same concept. If at some point in the future there are reasons to have platform specific "ingress" related options, then these could go in platform specific sub-specs?

viper.BindPFlag("jaeger-cassandra-schema-image", cmd.Flags().Lookup("jaeger-cassandra-schema-image"))

cmd.Flags().Bool("openshift", false, "Whether the operator should use OpenShift-specific features, like Routes and OAuth proxy for the UIs")
viper.BindPFlag("openshift", cmd.Flags().Lookup("openshift"))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned before, would be great if this could be auto-detected - but if not easy to do for now, then might be better to have a platform option, which defaults to kubernetes and openshift is another valid value.

@jpkrohling jpkrohling force-pushed the Support-for-OpenShift-Routes branch from 848e855 to 78de5ca Compare November 7, 2018 15:06
@jpkrohling
Copy link
Contributor Author

This is now ready for a second review round.

Copy link
Contributor

@objectiser objectiser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - just wanted to discuss the structure for platform specific components.

// FlagPlatformOpenShift represents the value for the 'platform' flag for OpenShift
FlagPlatformOpenShift = "openshift"

// FlagPlatformKubernetes represents the value for the 'platform' flag for Kubernetes
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: move kubernetes up as the first option - don't want to show favouritism :)

qi := ingress.NewQueryIngress(c.jaeger).Get()
if nil != qi {
os = append(os, qi)
if viper.GetString("platform") == v1alpha1.FlagPlatformOpenShift {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it worth moving this platform specific difference into the pkg/ingress package so reused in production strategy as well - and localises the platform differences?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this kind of logic actually belongs to the controller, as it's the part that decides what should get created (as opposed to the "how", which is inside the specific object packages).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok sounds reasonable.

Signed-off-by: Juraci Paixão Kröhling <[email protected]>
Copy link
Contributor

@objectiser objectiser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 12 of 24 files at r1, 10 of 12 files at r2, 1 of 1 files at r3.
Reviewable status: all files reviewed, 6 unresolved discussions (waiting on @objectiser)

Copy link
Contributor

@objectiser objectiser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

Reviewable status: all files reviewed, 6 unresolved discussions (waiting on @objectiser)

Copy link
Contributor

@objectiser objectiser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: :shipit: complete! all files reviewed, all discussions resolved

@objectiser objectiser merged commit 8d705b9 into jaegertracing:master Nov 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants