-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pre 0.8.0 flagd-proxy service does not contain managed-by label #719
Comments
@beeme1mr I personally think it's sufficient to add a warning to the 0.8.0 release for this as a breaking change, wdyt? |
Does ownership have to be validated via checking for that label? I can see in a previous version of the Service resource for flagd-proxy that it contains ownerReferences in the metadata, and the managed-by field within the selector in the spec. I'm making naive assumptions that these fields are all injected and accessible so might not be possible, but wondering if they could be used to validate ownership instead of the label? Eg: Older version Service resource pre- 0.8.0 apiVersion: v1
kind: Service
metadata:
creationTimestamp: XXXX-XX-XXTXX:XX:17Z
name: flagd-proxy-svc
namespace: XXXX
ownerReferences:
- apiVersion: apps/v1
kind: Deployment
name: open-feature-operator-controller-manager # <-- here
uid: XXXXXXXXXX
resourceVersion: "XXXX"
uid: 689f2c91-b183-4d4f-a295-26f27402b5d6
spec:
clusterIP: XX.XXX.XXX.XX
clusterIPs:
- XX.XXX.XXX.XX
internalTrafficPolicy: Cluster
ipFamilies:
- IPv4
ipFamilyPolicy: SingleStack
ports:
- xxx
selector:
app.kubernetes.io/managed-by: open-feature-operator # <-- here
app.kubernetes.io/name: flagd-proxy
sessionAffinity: None
type: ClusterIP
status:
loadBalancer: {} New service resource post 0.8.0 update: apiVersion: v1
kind: Service
metadata:
creationTimestamp:XXXX-XX-XXTXX:XX:17Z
labels:
app.kubernetes.io/managed-by: open-feature-operator # <-- new / easily added manually if needed
name: flagd-proxy-svc
namespace: flags-system
ownerReferences:
- apiVersion: apps/v1
kind: Deployment
name: open-feature-operator-controller-manager
uid: xxxxxx
resourceVersion: "xxxxxx"
uid: xxxxx xx
spec:
clusterIP: xx.xxx.xxx.xxx
clusterIPs:
- xx.xxx.xxx.xxx
internalTrafficPolicy: Cluster
ipFamilies:
- IPv4
ipFamilyPolicy: SingleStack
ports:
- xxxx
selector:
app.kubernetes.io/managed-by: open-feature-operator
app.kubernetes.io/name: flagd-proxy
sessionAffinity: None
type: ClusterIP
status:
loadBalancer: {} Example diff:
|
I'd personally use the ownerReference as well, but I assumed the decision to use a label has been taken on purpose. |
Changes introduced in #712 do not only validate the ownership of the flagd-proxy deployment but also the service, which leads to the service not being managed further by the OFO.
This only affects installations prior to 0.8.0 with flagd-proxy enabled.
A fix for this issue is to manually label the affected resource:
The text was updated successfully, but these errors were encountered: