1. 24 Jan, 2021 1 commit
  2. 14 Jan, 2021 3 commits
  3. 13 Jan, 2021 1 commit
  4. 07 Jan, 2021 1 commit
    • Geoff Simmons's avatar
      Set the "regular" config to "not available" when no Ingress is defined. · 7ca83849
      Geoff Simmons authored
      This was a remnant of earlier versions when the Pods were set to not
      Ready when there is no Ingress to implement. No the Pods are always
      ready, but we set the "configured" endpoint to respond with non-200
      when nothing is defined.
      However, if an Ingress had been defined previously, then deleted,
      the http/https endpoints still responded as for the previous config.
      This was semantically incorrect, and also meant that the VCL config
      remained defined indefinitely. Now it becomes unlabeled, so it can
      go cold and then be discarded.
  5. 06 Jan, 2021 1 commit
  6. 05 Jan, 2021 2 commits
    • Geoff Simmons's avatar
      Fix discard of VCL configs that have gone cold. · 0d9ac205
      Geoff Simmons authored
      I believe this became necessary because the meaning of the state
      and temperature fields in vcl.list has changed in recent Varnish
      versions (which we are now using).
    • Geoff Simmons's avatar
      Use Pod names to generate VCL backend name symbols. · 1e4941c4
      Geoff Simmons authored
      This makes backend names more readily recognizable in VCL sources,
      and as used in tools such as varnishlog and varnishstat. If the
      Pod ns/name is not available, fall back to the previous scheme of
      generating names from the Endpoint network addresses.
  7. 03 Jan, 2021 1 commit
  8. 01 Jan, 2021 1 commit
    • Geoff Simmons's avatar
      Evaluate Ingress rules in vcl_backend_fetch. · ae09f859
      Geoff Simmons authored
      This is possible now that we are using Varnish versions that support
      return(error(404)) from the backend side. It eliminates unnecessary
      computation when a request leads to a cache hit or synthetic response.
      It also simplifies the generated VCL code, since the evaluation
      happens in one place, rather than in each of hit, miss, pass and
  9. 31 Dec, 2020 3 commits
  10. 30 Dec, 2020 8 commits
  11. 07 Dec, 2020 1 commit
  12. 06 Dec, 2020 3 commits
  13. 04 Dec, 2020 1 commit
  14. 26 Nov, 2020 5 commits
  15. 25 Nov, 2020 2 commits
    • Geoff Simmons's avatar
      Add example/test for Service type LoadBalancer. · 9373af23
      Geoff Simmons authored
      Also set up the tests so that the external IP and port for both the
      NodePort and LoadBalancer tests. For this it is necessary to pass
      in the external cluster IP, and/or set up an external IP for the
      LoadBalancer Service.
      If neither of these are available, just use port-forwarding as for
      the other tests. That doesn't actually test the Service types, since
      connections are forwarded to the clusterIP. But the tests can be
      run in automation when the external networking is not available.
    • Geoff Simmons's avatar
  16. 24 Nov, 2020 3 commits
  17. 20 Nov, 2020 1 commit
  18. 15 Oct, 2020 2 commits
    • Geoff Simmons's avatar
    • Geoff Simmons's avatar
      Update Ingress status.loadBalancer after successful sync. · 2c879de1
      Geoff Simmons authored
      The addresses for this array are taken from the public names and/or
      IPs in the spec for Service(s) that expose the Ingress. These are
      identified as:
      - in the same namespace as the admin Service
      - have the label viking.uplex.de/svc=public
      - have the same selectors as the admin Service
      - type is one of ClusterIP, NodePort or LoadBalancer
      The label viking.uplex.de/svc is only required if the Ingress status
      update is required. For example to use a tool like ArgoCD, or if
      the cloud provider requires it.
      Set the label in the Service template for the viking-service chart.