PeeringCandidates list cleanup logic is missing

[fracappa]

Hello everyone.

This issue is to ask a question about some logic within the FLUIDOS Node.

More specifically, PeeringCandidates are created upon Solver CRs creation; PeeringCandidate resources are indeed an association between a SolverID and a Flavour.

However, the current logic does not clean up the peering candidate table after a solver has been solved.

My question is: is this a missing logic or is it a desired behaviour?

Thanks.
Francesco

[cannarelladev]

Hi @fracappa,

A Peering Candidate is not "an association between a SolverID and a Flavour." It simply serves as a wrapper for a Flavour received from an external fluidos node after a specific discovery triggered by a Solver. These Peering Candidates represent available Flavours and indicate where resources can be allocated from.

The rationale for retaining them, rather than deleting them, is based on the anticipation of finding a matching candidate during the next discovery process. If a Peering Candidate is utilized, it will be reserved and associated with a SolverID. This information is crucial for correctly solving, reserving, and provisioning the necessary resources.

Thanks.
Alessandro

[fracappa]

Hi @cannarelladev .

Thanks for replying to this issue.

I thought about the reason behind this implementation choice and I have come to the same conclusions as you.

However, if the PeeringCandidate resource is "only" a wrapper of a Flavour, it should not be having any relationships with other resources, should it?
But, sooner or later, it's going to be linked to a Solver (through SolverID field) and as such it's not just a Flavour wrapper anymore.

I agree with you that it is reasonable to keep PeeringCandidate available for next discoveries but what if those discoveries are never triggered? Has been taken into account the possibility of handling different types of Flavours (VMs, K8s, Services, etc) with a possible explosion of PeeringCandidate CRs?

Moeover, I believe that many intermediate resources (like PeeringCandidate "consumed "by solvers and Reservations) should be cleaned once we got the Contract, possibly after a while, as those are temporary resources.

I'm questioning if it's reasonable to just cache HTTP(s) responses from providers and then creating PC (if cache is still valid) upon possible next discoveries, rather than keeping CRs forever.

Thanks for any feedback.
Francesco