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

Refactor k8s rule type annotation parsing/retrieval. #1151

Conversation

timoreimann
Copy link
Contributor

Carved out of #1129.

  • Move annotation logic into function.
  • Constantify strings.
  • Refactor TestRuleType.
  • Add test for GetRuleTypeFromAnnotations.

@timoreimann timoreimann force-pushed the refactor-k8s-rule-type-annotation-logic branch from dd29713 to 69315de Compare February 12, 2017 00:33
@timoreimann
Copy link
Contributor Author

@emilevauge @errm This is the referenced, original PR trimmed done to the refactoring parts as announced.

Could you please take a look? Thanks!

tests := []struct {
desc string
ingressRuleType string
serviceRuleType string
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just realized I forgot to remove this one. Will do so later.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done!

@timoreimann timoreimann force-pushed the refactor-k8s-rule-type-annotation-logic branch from 69315de to 0d1eb9a Compare February 12, 2017 21:38
@timoreimann timoreimann force-pushed the refactor-k8s-rule-type-annotation-logic branch 3 times, most recently from d36f4ce to 1f5c33c Compare February 21, 2017 23:18
@timoreimann
Copy link
Contributor Author

@emile @SantoDE @errm @russ @dtomcej @vdemeester would be grateful for a review, thanks. :-)

Copy link
Contributor

@vdemeester vdemeester left a comment

Choose a reason for hiding this comment

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

LGTM 🐸

ruleType = "PathPrefix"
if len(pa.Path) > 0 {
ruleType, unknown := getRuleTypeFromAnnotation(i.Annotations)
switch {
Copy link
Contributor

Choose a reason for hiding this comment

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

This may be a dumb question, but If you are not switching on a variable, should you still have a default in the event that neither of the cases are matched?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not a dumb question at all!

I agree with you that there should usually be a default case when you use a switch statement in an exhaustive way: Handle all acceptable inputs and do something for the unexpected case (like returning an error).

The other type of switch usage in Go is a more readable version of multiple / nested / complex if-else statements. This one doesn't necessarily need a default case in my opinion, and it's the one I had in mind here.

Admittedly, I could have also written

if unknown {
  log.Warnf("Unknown RuleType ...")
}

if ruleType == "" {
  ruleType = ruleTypePathPrefix
}

I prefer the switch variant because I can use fallthrough to shortcut right to setting a default value in case of an unknown rule type (fallthrough ignores the condition of the following case expression) and don't need to depend onruleType having a particular value (empty string here).

If you think that two if statements would be better, I'm happy to change.

Copy link
Contributor

Choose a reason for hiding this comment

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

Nope. LGTM

@timoreimann timoreimann force-pushed the refactor-k8s-rule-type-annotation-logic branch from 1f5c33c to 12d7904 Compare February 22, 2017 18:17
Copy link
Contributor

@dtomcej dtomcej left a comment

Choose a reason for hiding this comment

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

LGTM :shipit:

@timoreimann
Copy link
Contributor Author

@vdemeester @dtomcej okay to merge?

@emilevauge
Copy link
Member

emilevauge commented Feb 23, 2017

@timoreimann I'm still not sure maintaining another rule (incomplete) list is a good idea. Rules are defined https://github.com/containous/traefik/blob/master/rules.go#L107 and again https://github.com/containous/traefik/pull/1151/files#diff-f9e99fb6bddb36d1640e40bc4bd36bc1R22 in kubernetes.go. It duplicates parsing code.
I'm sorry but I'm still considering that this solution would be a lot simpler to maintain.
@errm @dtomcej WDYT ?

@timoreimann
Copy link
Contributor Author

timoreimann commented Feb 23, 2017

@emilevauge I agree with you in general. However, the PR did not introduce any new rules: It's a refactoring (and test-extending) change only which IMHO already provides an incremental improvement over the previous state. Put in a different way, it still contains the same level of duplication but makes it more readable (agile, yay :-) ).

My suggestion would be to move forward with this PR and follow-up with some de-duplication effort afterwards. That way, we don't conflate a fairly limited and simple refactoring with a bigger change that could possibly be more difficult to design and implement.

Copy link
Contributor

@Russell-IO Russell-IO left a comment

Choose a reason for hiding this comment

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

LGTM 👍

@timoreimann
Copy link
Contributor Author

@emile @errm any further thoughts on this one?

@timoreimann timoreimann force-pushed the refactor-k8s-rule-type-annotation-logic branch from 12d7904 to f68e016 Compare March 1, 2017 13:48
- Move annotation logic into function.
- Constantify strings.
- Refactor TestRuleType.
- Add test for GetRuleTypeFromAnnotations.
@timoreimann timoreimann force-pushed the refactor-k8s-rule-type-annotation-logic branch from f68e016 to f3598e6 Compare March 3, 2017 12:33
@emilevauge
Copy link
Member

However, the PR did not introduce any new rules: It's a refactoring (and test-extending) change only which IMHO already provides an incremental improvement over the previous state. Put in a different way, it still contains the same level of duplication but makes it more readable (agile, yay :-) ).

You're right, in my opinion, we shouldn't have accepted the previous state.
Let's move on. We will really need to de-duplicate all these rules soon or later.

Copy link
Member

@emilevauge emilevauge left a comment

Choose a reason for hiding this comment

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

LGTM!

@timoreimann timoreimann deleted the refactor-k8s-rule-type-annotation-logic branch March 3, 2017 17:49
@ldez ldez added this to the 1.3 milestone May 19, 2017
@ldez ldez added kind/enhancement a new or improved feature. and removed status/3-needs-merge labels May 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants