You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 19, 2024. It is now read-only.
In a separate terminal, apply any of the examples, e.g. examples/bs1.yaml:
kubectl apply -f examples/bs1.yaml
Inspect the local DB StatefulSet and the Services created by the operator
kubectl get statefulset --selector=app.kubernetes.io/name=backstage,app.kubernetes.io/instance=bs1 -o yaml | yq '.items[0].spec'
kubectl get service --selector=app.kubernetes.io/name=backstage,app.kubernetes.io/instance=bs1
Actual behavior
Here are the services created by the operator:
$ kubectl get service --selector=app.kubernetes.io/name=backstage,app.kubernetes.io/instance=bs1
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
backstage-bs1 ClusterIP 172.31.39.19 <none> 80/TCP 6m36s
backstage-db-bs1 ClusterIP 172.31.20.189 <none> 5432/TCP 6m36s
And the spec of the DB StatefulSet, where we can see that spec.serviceName is hardcoded to backstage-psql-cr1-hl (and spec.template.metadata.name is also hardcoded to backstage-db-cr1, but this might not be an issue per se).
Per the official K8s docs, a Headless Service is required for StatefulSets and must exist:
StatefulSets currently require a Headless Service to be responsible for the network identity of the Pods. You are responsible for creating this Service
Not sure why K8s does not return an error with this non-existing service, but the expected behavior would be:
spec.serviceName should not be hardcoded. Instead, it can have a value like backstage-psql-<cr_name>-hl (and this headless service should be created by the operator as well)
spec.template.metadata.name should not be hardcoded. Instead, it can have a value like backstage-psql-<cr_name>
rm3l
changed the title
spec.serviceName field in local DB StatefulSet spec is hardcoded and not correctspec.serviceName field in local DB StatefulSet operand is hardcoded and not correct
May 29, 2024
Our StatefulSet has never worked with headless service which mean only 1 replica configuration would be working correct.
Indeed, to make it work correct with more than one Pod-PV it has to be headless service instead of load-balancing one.
I would not qualify it as a bug though, it is rather a limitation for local (not recommended for production) database schema and, again, it has never worked with headless service yet.
spec.serviceName should not be hardcoded. Instead, it can have a value like backstage-psql-<cr_name>-hl (and this >headless service should be created by the operator as well)
I do not see why we need "-hl" and "non-hl" service here. If it will work with headless, let's leave only it (backstage-psql-<cr_name> as a serviceName).
spec.template.metadata.name should not be hardcoded. Instead, it can have a value like backstage-psql-<cr_name>
Unfortunatelly, looks like Statefulsert does not respect it (otherwise, there were no needs in renaming SS). The template for Pod names are still - . We can just remove it
/kind bug
Follow-up issue discovered while working on #369
What versions of software are you using?
What did you run exactly?
examples/bs1.yaml
:Actual behavior
spec.serviceName
is hardcoded tobackstage-psql-cr1-hl
(andspec.template.metadata.name
is also hardcoded tobackstage-db-cr1
, but this might not be an issue per se).StatefulSet spec
Expected behavior
Per the official K8s docs, a Headless Service is required for StatefulSets and must exist:
Not sure why K8s does not return an error with this non-existing service, but the expected behavior would be:
spec.serviceName
should not be hardcoded. Instead, it can have a value likebackstage-psql-<cr_name>-hl
(and this headless service should be created by the operator as well)spec.template.metadata.name
should not be hardcoded. Instead, it can have a value likebackstage-psql-<cr_name>
Any logs, error output, etc?
The text was updated successfully, but these errors were encountered: