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

🐛 Populate GVK for listed objects #389

Merged
merged 4 commits into from
May 15, 2019

Conversation

JoelSpeed
Copy link
Contributor

Fixes #284. Populates GroupVersionKind for objects returned by the List method.

This supersedes #296. I've rebased the branch, fixed up the conflicts and found an issue where we seemed to not be deepcopying items out of the cache before returning.

I've maintained @liyinan926's ownership of the commits so they should still be credited for their work.

/CC @DirectXMan12

@k8s-ci-robot k8s-ci-robot added cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Apr 9, 2019
@@ -125,7 +125,9 @@ func (c *CacheReader) List(_ context.Context, out runtime.Object, opts ...client
if !isObj {
return fmt.Errorf("cache contained %T, which is not an Object", obj)
}
runtimeObjs = append(runtimeObjs, obj)
outObj := obj.DeepCopyObject()

Choose a reason for hiding this comment

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

I don't believe that we need to deep copy here because these objects are all created from within this function?

Thoughts?

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 added the DeepCopy because it stopped the race detector going off when I was running tests so there must be something funky going on here but I'm not sure what 🤷‍♂️

Choose a reason for hiding this comment

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

👍 wonder if it is what the indexer gives us for each list is just the cached object? I will look it up to see eventually :) thanks for the explanation!

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 should've been deepcopying anyway, since that's what we do elsewhere anyway.


By("verifying that the returned pods have GVK populated")
Expect(out.Items).NotTo(BeEmpty())
Expect(out.Items).Should(SatisfyAny(HaveLen(3), HaveLen(4)))

Choose a reason for hiding this comment

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

If we are getting 4 pods, I think that is a bug in the namespaced cache implementation. I will attempt to re-create locally.

I think we may need to file an issue and merge this with a TODO remove HaveLen(4) IMO.

/cc @DirectXMan12

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Don't know if you managed to repro locally or not, but to me it looks like the regular cache will be returning 4 pods as it lists across all namespaces(?) whereas the multinamespaced cache will only list 3 as there is a pod in a namespace that it isn't caching?

I haven't looked into this thoroughly though so am kinda guessing how the two different caches behave 🤷‍♂️

@JoelSpeed
Copy link
Contributor Author

/assign @pwittrock
Forgot to do the assign that the robot recommended

@shawn-hurley
Copy link

/lgtm

@DirectXMan12

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label May 8, 2019
@DirectXMan12
Copy link
Contributor

/lgtm
/approve

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: DirectXMan12, JoelSpeed

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

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label May 15, 2019
@k8s-ci-robot k8s-ci-robot merged commit 9d37aab into kubernetes-sigs:master May 15, 2019
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. size/S Denotes a PR that changes 10-29 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

MapObject.Object contains empty GroupVersionKind
6 participants