Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move controller revision to annotations #1234

Merged
merged 12 commits into from
Jul 18, 2019

Conversation

anyasabo
Copy link
Contributor

Reverts most of #1224 and relates to #1137

Moves the controller revision to last update the CR to the metadata rather than the status. I'm open to having it wherever, this is just a first pass.

If we do want to use this field for control flow we will need to do it before we enter the inner reconcile flow (since this update occurs right before we do that), or change where this func is called.

Also looked like our dep lock file had fallen out of date so I ran dep ensure. Might be worth adding a check for that to CI, but we can also just punt until go modules.

Copy link
Contributor

@sebgl sebgl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a few minor comments, other than that LGTM! 👍

This is probably not enough to skip 0.8 -> 0.9 breaking migrations (how do we know if a cluster with no annotation is a 0.8 cluster or a newly created 0.9 cluster?), but can be useful starting 0.9.

)

// ControllerVersionAnnotation is the annotation name that indicates the last controller version to update a resource
const ControllerVersionAnnotation = "k8s.elastic.co/controller-version"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we have common.k8s.elastic.co used in other places, maybe use it here as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm good with that

func UpdateControllerVersion(client k8s.Client, obj runtime.Object, version string) error {
metaObject, err := meta.Accessor(obj)
if err != nil {
log.Error(err, "error converting runtime object to metav1 object")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe log obj.GetObjectKind().GroupVersionKind().Kind?


annotations[ControllerVersionAnnotation] = version
accessor := meta.NewAccessor()
err = accessor.SetAnnotations(obj, annotations)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we not reuse metaObject.SetAnnotations here, instead of creating a new accessor?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so because accessor's SetAnnotations(obj, annotations) returns a runtime.Object, which is what we need for the Update call, while metaObject.SetAnnotations() modifies the metav1.Object receiver.

But your question did make me realize that I didn't look closely enough at the funcs available to the metav1 Accessor so there's some small bit of refactoring I can do here

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

metaObject.SetAnnotations() modifies the metav1.Object receiver

I think it also modifies the original object you passed to it, which you can the use for the update call.
But I'm also fine with the way you used it here :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah that was not my understanding just from scanning through the code but it's deeeeefinitely possible I am misunderstanding

}

// setupScheme creates a scheme to use for our fake clients so they know about our custom resources
// TODO move this into one of the upper level common packages and make public, refactor out this code that's in a lot of our tests
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, can you create an issue for that one?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Technically you only need to register the Kibana types here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that's true @pebrc, wanted to make it easy to just copy it later

}

// do not send extraneous update if the value would not change
if annotations[ControllerVersionAnnotation] == version {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this not also return if there is any version set?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought we would want to use this func because the caller decided that we do want to proceed with an update -- for instance it might be okay with going from 0.9.0 to 0.9.1. We might need additional funcs before calling this

@anyasabo
Copy link
Contributor Author

This is probably not enough to skip 0.8 -> 0.9 breaking migrations (how do we know if a cluster with no annotation is a 0.8 cluster or a newly created 0.9 cluster?), but can be useful starting 0.9.

Agreed that's something we need to think about but think that might be out of the scope of this issue.

@pebrc pebrc added the v0.9.0 label Jul 15, 2019
@anyasabo
Copy link
Contributor Author

Jenkins test this please

@pebrc
Copy link
Collaborator

pebrc commented Jul 18, 2019

Jenkins test this please

@anyasabo anyasabo merged commit 8cd046b into elastic:master Jul 18, 2019
@anyasabo anyasabo deleted the 1137/oprevmetadata branch July 18, 2019 16:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants