Navigation Menu

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

remove created-by annotation #54445

Merged
merged 1 commit into from Nov 1, 2017
Merged

Conversation

crimsonfaith91
Copy link
Contributor

@crimsonfaith91 crimsonfaith91 commented Oct 24, 2017

What this PR does / why we need it:
This PR removes CreatedByAnnotation.

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #50720

Release note:

The `kubernetes.io/created-by` annotation is no longer added to controller-created objects. Use the  `metadata.ownerReferences` item that has `controller` set to `true` to determine which controller, if any, owns an object.

@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Oct 24, 2017
@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Oct 24, 2017
@k8s-github-robot k8s-github-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 26, 2017
@kow3ns
Copy link
Member

kow3ns commented Oct 26, 2017

/approve

@k8s-github-robot k8s-github-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 26, 2017
@janetkuo janetkuo assigned janetkuo and unassigned crimsonfaith91 Oct 27, 2017
@@ -474,29 +472,12 @@ func getPodsFinalizers(template *v1.PodTemplateSpec) []string {
return desiredFinalizers
}

func getPodsAnnotationSet(template *v1.PodTemplateSpec, object runtime.Object) (labels.Set, error) {
func getPodsAnnotationSet(template *v1.PodTemplateSpec, object runtime.Object) labels.Set {
Copy link
Member

Choose a reason for hiding this comment

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

object is no longer needed

orphaned_ds_pod := corev1.Pod{
ObjectMeta: metav1.ObjectMeta{
Name: "bar",
Namespace: "default",
CreationTimestamp: metav1.Time{Time: time.Now()},
Labels: labels,
SelfLink: testapi.Default.SelfLink("pods", "bar"),
Annotations: missing_ds_anno,
OwnerReferences: []metav1.OwnerReference{
Copy link
Member

@janetkuo janetkuo Oct 27, 2017

Choose a reason for hiding this comment

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

This test setup isn't correct. An "orphaned" pod does not have any controller (controllerRef == nil). "Orphan" simply means it's not controlled by anyone, and GC controller "orphans" a resource by removing its controllerRef.

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 am aware of it, but i didn't change it as it is not relevant to created-by annotation.

Copy link
Member

Choose a reason for hiding this comment

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

It's actually related, because this controllerRef was mistakenly added here when replacing created-by with controllerRef d76b08d#diff-db0998ca74ee87d106ee23d584f337a5R399

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 verified it was me who added the owner reference to the test. I did not know about orphaning at that moment (it was my first PR for k8s main repo). Thanks for catching it!

@@ -1253,7 +1253,7 @@ run_kubectl_run_tests() {
# Post-Condition: Job "pi" is created
kube::test::get_object_assert jobs "{{range.items}}{{$id_field}}:{{end}}" 'pi:'
# Describe command (resource only) should print detailed information
kube::test::describe_resource_assert pods "Name:" "Image:" "Node:" "Labels:" "Status:" "Created By"
kube::test::describe_resource_assert pods "Name:" "Image:" "Node:" "Labels:" "Status:"
Copy link
Member

Choose a reason for hiding this comment

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

For every kube::test::describe_resource_assert call to a resource that's controlled by something, verify that "Controlled By" is there too

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As synced by person, the above two tests should not be added with "Controlled By" print attribute. For the first test, we are not interested with it. For the second one, although a node is managed by node controller, "Controlled By" print attribute will look at controllerRef field, which is not available for nodes.

I also did a thorough search, and added "Controlled By" to only the tests that manage to pass with it.

@crimsonfaith91
Copy link
Contributor Author

crimsonfaith91 commented Oct 27, 2017

For future reference, Controlled By will not be available for printing if the resource is created directly from a YAML file. A resource needs to be created by a parent resource (e.g., a replicaset is created by a deployment) for it to have Controlled By info at the beginning. This is because Controlled By info depends on controllerRef field under the hood, which is not set if there is no parent resource.

The resource created directly from a YAML file can later be adopted and controlled by a parent resource, in which the resource's controllerRef points to the parent resource.

Note that the controllerRef field is populated when an ownerReference has controller field set to true. Each resource can have only one ownerReference with controller field as true.

It is possible for a node or a service to have controllerRef field pointing to a parent resource. A user can create a custom resource (not k8s core resource) that controls the node or service.

@janetkuo
Copy link
Member

For future reference, Controlled By will not be available for printing if the resource is created directly from a YAML file. A resource needs to be created by a parent resource (e.g., a replicaset is created by a deployment) for it to have Controlled By info. This is because Controlled By info depends on controllerRef field under the hood.

To clarify, node and service do not have controllerRef field, so Controlled By info is not applicable too.

When we say controllerRef we actually mean the .metadata.ownerReferences field and specifically the one with .metadata.ownerReference[].controller == true. Every resource has the ownerReferences field (as long as it has metadata).

A resource can be adopted by other resources dynamically. For example, an RS can be created from a yaml file, and it does not have controllerRef at creation time (because no one controls its lifecycle); however, it can then be adopted (and controlled) by a deployment, and have its controllerRef points to the deployment.

Theoretically, a user can create a custom resource (not Kubernetes core resource) that controls a node or service, and have their controllerRef point to the custom resource.

@crimsonfaith91
Copy link
Contributor Author

crimsonfaith91 commented Oct 30, 2017

@janetkuo Thanks for pointing out the custom resource - didn't know about that. Is the custom resource named TPR or CRD? Updated my summary comment too.

If everything looks good to you, I will squash.

@janetkuo
Copy link
Member

LGTM, feel free to squash.

Is the custom resource named TPR or CRD

Custom resource can be defined with CRD. CRD supersedes TPR.

@janetkuo
Copy link
Member

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Oct 31, 2017
@crimsonfaith91
Copy link
Contributor Author

crimsonfaith91 commented Oct 31, 2017

/assign @lavalamp @liggitt
This PR removes created-by annotation. It needs your approval for merging. The annotation has been deprecated in 1.8, and is scheduled for removal in 1.9.

@liggitt liggitt added release-note-action-required Denotes a PR that introduces potentially breaking changes that require user action. and removed release-note Denotes a PR that will be considered when it comes time to generate release notes. labels Oct 31, 2017
@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed release-note-action-required Denotes a PR that introduces potentially breaking changes that require user action. labels Oct 31, 2017
@liggitt
Copy link
Member

liggitt commented Oct 31, 2017

noted deprecated in https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.8.md#deprecations

updated release note with more detailed info

/lgtm

@crimsonfaith91
Copy link
Contributor Author

@liggitt Thanks for updating the release note with more detailed info! I will make changes to CHANGELOG-1.8.md once this PR merges.

@fejta
Copy link
Contributor

fejta commented Oct 31, 2017

/approve

@k8s-github-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: crimsonfaith91, fejta, janetkuo, kow3ns, liggitt

Associated issue: 50720

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these OWNERS Files:

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

@k8s-github-robot k8s-github-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Oct 31, 2017
@k8s-github-robot
Copy link

Automatic merge from submit-queue (batch tested with PRs 53190, 54790, 54445, 52607, 54801). If you want to cherry-pick this change to another branch, please follow the instructions here.

@k8s-github-robot k8s-github-robot merged commit ed00d9c into kubernetes:master Nov 1, 2017
hiddeco pushed a commit to hiddeco/kubernetes that referenced this pull request Apr 6, 2020
Automatic merge from submit-queue (batch tested with PRs 53190, 54790, 54445, 52607, 54801). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.

remove created-by annotation

**What this PR does / why we need it**:
This PR removes `CreatedByAnnotation`.

**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes kubernetes#50720

**Release note**:

```release-note
The `kubernetes.io/created-by` annotation is no longer added to controller-created objects. Use the  `metadata.ownerReferences` item that has `controller` set to `true` to determine which controller, if any, owns an object.
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Remove CreatedByAnnotation in v1.9, in favor of ControllerRef
8 participants