This is done a lot

home, err := os.UserHomeDir()
if err != nil {
	panic(err)
}

cfg, err := clientcmd.BuildConfigFromFlags("", path.Join(home, ".kube/config"))
if err != nil {
	panic(err.Error())
}

client := kubernetes.NewForConfigOrDie(cfg)
desired := corev1.ConfigMap{
	ObjectMeta: metav1.ObjectMeta{
		Name:      name,
		Namespace: namespace,
	},
	Data: map[string]string{"foo": "bar"},
}

Thoughts on a pkg/common or common/ or . I thin it will help better focus on the example that's trying to be displayed rather than the setup.

The repository should include an example of retry.RetryOnConflict.

Current implementation idea:

Folder Name: retry-on-conflict General Flow:

• Create pod - keep reference
• UpdateStatus pod - ignore reference to emulate the object changing unexpectedly from either another controller or external source
• Implement retry function. To display the use we could use a timer to demonstrate performing long running task to validate the status of an object. For instance sometimes when working with CRDs that create resources external to k8s, gathering status can take a significant amount of time. A very naive solution would be just using a flag and skipping fetch on the first try. Not quite sure, but a simple explanation would be better than a complex example. Maybe someone has some thoughts on how to emulate this situation easily.

err := retry.RetryOnConflict(retry.DefaultRetry, func() error {
    pod, err := c.Pods("ns").Get(name, metav1.GetOptions{})
    if err != nil {
        return err
    }
    
    // emulate long running tasks to get current status with timers
    
    _, err = c.Pods("ns").UpdateStatus(pod)
})

I'd like to submit a PR for this as I recently hit this position in a custom controller. @iximiuz I'd like to hear thoughts.

Thank you for the blogposts and for these snippets! I think it's very useful to see the timestamps in the examples that you have, I was wondering if you'd be ok if I submit a change replacing fmt.Printf with klog.Infof

So far:

I hope this is along the lines of what is expected.

Adds:

• simple display of retry on conflict. The current code will produce the following log

[email protected] retry-on-conflict (retry-on-conflict %)]$ go run main.go 
Successfully updated ConfigMap
Operation cannot be fulfilled on configmaps "foobar": the object has been modified; please apply your changes to the latest version and try again
Successfully updated ConfigMap
Operation cannot be fulfilled on configmaps "foobar": the object has been modified; please apply your changes to the latest version and try again
Successfully updated ConfigMap
Operation cannot be fulfilled on configmaps "foobar": the object has been modified; please apply your changes to the latest version and try again
Successfully updated ConfigMap
Operation cannot be fulfilled on configmaps "foobar": the object has been modified; please apply your changes to the latest version and try again
Successfully updated ConfigMap
Operation cannot be fulfilled on configmaps "foobar": the object has been modified; please apply your changes to the latest version and try again

I will add documentation on real world use cases/the nuances of the example in the readme. I will also be adding some docs about the function retryOnConflict itself and it's nuances.

cheers

Small typo

By the way awesome project. I find myself want to reference back to client-go example I no longer have access to or can't find. Expect to see a bit more of me.

Cheers!

At present, the selector remains empty even after the sel.Add(req) call.

fmt.Printf("%v", sel) prints empty string.

This is because the mutated sel is not reveived and assigned to sel at the caller.

note: the signature of sel.Add function is Add(r ...Requirement) Selector

Signed-off-by: Nikhil Thomas [email protected]