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
Add e2e testing of server-side apply for openshift types #25652
Add e2e testing of server-side apply for openshift types #25652
Conversation
This enables apply testing to use the namespace in Patch invocations.
c2f200a
to
bfee082
Compare
} | ||
kubeClient, err := kubernetes.NewForConfig(oc.AdminConfig()) | ||
o.Expect(err).NotTo(o.HaveOccurred()) | ||
mapper = restmapper.NewDeferredDiscoveryRESTMapper(discocache.NewMemCacheClient(kubeClient.Discovery())) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: why a new one for each subtest?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note the conditional check above. It's initialized once per worker, not once per subtest. My ginkgo-foo is weak, if there's a better way to accomplish this I'm all ears!
// Ensure that any stub embedding the etcd test namespace | ||
// is updated to use local test namespace instead. | ||
if len(testNamespace) > 0 { | ||
stub = strings.Replace(stub, exetcd.TestNamespace, testNamespace, -1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there a need to use the etcd storage test namespace? Would rather use a unique namespace here to avoid conflicts, and to reduce shared logic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am using a unique namespace - that's testNamespace
. It only needs to be used when the resource itself is namespaced since many of the types are cluster-scoped. This minimizes the need to provision new namespaces since that is not cheap.
Overall it looks good! |
types.ApplyPatchType, | ||
serializedObj, | ||
metav1.PatchOptions{ | ||
FieldManager: "apply_test", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this what it takes to do server-side apply?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the patch type especially.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh, okay, it points to the client that made the update.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This just points to who made an update, and it can be supplied with CREATE, UPDATE or PATCH. The key to performing server-side apply is types.ApplyPatchType
.
o.Expect(err).NotTo(o.HaveOccurred()) | ||
|
||
g.By(fmt.Sprintf("updating the %s via apply", unstructuredObj.GetKind())) | ||
obj, err := resourceClient.Patch( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we don't have to actually change the object to test the server-side apply logic?
is setting a FieldManager
a good indicator?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A good first step. It won't tell us that our schema is correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The server-side logic has reasonable integration tests in upstream. The goal of this test is validating that openshift types are compatible with server-side apply vs validating server-side apply itself.
/retest |
1 similar comment
/retest |
bfee082
to
e933075
Compare
Updated to fix the final test failure: https://github.com/openshift/origin/pull/25652/files#diff-5622a956d54343610dc9861478380f2c89a9050297ea9bc48726e6356c6a9dedR67 |
/retest |
2 similar comments
/retest |
/retest |
/lgtm |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: marun, p0lyn0mial, sttts 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 |
/retest Please review the full test history for this PR and help us cut down flakes. |
6 similar comments
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/retest Please review the full test history for this PR and help us cut down flakes. |
/cherry-pick release-4.6 |
@marun: #25652 failed to apply on top of branch "release-4.6":
In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
TODO
oauth.openshift.io/v1
anduser.openshift.io/v1
groups/cc @sttts @stlaz @p0lyn0mial