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

Use recommended labels #172

Merged

Conversation

jpkrohling
Copy link
Contributor

@jpkrohling jpkrohling commented Jan 18, 2019

This PR replaces the selector with a broader labels map, following the Kubernetes' recommended labels

Signed-off-by: Juraci Paixão Kröhling juraci@kroehling.de

@jpkrohling
Copy link
Contributor Author

This change is Reviewable

@jpkrohling
Copy link
Contributor Author

This is the first draft that would fix #170, intended to get a consensus on the names/values for the labels.

@harshal-shah, do you think something like this would be suitable for your use-case?

@codecov
Copy link

codecov bot commented Jan 18, 2019

Codecov Report

Merging #172 into master will increase coverage by 0.07%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #172      +/-   ##
==========================================
+ Coverage   96.38%   96.46%   +0.07%     
==========================================
  Files          30       30              
  Lines        1438     1469      +31     
==========================================
+ Hits         1386     1417      +31     
  Misses         40       40              
  Partials       12       12
Impacted Files Coverage Δ
pkg/deployment/query.go 100% <100%> (ø) ⬆️
pkg/deployment/all-in-one.go 100% <100%> (ø) ⬆️
pkg/deployment/collector.go 100% <100%> (ø) ⬆️
pkg/deployment/agent.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 1e134be...79acff3. Read the comment docs.

func (c *Collector) labels() map[string]string {
return map[string]string{
"app.kubernetes.io/name": c.name(),
"app.kubernetes.io/instance": c.jaeger.Name,
Copy link
Contributor

Choose a reason for hiding this comment

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

Looks reasonable - only one I wasn't sure about was the instance, where the docs describe it as "A unique name identifying the instance of an application" with an example of wordpress-abcxzy. But for our purpose it enables objects to be selected by various criteria.

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'll apply the same change to the other objects then. Thanks!

Copy link
Contributor

Choose a reason for hiding this comment

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

Don't forget we will also need to support the app label for a while - was thinking that should be same as app.kubernetes.io/name value?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Do you have existing applications in mind, or is there a case of an application that still reads the app instead of app.kubernetes.io? If it's about maintaining backwards compatibility, we need to keep app: jaeger.

Copy link
Contributor

Choose a reason for hiding this comment

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

I guess the two areas to consider is:

  1. Istio - which needs the app label and app:jaeger should be fine
  2. Kiali - raised by Jay? where unique app label seemed to be a problem - but possibly this is not a blocker

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If they are also moving to use app.kubernetes.io instead of app, then I'd keep app: jaeger for backwards compatibility.

Copy link
Contributor

Choose a reason for hiding this comment

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

Unclear what the timeframe is for them changing, but yes probably the best approach.

@jpkrohling jpkrohling changed the title WIP - Use recommended labels Use recommended labels Jan 21, 2019
@jpkrohling
Copy link
Contributor Author

This is now ready to be reviewed.

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 - although might be good to have some tests?

@jpkrohling
Copy link
Contributor Author

Tests added

@objectiser
Copy link
Contributor

Thanks 👍

Signed-off-by: Juraci Paixão Kröhling <juraci@kroehling.de>
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