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

Graduate EndpointSlice API to GA #99662

Merged
merged 1 commit into from Mar 6, 2021

Conversation

swetharepakula
Copy link
Member

  • removes discovery v1alpha1 API
  • removes EndpointSlice Topology field from GA API
  • adds per Endpoint Zone field in GA API

What type of PR is this?

/kind feature
/kind api-change

What this PR does / why we need it:

Graduates the EndpointSlice API to GA and removes the v1alpha1 API.

Does this PR introduce a user-facing change?

EndpointSlice API is now GA. The EndpointSlice topology field has been removed from the GA API and will be replaced by a new per Endpoint Zone field. If the topology field was previously used, it will be converted into an annotation in the v1 Resource. The discovery.k8s.io/v1alpha1 API is removed.

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

/cc @aojea @andrewsykim @liggitt @robscott @wojtek-t
/assign @thockin

@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. kind/feature Categorizes issue or PR as related to a new feature. size/XL Denotes a PR that changes 500-999 lines, ignoring generated files. labels Mar 2, 2021
@k8s-ci-robot k8s-ci-robot added kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. labels Mar 2, 2021
@k8s-ci-robot
Copy link
Contributor

Hi @swetharepakula. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

@k8s-ci-robot k8s-ci-robot added area/apiserver sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. and removed do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels Mar 2, 2021
@robscott
Copy link
Member

robscott commented Mar 2, 2021

Thanks for the work on this!

/ok-to-test
/sig network
/triage accepted
/priority important-soon

@k8s-ci-robot k8s-ci-robot added sig/network Categorizes an issue or PR as relevant to SIG Network. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. triage/accepted Indicates an issue or PR is ready to be actively worked on. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. labels Mar 2, 2021
@swetharepakula
Copy link
Member Author

I have made an update to PR with the new approach outlined in the above comment. It is ready for review again. Thank you all for all the feedback and help!

},
}

for _, tc := range testcases {
Copy link
Member

Choose a reason for hiding this comment

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

Great testcases

Copy link
Member

@thockin thockin left a comment

Choose a reason for hiding this comment

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

This looks pretty solid to me

pkg/apis/discovery/install/install.go Outdated Show resolved Hide resolved
test/integration/etcd/data.go Outdated Show resolved Hide resolved
pkg/apis/discovery/types.go Outdated Show resolved Hide resolved
pkg/controlplane/storageversionhashdata/data.go Outdated Show resolved Hide resolved
pkg/registry/discovery/endpointslice/strategy.go Outdated Show resolved Hide resolved
}

