fix: Make Neutron and OVN installation work without Kube-OVN TLS. #1349
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit works, but note all of the following:
- Octavia must also talk to the OVN NB and SB using encryption
- Aside from Octavia, this would work for new installations, however:
- it has overrides to mount a cert secret in the Neutron pods that won't
exist for already-deployed installations with Kube-OVN's `ENABLE_SSL` set
to false
- which would cause those overrides to fail
- I modified the Neutron install script to use 'ssl:' instead of 'tcp:'
- that would also fail on existing installations with `ENABLE_SSL` set
to false
So this commit needs additional work to:
1. Degrade gracefully so that an installation with `ENABLE_SSL: false` works
- with respect to the secret mount and `tcp:` and `ssl:` NB and SB
connection strings
2. Enable Octavia using TLS connections for the NB and SB for OVN
Or however we want to resolve that. Possibly, we could:
- take the NB and SB connection strings out of the Neutron install script and
use the services like `ovn-nb.kube-ovn.svc.cluster.local` for NB and SB
connections in the Neutron helm overrides, or
- modify the install script to try to use `yq` to collect whether we have
`ENABLE_SSL` set to true as it walks through the overrides so that it can
use `ssl:` or `tcp:` as appropriate in the overrides set on the helm install
on the command line.
It works in a lab like this, but has the same rough edges as the Neutron commit, namely, I put 'ssl:' in the install script and I believe it should choose or install with 'tcp:' connections where we don't have Kube-OVN TLS enabled. It felt a little hacky to put the volume mounts in `octavia_amphora_provider.yaml.j2` in addition to the base overrides, but this file ends up as `/tmp/octavia_helm_overrides.yaml` in a hyperconverged lab, and the hyperconverged lab script, invoked with `-x` for extra components (currently, k9s and _Octavia_), throws `-f /tmp/octavia_helm_overrides.yaml` on the _Octavia_ install, and that clobbers mounting the certificate for OVN, because it contains a list of volumes to mount to the pods, and that replaces the list from the base overrides. Additionally, I haven't yet verified what happens if namespace openstack doesn't actually have a `ovn-client-tls` secret, which again amounts to the as-of-yet not-fully-solved problem of detecting a cluster without _Kube-OVN_ TLS enabled and degrading gracefully Also, as when doing this with Neutron, I would like to phase out using the service IP and use service names like `ovn-nb.kube-system.svc.cluster.local`
The install scripts, etc. need to account for existing environments without Kube-OVN TLS. Here, the install script looks at the OVN chart overrides and chooses a 'tcp' or 'ssl' connection string based on whether we have `ENABLE_SSL` set for Kube-OVN. Additionally, installations without Kube-OVN TLS enabled won't have an OVN client TLS secret in the `openstack` namespace (or the `kube-system` namespace for that matter). Trying to make a volume from a non-existent secret would stop the pods from starting. k8s has an option to make a volume optional, though, so this commit also, with the secret volume in the base overrides, uses _kustomize_ to make the volume optional. I don't believe the OpenStack helm charts would allow me to put this `optional: true` flag on the volume specification for the pods directly, so I just patched in it with _kustomize_
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The install scripts, etc. need to account for existing environments without Kube-OVN TLS.
Here, the install script looks at the OVN chart overrides and chooses a 'tcp' or 'ssl' connection string based on whether we have
ENABLE_SSLset for Kube-OVN.Additionally, installations without Kube-OVN TLS enabled won't have an OVN client TLS secret in the
openstacknamespace (or thekube-systemnamespace for that matter). Trying to make a volume from a non-existent secret would stop the pods from starting. k8s has an option to make a volume optional, though, so this commit also, with the secret volume in the base overrides, uses kustomize to make the volume optional. I don't believe the OpenStack helm charts would allow me to put thisoptional: trueflag on the volume specification for the pods directly, so I just patched in it with kustomize