Skip to content
This repository has been archived by the owner on Aug 26, 2021. It is now read-only.

Seperate concept of provider and class #202

Merged
merged 3 commits into from
Jul 5, 2017
Merged

Seperate concept of provider and class #202

merged 3 commits into from
Jul 5, 2017

Conversation

jackhopner
Copy link
Contributor

Previously you're ingress provider and classes had to have the same name. These should be two different concepts and be used in combination.

For example if you have:

Ingress classes for nginx-internal and nginx-external but want them to both be provided by nginx then if you don't have the provider and class as two different concepts this isn't possible.

Below is an example ingress resource with the new annotation:

kind: Ingress
metadata:
  name: svc-ing
  namespace: some-namespace
  annotations:
    kubernetes.io/tls-acme: "true"
    kubernetes.io/ingress.provider: "nginx"
    kubernetes.io/ingress.class: "nginx-external"
    ingress.kubernetes.io/ssl-redirect: "true"
spec:
  tls:
  - hosts:
    - example.com
    secretName: svc-tls
  rules:
  - host: example.com
    http:
      paths:
      -
        path: /something
        backend:
          serviceName: svc
          servicePort: 80

jackhopner added 2 commits June 6, 2017 11:29
Allows use of a single supported ingress class
…ovider

The "kubernetes.io/ingress.class" annotation shouldn't be used
to determine which proivder to use. There's now a "kubernetes.io/ingress.provider"
which can be "nginx" or "gce" (unless you implement your own).
@rochacon
Copy link

I like this approach more than my proposal on #195. Any updates whether this may be merged?

@jackhopner there is a couple of conflicts with master, would you be willing to fix it?

@jackhopner
Copy link
Contributor Author

@rochacon Fixed up the conflicts :)

@munnerz
Copy link
Contributor

munnerz commented Jul 5, 2017

Thanks for this!

I'm not a big fan of the kubernetes.io/ingress.provider annotation, as this really is an annotation that's specific to kube-lego only, however we already have a number of similarly prefixed annotations that are specific to kube-lego so I don't think it's a problem we should be solving in this PR.

func (i *Ingress) IngressProvider() string {
val, ok := i.IngressApi.Annotations[kubelego.AnnotationIngressProvider]
if !ok {
return i.kubelego.LegoDefaultIngressProvider()
Copy link
Contributor

Choose a reason for hiding this comment

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

After some more thought, I've realised this may break current implementations of the GCE ingress controller - please do correct me if I'm wrong...

If a user currently has an ingress that specifies
kubernetes.io/ingress.class: "gce", and no ingress.provider annotation (as they are upgrading), the ingress.provider will default to nginx, thus breaking their set up.

To work around this and perform these changes in a backwards compatible way, I think we need to set the ingress.provider value to ingress.class if it's not already defined on the ingress resource itself.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah you're right to be backwards compatible you do need to do that

@fergusstrange
Copy link

Hi @munnerz can we have a release of this please?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants