About HasIncorrectServiceConfig in updateStatus

Right now inside of updateStatus{} sub reconciliation, for the HasIncorrectServiceConfig part, the code only checks whether Headless service has some incorrect config or not, but ignores the normal services, such as ClusterIP, etc. Do you think it’s necessary to add judgement on those services? I know right now only ClusterIP is support, just assume all the four service types have been supported.

I think it make sense to add some additional checks for the “normal” services. We don’t use the service implementation currently and the right way forward (from our perspective) is to use the DNS support in 7.1. The operator already supports to use DNS in the cluster file.

If you want to extend the verification for created services, I would appreciate if you could create a GitHub issue with some concrete examples of checks that you want to perform and then you could follow up with the actual implementation of those checks.

Can you pls declare when the DNS will be officially supported?
BTW, I’ve tested DNS in FDB7.1.24, and I found it not accessible from outside using DNS connection strings. So how can we solve this problem if using DNS with no services(such as LoadBalancer that I’ve added but not submitted yet)?

The DNS support in FDB is already supported, same for the DNS support in the operator. We are only missing the documentation for it.

I’ve tested DNS in FDB 7.1.24, and I found it not accessible from outside using DNS connection strings.

Are the DNS records available outside of you Kubernetes cluster? If not, that’s expected.

So how can we solve this problem if using DNS with no services(such as LoadBalancer that I’ve added but not submitted yet)?

I don’t have such a setup to test. Using the DNS records and the LoadBalancer IPs should be possible to setup but if the DNS records are not available outside of the Kubernetes cluster it won’t help much.

If you have some ideas for improvement around the service setup (and DNS integration), feel free to create issues in the GitHub repository. Currently we don’t have to much time to implement that, so you help would be appreciated.