requestGV := schema.GroupVersion{Group: info.APIGroup, Version: info.APIVersion}
if requestGV == discoveryv1.SchemeGroupVersion {
Copy link
Member

Choose a reason for hiding this comment

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

suggest checking our version and returning early for v1beta1 specifically. we'd want to drop deprecated topology the same way in future versions without needing to revisit this code.

func dropTopologyOnV1(ctx context.Context, oldEPS, newEPS *discovery.EndpointSlice) {
  if info, ok := genericapirequest.RequestInfoFrom(ctx); ok {
    // ... return early if v1beta1
  }
  ... check deepequal, drop, etc...

Copy link
Member

Choose a reason for hiding this comment

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

that has a nice property of forcing us to look at this when v1b1 goes away

Copy link
Member Author

Choose a reason for hiding this comment

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

updated so we check for v1beta1 requests and return early.

Comment on lines 172 to 177
if ep.NodeName != nil {
if ep.DeprecatedTopology == nil {
ep.DeprecatedTopology = make(map[string]string, 1)
}
ep.DeprecatedTopology[corev1.LabelHostname] = *ep.NodeName
}
Copy link
Member

@liggitt liggitt Mar 5, 2021

Choose a reason for hiding this comment

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

why isn't this limited to endpointListUpdated as well? this means a v1 writer touching only metadata fields (like the garbage collector or something) would cause nodeName to get propagated into deprecatedTopology. is that what we want?

edit: I guess if we drop the hostname topology label in internal→v1 conversion as described in #99662 (comment), we have to restore it in v1→internal conversion

Copy link
Member Author

Choose a reason for hiding this comment

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

I think we need to have nodeName propagated in deprecatedTopology, otherwise older kube-proxies would not be able to read nodeName information since we don't do anything special in the conversion in regards to the hostname topology label. When we remove v1beta1, we could then remove this logic to stop populating topology and eventually deprecatedTopology will be an unused field.

Copy link
Member

Choose a reason for hiding this comment

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

I think we need to have nodeName propagated in deprecatedTopology, otherwise older kube-proxies would not be able to read nodeName information since we don't do anything special in the conversion in regards to the hostname topology label.

When endpoints are being modified via v1, I agree. If the endpoint was written via v1beta1, doing this unconditionally (not just when endpoints were modified via v1) means we'll copy nodeName into topology

Copy link
Member Author

Choose a reason for hiding this comment

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

We still have the version check, but I see your point that it makes sense only to do this when the v1 client is writing to Endpoints

pkg/apis/discovery/v1beta1/conversion.go Outdated Show resolved Hide resolved
pkg/apis/discovery/v1beta1/conversion.go Show resolved Hide resolved
@liggitt
Copy link
Member

liggitt commented Mar 5, 2021

I agree this looks close. The only open question I have is whether we want deprecatedTopology[hostname] served in v1 when it matches nodeName.

  * Removes discovery v1alpha1 API
  * Replaces per Endpoint Topology with a read only DeprecatedTopology
  in GA API
  * Adds per Endpoint Zone field in GA API
Copy link
Member

@thockin thockin left a comment

Choose a reason for hiding this comment

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

YAY!

/lgtm
/approve

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Mar 5, 2021
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: swetharepakula, thockin

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 Mar 5, 2021
@aojea
Copy link
Member

aojea commented Mar 5, 2021

Impressive 👏

@liggitt
Copy link
Member

liggitt commented Mar 6, 2021

/test pull-kubernetes-dependencies
/test pull-kubernetes-unit

@aojea
Copy link
Member

aojea commented Mar 6, 2021

https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/99662/pull-kubernetes-unit/1368287507921244160

https://storage.googleapis.com/k8s-gubernator/triage/index.html?date=2021-03-06&pr=1&text=etcd%20event%20received%20with%20PrevKv%3Dnil

=== RUN   TestWatch
I0306 20:06:14.051962   69532 client.go:360] parsed scheme: "endpoint"
I0306 20:06:14.052118   69532 endpoint.go:68] ccResolverWrapper: sending new addresses to cc: [{unix://localhost:65802040492353799000  <nil> 0 <nil>}]
I0306 20:06:14.059865   69532 client.go:360] parsed scheme: "endpoint"
I0306 20:06:14.060215   69532 endpoint.go:68] ccResolverWrapper: sending new addresses to cc: [{unix://localhost:65802040492353799000  <nil> 0 <nil>}]
I0306 20:06:14.066951   69532 client.go:360] parsed scheme: "endpoint"
I0306 20:06:14.067180   69532 endpoint.go:68] ccResolverWrapper: sending new addresses to cc: [{unix://localhost:65802040492353799000  <nil> 0 <nil>}]
E0306 20:06:17.870930   69532 watcher.go:218] watch chan error: etcd event received with PrevKv=nil (key="/registry/ingresses/test/foo-ingress", modRevision=3, type=DELETE)
    resttest.go:1559: unexpected result from result channel
--- FAIL: TestWatch (4.07s)

/retest

@liggitt
Copy link
Member

liggitt commented Mar 6, 2021

/retest

1 similar comment
@robscott
Copy link
Member

robscott commented Mar 6, 2021

/retest

@liggitt
Copy link
Member

liggitt commented Mar 6, 2021

https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/99662/pull-kubernetes-unit/1368295059291639808

https://prow.k8s.io/view/gs/kubernetes-jenkins/pr-logs/pull/99662/pull-kubernetes-unit/1368306368418680832

https://storage.googleapis.com/k8s-gubernator/triage/index.html?date=2021-03-06&pr=1&test=TestAdmit

=== RUN   TestAdmit/match_dry_run_side_effects_None
W0306 20:42:50.473031   82007 mutation_detector.go:53] Mutation detector is enabled, this will result in memory leakage.
W0306 20:42:50.473220   82007 mutation_detector.go:53] Mutation detector is enabled, this will result in memory leakage.
    plugin_test.go:187: 
        	Error Trace:	plugin_test.go:187
        	Error:      	Not equal: 
        	            	expected: map[string]string{"allow/key1":"value1", "mutation.webhook.admission.k8s.io/round_0_index_0":"{\"configuration\":\"test-webhooks\",\"webhook\":\"allow\",\"mutated\":false}"}
        	            	actual  : map[string]string(nil)
        	            	
        	            	Diff:
        	            	--- Expected
        	            	+++ Actual
        	            	@@ -1,5 +1,2 @@
        	            	-(map[string]string) (len=2) {
        	            	- (string) (len=10) "allow/key1": (string) (len=6) "value1",
        	            	- (string) (len=49) "mutation.webhook.admission.k8s.io/round_0_index_0": (string) (len=67) "{\"configuration\":\"test-webhooks\",\"webhook\":\"allow\",\"mutated\":false}"
        	            	-}
        	            	+(map[string]string) <nil>
        	            	 
        	Test:       	TestAdmit/match_dry_run_side_effects_None
        	Messages:   	match dry run side effects None: annotations not set as expected.
    --- FAIL: TestAdmit/match_dry_run_side_effects_None (0.02s)

@liggitt
Copy link
Member

liggitt commented Mar 6, 2021

(the unit test flakes don't look related at all, just capturing them for referencing in flake issues)

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. area/apiserver area/cloudprovider area/code-generation area/dependency Issues or PRs related to dependency changes area/kubectl area/test cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API kind/feature Categorizes issue or PR as related to a new feature. lgtm "Looks good to me", indicates that a PR is ready to be merged. ok-to-test Indicates a non-member PR verified by an org member that is safe to test. priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. sig/cli Categorizes an issue or PR as relevant to SIG CLI. sig/cloud-provider Categorizes an issue or PR as relevant to SIG Cloud Provider. sig/cluster-lifecycle Categorizes an issue or PR as relevant to SIG Cluster Lifecycle. sig/instrumentation Categorizes an issue or PR as relevant to SIG Instrumentation. sig/network Categorizes an issue or PR as relevant to SIG Network. sig/testing Categorizes an issue or PR as relevant to SIG Testing. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants