Add Conditions to the Status information

[cimnine]

The goal of this PR is to provide more information about various error and success-conditions to the average K8up user. Such users are mainly interacting with K8up through the relevant custom resources. Therefore, when querying the status of these resources (e.g. kubectl describe backups/X), Conditions shall provide additional information about the resource's individual status.

Closes #138

[corvus-ch]

Overall looking good.

I commented some minor things here and there.

I miss a condition for when the job finished. This might not be that easy to achieve though as this would require to what jobs and have a reconciliation loop for when they change. Maybe create a feature request for this.

[cimnine]

I miss a condition for when the job finished. This might not be that easy to achieve though as this would require to what jobs and have a reconciliation loop for when they change. Maybe create a feature request for this.

I'll quickly look into it on Thursday, but it'll probably lead to a feature request.

[ccremer]

I miss a condition for when the job finished. This might not be that easy to achieve though as this would require to what jobs and have a reconciliation loop for when they change. Maybe create a feature request for this.

Not sure if I understand it correctly. We already have a reconciler for batch.jobs: https://github.com/vshn/k8up/blob/master/controllers/job_controller.go#L50, so we are watching those.

[corvus-ch]

We already have a reconciler for batch.jobs: https://github.com/vshn/k8up/blob/master/controllers/job_controller.go#L50, so we are watching those.

I was not aware of that one. So then this should be simple, I guess.

[cimnine]

We already have a reconciler for batch.jobs: https://github.com/vshn/k8up/blob/master/controllers/job_controller.go#L50, so we are watching those.

I was not aware of that one. So then this should be simple, I guess.

I don't see a straight-forward way to get back to the original Backup object, though. This is what I've come up with so far:

// Handle extracts some information from the batchv1.job that make observations
// easier.
func (j *JobHandler) Handle() error {

	jobEvent := observer.Create

	if _, exists := j.job.GetLabels()[job.K8uplabel]; !exists {
		return nil
	}

	if j.job.Status.CompletionTime != nil {
		references := j.job.GetObjectMeta().GetOwnerReferences()
		if len(references) < 1 {
			return nil
		}

		reference := references[0]

		ownerBackupObj := &v1alpha1.Backup{}
		err := j.Client.Get(j.CTX, client.ObjectKey{Name: reference.Name, Namespace: j.job.Namespace}, ownerBackupObj)
		if err != nil {
			return err
		}
	}

• Is that how you'd solve it?
• Do I understand correctly that the OwnerReference could either be a Backup, Restore, Check, Prune, Snapshot, etc.? So I would have to account for all possible types that start jobs? (That seems error-prone to me.)

[cimnine]

Rebased onto master and stashed the commits.

[ccremer]

I played around with it locally, though I haven't set up local backup repository so they always failed. at least the "JobCreated" condition is correctly being applied to the prune job that I set up.

Looking good so far! Thanks for the works!

[tobru]

Documentation update LGTM