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.

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

Create/Delete HealthCheckProbeCR from DNSRecord Reconciler #271

Merged
merged 1 commit into from
Oct 25, 2024
Merged

Conversation

maksymvavilov
Copy link
Contributor

@maksymvavilov maksymvavilov commented Oct 15, 2024

Create and delete DNSHealthProbe CRs during reconciliation of the DNSRecords.
This replaced logic in internal/controller/dnsrecord_healthchecks.go to create new healthchecks but does not remove the code that would generate old healthchecks.

@maksymvavilov maksymvavilov linked an issue Oct 15, 2024 that may be closed by this pull request
@maksymvavilov maksymvavilov force-pushed the gh-144 branch 2 times, most recently from ec73121 to 526484f Compare October 16, 2024 13:47
@maksymvavilov maksymvavilov changed the title [WIP] Create/Delete HealthCheckProbeCR from DNSRecord Reconciler Create/Delete HealthCheckProbeCR from DNSRecord Reconciler Oct 16, 2024
}
})

It("Should create valid probe CRs and remove them on DNSRecord deletion", func() {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Creating a trivial integration check. At this moment we can only verify the creation of CR to our liking and a correct removal. Will expand in tests as the work progresses

@maksymvavilov maksymvavilov force-pushed the gh-144 branch 6 times, most recently from 15d0b49 to e9a9109 Compare October 23, 2024 12:26
for _, probe := range healthProbes.Items {
logger.V(1).Info(fmt.Sprintf("Deleting probe: %s", probe.Name))
if err := r.Delete(ctx, &probe); err != nil {
return err
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we gather the errors and attempt a delete on each of them to avoid leavng around ones we could have deleted due to an issue with another probe?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will immediately requeue as the reconciler will return this error. But I see no harm in it - changed

} else {
// we can't deal with it just by shortening one of them
// default to UID of record
value = record.GetUIDHash()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why don't we just use this all the time?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually the pobe will always be in the same namespace as the record. The record name has to be unique per namespace. So the label can just be the name of the DNSRecord it came from right? Don't need namespace here ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If i recall correctly it was something to do with this label being human-readable. The probe name will be a combination of hostname and IP/CNAME address of a leaf. This will not help a human to find the owner of the probe (DNS record name of gateway name + listener name)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually the pobe will always be in the same namespace as the record. The record name has to be unique per namespace. So the label can just be the name of the DNSRecord it came from right? Don't need namespace here ?

if we have multiple namespaces and the same names of records among them this might case a problem for the controller. Right now I'm restricting it to a namespace but I'd rather have it safe and have those label values be as unique as we can

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

however, if that makes no sense I'd rather have this logic as simple as possible (either name of record or uid if the name is too long). I might be just too paranoid 🤔

Copy link
Collaborator

@maleck13 maleck13 Oct 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think just go with the name as the simplest option for the controller to use and when you do the list also restrict to namespace (can never get the wrong ones then). So the list of probes is always done in the same namespace as the policy and record. You can do this with listOptions

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

changed

Copy link
Collaborator

@maleck13 maleck13 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

couple of questions but is coming together well

@maleck13 maleck13 added this pull request to the merge queue Oct 25, 2024
Merged via the queue into main with commit 51b99cb Oct 25, 2024
15 checks passed
@maksymvavilov maksymvavilov deleted the gh-144 branch November 7, 2024 12:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Create Health Check CRs from DNS Record reconciler
2 participants