[go: nahoru, domu]
Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Resolving refs finds objects in terminating state #261

Open
larhauga opened this issue Apr 15, 2021 · 4 comments
Open

Resolving refs finds objects in terminating state #261

larhauga opened this issue Apr 15, 2021 · 4 comments
Labels
bug Something isn't working wontfix This will not be worked on

Comments

@larhauga
Copy link
larhauga commented Apr 15, 2021 •
edited
Loading

What happened?

When using references to other objects, the object is resolved even though the referenced object is in a terminating state.

How can we reproduce it?

We can reproduce this with the usage of AWS SecurityGroups where AWS checks if the SG ID is in use elsewhere.

apiVersion: ec2.aws.crossplane.io/v1beta1
kind: SecurityGroup
metadata:
  name: app-sg
  labels:
    type: application
    app: foobar
spec:
  forProvider:
    vpcId: XXX
    region: 
    description: Application security group
    groupName: app-sg
  providerConfigRef:
    name: default

apiVersion: ec2.aws.crossplane.io/v1beta1
kind: SecurityGroup
metadata:
  name: redis-sg
spec:
  forProvider:
    vpcId: XXX
    region: xxx
    description: regis-sg
    groupName: redis-sg
    ingress:
      - ipProtocol: tcp
        fromPort: 6379
        toPort: 6379
        userIdGroupPairs:
        - groupIdSelector:
            matchLabels:
              type: application
              app: foobar
  providerConfigRef:
    name: default
kubectl apply -f application-sg.yaml -f redis-sg.yaml
kubectl get securitygroups
app-sg                                     True    True     sg-xxx   vpc-xxx   85s
redis-sg                                   True    True     sg-xxx   vpc-xxx   65s

Delete the application security group that is referenced by redis security group, which will hang because of blocking AWS api.

kubectl delete -f application-sg.yaml # will hang on blocking

This will result in the following, since redis-sg now depends on app-sg, and on reconcile the object reference will see the app-sg even though it is in an unready state.

app-sg                                     False   False    sg-xxx   vpc-xxx   83s
redis-sg                                   True    True     sg-xxx   vpc-xxx   65s

The event on app-sg is the following:

failed to delete the SecurityGroup resource: DependencyViolation: resource sg-xxx has a dependent object

Expected behaviour

In #250 it is describe that it should work with clearing the reference, but this does not seem to be the case.

kubectl edit -f redis-sg.yaml # remove sg- reference

I assume that there is a missing condition at references.go as the destination object is not checked.

What environment did it happen in?

Crossplane version: 1.1.0
Cloud provider: provider-aws 0.17 + PR crossplane-contrib/provider-aws#614
Kubernetes version: 1.18
Kubernetes distribution: EKS
@larhauga larhauga added the bug Something isn't working label Apr 15, 2021
larhauga added a commit to larhauga/crossplane-runtime that referenced this issue Apr 15, 2021
@larhauga
Avoid resolution of pointers to objects in terminating state
adb5ed8 
Fixes: crossplane#261

Signed-off-by: Lars Haugan <lars@larshaugan.net>
larhauga added a commit to larhauga/crossplane-runtime that referenced this issue Apr 15, 2021
@larhauga
Avoid resolution of pointers to objects in terminating state
09fdf46 
Fixes: crossplane#261

Signed-off-by: Lars Haugan <lars@larshaugan.net>
@larhauga larhauga mentioned this issue Apr 15, 2021
Closed
2 tasks
larhauga added a commit to larhauga/crossplane-runtime that referenced this issue Apr 22, 2021
@larhauga
Avoid resolution of pointers to objects in terminating state
7569dee 
Fixes: crossplane#261

Signed-off-by: Lars Haugan <lars@larshaugan.net>
larhauga added a commit to larhauga/crossplane-runtime that referenced this issue Apr 22, 2021
@larhauga
Avoid resolution of pointers to objects in terminating state
e7bb19c 
Fixes: crossplane#261

Signed-off-by: Lars Haugan <lars@larshaugan.net>
@chlunde chlunde mentioned this issue Jun 24, 2021
Closed
larhauga added a commit to larhauga/crossplane-runtime that referenced this issue Oct 9, 2021
@larhauga
Avoid resolution of pointers to objects in terminating state
f7e364b 
Fixes: crossplane#261

Signed-off-by: Lars Haugan <lars@larshaugan.net>
@muvaf
Copy link
Member
muvaf commented Apr 21, 2022

What is the scenario that requires you to reference a terminating object? A case I can think of is that you reference an object, it's resolved, but now you'd like to delete and re-create that referenced object and expect that it picks up the new value. If that's the case, #328 should help you set a policy for the reference to repeatedly resolve even if it's already resolved to a value. Would that help?

@chlunde
Copy link
chlunde commented May 1, 2022

Yeah, this is about being able to recreate (or just delete) a composition or managed object that is referenced from another. For example, if you have an App and a DB, and the DB references the App in an inbound security group rule.

#328 will definitively help, but wouldn't it be 50-50 selecting the terminating object instead? So after 6 reconciles there's a 1% chance of all the reconciles selecting the terminating object? And AWS will not allow that object to terminate because of the reference.

And if the new object is "named" in AWS and not "random ID"-based, there will never be two objects available at the same time. In that case, the situation will never clear up.

So I think during resolution, we should still skip terminating objects, but the implementation will be much simpler thanks to #328.

@stale
Copy link
stale bot commented Aug 13, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix This will not be worked on label Aug 13, 2022
@chlunde
Copy link
chlunde commented Sep 13, 2022

/fresh

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working wontfix This will not be worked on
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Avoid resolution of pointers to objects in terminating state larhauga/crossplane-runtime
3 participants
@chlunde @larhauga @muvaf