- 18 Oct, 2021 6 commits
-
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
This is necessary even if the controller is otherwise restricted to a namespace. So we add a new ClusterRole to add the RBAC read rights (wath, list and get) unconditionally for any controller instance.
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
-
- 14 Oct, 2021 1 commit
-
-
Geoff Simmons authored
Verified with the hello world example using kubectl/yaml deployment. The other tests/examples, including all helm deployments, do not work as of this commit, until they are adapted to the new logic for configuring the Ingress class.
-
- 12 Oct, 2021 2 commits
-
-
Geoff Simmons authored
-
Geoff Simmons authored
-
- 05 Oct, 2021 1 commit
-
-
Geoff Simmons authored
Its two fields are mapped directly to the ttl and ttl_from parameters of VMOD dynamic.
-
- 28 Sep, 2021 3 commits
-
-
Geoff Simmons authored
We now work with Ingress from the API group networking.k8s.io. Ingress in the extensions API group is no longer supported. This entails: - update RBAC grants - update client-go code - update the examples/tests, currently only using helm deployments - changes in the Ingress backend and service fields - for now we only test pathType:ImplementationSpecific, implemented as posix_type re2 matches, which had been the match implementation prior to this change. viking will support the Match and Prefix pathTypes, but in this iteration, it was not necessary to change the code to support the ImplementationSpecific pathType. Examples/tests with kubectl deployments and plain YAML manifests will also be updated in an upcoming iteration.
-
Geoff Simmons authored
-
Geoff Simmons authored
-
- 22 Sep, 2021 3 commits
-
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
In this commit, the code compiles and passes make check. But we currently can't test anything else, because the manifests/charts still use API groups that are obsolete in this k8s version.
-
- 21 Sep, 2021 1 commit
-
-
Geoff Simmons authored
-
- 20 Sep, 2021 1 commit
-
-
Geoff Simmons authored
Cf. ab85c9bb and c3f7a9a9
-
- 17 Sep, 2021 7 commits
-
-
Geoff Simmons authored
-
Geoff Simmons authored
The replica scaling test for self-sharding requires the Deployment name "varnish-ingress" for the viking service.
-
Geoff Simmons authored
This is the SNI sent in the client TLS connection to a backend. We use VMOD dynamic for backends represented by an ExternalName Service (likely the common use case for TLS onload). VMOD dynamic does not have the authority field that klarlack makes available for standard backends. But if the host_header field is set for a VMOD dynamic director, the VMOD uses that value for the SNI. So if the BackendConfig authority field is set, we also assign its value to the host_header field. Since BackendConfig also has a separate field for host_header, both of them could be conceivably set to different values. If we find that the two fields are set to non-empty, conflicting values, the controller emits a SyncFatalError, and the BackendConfig is not synced.
-
Geoff Simmons authored
-
Geoff Simmons authored
-
Geoff Simmons authored
This uses haproxy for TLS connections to IngressBackends, and the via feature of the klarlack implementation of Varnish. See: https://github.com/varnishcache/varnish-cache/pull/3128 Adds the spec.tls object to the BackendConfig CRD, which configures TLS onload for a backend. Limitations: currently only verify:false and the maxConn settings are implemented. Specification of CA certificates and the stick table configuration for haproxy are not yet implemented. Currently TLS onload may be only specified for one backend (no more than one BackendConfig). Adds the CLI option -varnishImpl to the controller. TLS onload is only supported if this option is set to "klarlack". Otherwise, the presence of the tls object in a BackendConfig leads to a SyncFatalError, with a message that it's only supported for klarlack, and the BackendConfig is not synced. If the backend Service specified for TLS onload has type ExternalName, then 3 server instances are configured for the haproxy backend. This value is currently hard-wired, and may be made configurable in a future iteration. For any other Service type, there are as many haproxy server instances as there are Endpoints (Pods) in the k8s cluster. If maxConn is not specified in the BackendConfig, it defaults to 2000 (the haproxy default).
-
Geoff Simmons authored
-
- 03 Sep, 2021 15 commits
-
-
Nils Goroll authored
-
Nils Goroll authored
See c3f7a9a9
-
Nils Goroll authored
-
Nils Goroll authored
If changes did not trigger a klarlack build, gitlab CI would file this complaint: Found errors in your .gitlab-ci.yml: 'build:ascn' job needs 'build:klarlack' job but 'build:klarlack' is not in any previous stage despite the fact that the ci file lints just fine. IIUC, the issue is that for the triggered pipeline, the klarlack build job just would not exist. In this case, we can build ascn on top of the previous klarlack build.
-
Nils Goroll authored
Does this help?
-
Nils Goroll authored
because of: Step 5/20 : RUN go get -d -v github.com/slimhazard/gogitversion && cd /go/src/github.com/slimhazard/gogitversion && make install ---> Running in 8a50294f4b5c github.com/slimhazard/gogitversion (download) godoc -html . | pandoc -f html -t markdown_github > README.md /bin/sh: 1: pandoc: not found /bin/sh: 1: godoc: not found make: *** [Makefile:36: README.md] Error 127
-
Nils Goroll authored
-
Nils Goroll authored
see - e6645a38 - c488a3b1
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
-
Nils Goroll authored
Dependencies: did not do what I expected it to
-
Nils Goroll authored
-
Nils Goroll authored
I hope this works
-
Nils Goroll authored
-