-
Notifications
You must be signed in to change notification settings - Fork 9
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
Conversation
ec73121
to
526484f
Compare
} | ||
}) | ||
|
||
It("Should create valid probe CRs and remove them on DNSRecord deletion", func() { |
There was a problem hiding this comment.
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
15d0b49
to
e9a9109
Compare
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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() |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 🤔
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
changed
There was a problem hiding this 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
Signed-off-by: Maskym Vavilov <[email protected]>
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.