This commit moves the synchronization logic to allways happen in a Pod,
regardless being a Custom or JSON syncer. This allows having a simpler Pod
lifecycle management as part of the channel controller logic.
In addition, syncer pod logs are read on succeeded state instate of
running state to simplify Pod lifecycle management.
As a result channel updates trigger a new channel synchronization
without having to wait for the next scheduled sync.
Signed-off-by: David Cassany <dcassany@suse.com>
* Add cloud-init support to seedImage
This commit adds a field to the SeedImage Spec for a cloud-config that
will be included in the built ISO.
If the cloud-config field is not set an empty file will be added to the
ISOs iso-config dir.
The reconciliation will take place in case the cloud-config is changed
and the base64 encoded value is used in an annotation in order to see if
the value has changed.
Signed-off-by: Fredrik Lönnegren <fredrik.lonnegren@suse.com>
* Linting
Signed-off-by: Fredrik Lönnegren <fredrik.lonnegren@suse.com>
* Add seedImage unit-tests
Signed-off-by: Fredrik Lönnegren <fredrik.lonnegren@suse.com>
---------
Signed-off-by: Fredrik Lönnegren <fredrik.lonnegren@suse.com>
This commit adds a rate limiter to the ManagedOSVersionChannel controller to prevent
stacking reconcile loops over the same resource in fast rates (doesn't make sense for a
ManagedOSVersionChannel). By default the controller runtime already includes an
equivalent rate limiter, but starts in the range of milliseconds, starting the exponential
rate limiter in the range of seconds is more than enough in this context.
In addition it drops the failures counter in the resource. This counter was supposed to
be used to limit the number attempts to sync in case of failure. This was a bad design,
status should not keep a counter like this as any change in status triggers a new
immediate reconcile loop, hence the counter was reaching the maximum as fast as the
controller runtime was executing reconcile loops without any rate limiter (rate limiter
applies only when there are no changes including status).
For now I think we can just live without the setting any maxium for failures. If we ever
need it I believe it should be coded and tracked within the controller itself, not in each
resource as this prevents the reconcile loop of being idempotent. Alternatively we could
prevent triggering the reconcile loop on status changes, however this prevents
reconciling if any third party (or user from the kubectl client) changes a resource status.
Fixes#257
Part of #240
Signed-off-by: David Cassany <dcassany@suse.com>
This commit adds few changes on the syncer logic:
* Makes use of ManagedOSVersionChannel status reason to track if there
is an on going synchronization rather than polling for the existence of a synchronization pod or not.
* Adds a logic to stop trying to synchronize after 4 consecutive attempts.
If it exceeds the maximum it just programs the next re-sync after the given sync
interval instead of immediately retrying.
* Adds some logging and comments here and there.
Signed-off-by: David Cassany <dcassany@suse.com>
* Implement syncer logic as part of the ManagedOSVersionChannel controller
This commit adds the logic to synchronize managedosversionchannels
within the already existing controller.
* make generate
* make build-manifests
* Update chart
* update e2e tests
Signed-off-by: David Cassany <dcassany@suse.com>
Francesco Giudici