controller does only partial cleanups
szuecs opened this issue · comments
We get in skipper logs the following errors, because we clean a svc object, but not the link to the service within ingress objects, which we should do, too:
[APP]time="2018-12-12T22:39:50Z" level=error msg="convertPathRule: Failed to get service default, cdp-e2e-cdp-cd-robot-e5eb20050a35b3d718d8fd603a20b6bf6f8934ef, ingress"
ingress
metadata:
creationTimestamp: 2018-09-04T16:04:59Z
generation: 1
labels:
deployment-id: d-2mctyfio8r3y2f535k2zocoupk
stack-version: e5eb20050a35b3d718d8fd603a20b6bf6f8934ef
stackset: cdp-e2e-cdp-cd-robot
name: cdp-e2e-cdp-cd-robot-e5eb20050a35b3d718d8fd603a20b6bf6f8934ef
namespace: default
ownerReferences:
- apiVersion: zalando.org/v1
kind: Stack
name: cdp-e2e-cdp-cd-robot-e5eb20050a35b3d718d8fd603a20b6bf6f8934ef
uid: 3fc086e8-b05c-11e8-96bd-022ad150ebe8
resourceVersion: "210581283"
spec:
rules:
- host: cdp-e2e-cdp-cd-robot-e5eb20050a35b3d718d8fd603a20b6bf6f8934ef.example.org
http:
paths:
- backend:
serviceName: cdp-e2e-cdp-cd-robot-e5eb20050a35b3d718d8fd603a20b6bf6f8934ef
servicePort: ingress
svc
% kubectl get svc cdp-e2e-cdp-cd-robot-e5eb20050a35b3d718d8fd603a20b6bf6f8934ef
Error from server (NotFound): services "cdp-e2e-cdp-cd-robot-e5eb20050a35b3d718d8fd603a20b6bf6f8934ef" not found
stackset
spec:
ingress:
hosts:
- cdp-e2e-cdp-cd-robot.example.org
stackLifecycle:
limit: 5
scaledownTTLSeconds: 300
stackTemplate:
spec:
podTemplate:
metadata:
labels:
application: cdp-e2e-cdp-cd-robot
spec:
containers:
- env:
- name: VERSION
value: e5eb20050a35b3d718d8fd603a20b6bf6f8934ef
image:___
lifecycle:
preStop:
exec:
command:
- sleep
- "5"
name: cdp-e2e-cdp-cd-robot
ports:
- containerPort: 8080
name: ingress
readinessProbe:
httpGet:
path: /health
port: 8080
replicas: 1
version: e5eb20050a35b3d718d8fd603a20b6bf6f8934ef
I believe this happens because a service is owned by a deployment while the per stack ingress is owned by the stack. So if we delete the deployment, without deleting the stack, then we have this problem.
Simply changing the service to be owned by the stack instead of the deployment should fix this.
@mikkeloscar sounds good to me
@szuecs is this still needs to be implemented?, if so i would like to work on it.
Thanks for offering your help on this, however it was already done a while ago when we refactored the controller. :)