- introduces resource_ids to eip status
- moves setting attachment status to be
before an attempt at attaching
- moves status update from patch to replace
this should raise errors if the resource has
changed allowing the resource_id to function
somewhat as a lock
- resource won't attempt to claim a resource
with a resource id
- fixes cargo deny errors
ensuring new eips that get created are associated with the correct resources in a timely manner.
the dns target annotation is not removed for pods
there are no guarantees that a eip who has lost its resource id will be assigned to a new eip
The main issue with an approach like this:
when a node/pod drops an eip we're left up to the pod/node reconciliation cycle to reassign. The EIP will reconcile due status change, but without adding considerable amount of code like was done in 348, EIPs won't attach themselves to resource or cause resources to re-reconcile leading them setting up the attachment to the eips.
^ Update to this
I've now pushed a change where the eip will use a dynamic resource provider to find all resource matching it's selector and update a label with a timestamp leading the resource to be reconciled. This seems to work really well. Let me know if there are concerns.
Alternative to https://github.com/MaterializeInc/k8s-eip-operator/pull/348
I believe this still has issues:
The main issue with an approach like this: when a node/pod drops an eip we're left up to the pod/node reconciliation cycle to reassign. The EIP will reconcile due status change, but without adding considerable amount of code like was done in 348, EIPs won't attach themselves to resource or cause resources to re-reconcile leading them setting up the attachment to the eips. ^ Update to this I've now pushed a change where the eip will use a dynamic resource provider to find all resource matching it's selector and update a label with a timestamp leading the resource to be reconciled. This seems to work really well. Let me know if there are concerns.