jiebi/CodeConvo huggingface dataset:
Change:
import ( "bufio" <del> //"fmt" </del> "net" "net/http" "regexp" "strconv" "strings" <ins> "sync" </ins> "time" utilnet "k8s.io/apimachinery/pkg/util/net"

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: endpoint of different k8s components expose Prometheus metrics that are not for them. For example, exposes metrics: or : What you expected to happen: Prometheus metrics only for to appear on kubelet's endpoint. How to reproduce it (as minimally and precisely as possible): Access the endpoint of all Kubernetes components Anything else we need to know?: This problem comes from usage of functions in different packages that automatically register Prometheus metrics. Just importing that package or some package that depends on it can cause those metrics to appear in unexpected places. In the list bellow you can find the different packages that have init functions and affected binaries: [ ] () cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kube-proxy kube-scheduler [ ] () cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kube-proxy kube-scheduler [ ] cloud-controller-manager hyperkube kube-apiserver kube-controller-manager [ ] cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kubelet [ ] cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kube-proxy kube-scheduler [ ] cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kube-proxy kube-scheduler kubectl kubelet [ ] cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kube-proxy kube-scheduler kubelet [ ] hyperkube kube-apiserver kube-controller-manager [ ] hyperkube kube-apiserver [ ] cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kubelet [ ] cloud-controller-manager hyperkube kube-apiserver kube-controller-manager kube-proxy kube-scheduler kubelet Environment: Kubernetes version (use ):Cloud provider or hardware configuration: N/A OS (e.g. from /etc/os-release): N/A Kernel (e.g. ): N/A Install tools: N/A Others: N/A /sig instrumentation
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
}, } <del> select { case event := <-watching.ResultChan(): if e, a := watch.Added, event.Type; e != a { t.Errorf("Expected %v, got %v", e, a) } if e, a := pod, event.Object; !reflect.DeepEqual(e, a) { t.Errorf("Expected %v, got %v", e, a) } case <-time.After(10 * time.Millisecond): t.Errorf("Expected 1 call but got 0") </del> <ins> event := <-watching.ResultChan() if e, a := watch.Added, event.Type; e != a { t.Errorf("Expected %v, got %v", e, a) } if e, a := pod, event.Object; !reflect.DeepEqual(e, a) { t.Errorf("Expected %v, got %v", e, a) </ins> } // Test error case

Discussion:
https://travis-
Taking a look.
The problem is that TestWatch is using a 10ms timeout, and after parallel test change, we seem to hit the unlucky case more often. This happens when the etcdWatch.translate goroutine never gets a chance to consume the etcdIncoming channel within 10ms. A naive fix would be to remove this 10ms timeout, and have the test rely on the default 30 sec timeout which comes with the test harness.
Ah, I see. Nice catch.
Change:
// add the kubelet config controller to kubeletDeps kubeletDeps.KubeletConfigController = kubeletConfigController <ins> if err := checkPermissions(); err != nil { klog.ErrorS(err, "kubelet running with insufficient permissions") } </ins> // set up signal context here in order to be reused by kubelet and docker shim ctx := genericapiserver.SetupSignalContext()

Discussion:
What happened: follow on to Need to comment and avoid checking UID on windows. requires some research into what we should be checking so that we can add appropriate TODO. What you expected to happen: Lets also check this at the call site, Anything else we need to know?: Environment: Kubernetes version (use ): master OS (e.g: ): windows
/assign
/assign
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig windows
Hi are you working on this issue already? If not I'd like to tackle this issue :)
Hi yeah I am already working on this :)
Started branch for this here
thanks
Hey guys is there anything I can do here?
If you want to test perks patch that would be great ?
That sounds great Where do I get started?
Hey ! is there anything I can help with? and how?
I dont think there is anything left to do anything more that you think we need to do to get this merged?
Tested this with containerd as well, I think its good to test
/triage accepted
Change:
if strings.Contains(name, enableStatefulSetAutoDeletePVC) { defer featuregatetesting.SetFeatureGateDuringTest(t, utilfeature.DefaultFeatureGate, features.StatefulSetAutoDeletePVC, true)() } <del> if strings.Contains(name, enableStatefulSetStartOrdinal) { defer featuregatetesting.SetFeatureGateDuringTest(t, utilfeature.DefaultFeatureGate, features.StatefulSetStartOrdinal, true)() } </del> errs := ValidateStatefulSet(&testCase.set, pod.GetValidationOptionsFromPodTemplate(&testCase.set.Spec.Template, nil)) wantErrs := testCase.errs

Discussion:
This applies to StatefulSetStartOrdinal feature gate. Field validation should be done regardless of the feature gate state. From
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/sig apps
Change:
VolumeGlusterServer // VolumeRBDServer image VolumeRBDServer <del> // WindowsNanoServer image WindowsNanoServer </del> ) func initImageConfigs() map[int]Config { configs := map[int]Config{} configs[Agnhost] = Config{e2eRegistry, "agnhost", "2.6"} <del> configs[Alpine] = Config{dockerLibraryRegistry, "alpine", "3.7"} </del> configs[AuthenticatedAlpine] = Config{gcAuthenticatedRegistry, "alpine", "3.7"} configs[AuthenticatedWindowsNanoServer] = Config{gcAuthenticatedRegistry, "windows-nanoserver", "v1"} configs[APIServer] = Config{e2eRegistry, "sample-apiserver", "1.10"}

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: jobs primarely, like: Which test(s) are failing: [] Container Runtime blackbox test when running a container with a new image should be able to pull image from [NodeConformance] Since when has it been failing: Since this commit merged: Testgrid link: Reason for failure: The test should always pull the image from (), it is not configurable. Anything else we need to know: /sig testing /sig windows /area conformance This issue was fixed once before:
Change:
HostPort int `json:"hostPort,omitempty"` // Required: This must be a valid port number, 0 < x < 65536. ContainerPort int `json:"containerPort"` <del> // Optional: Supports "TCP" and "UDP".  Defaults to "TCP". </del> <ins> // Required: Supports "TCP" and "UDP". </ins> Protocol Protocol `json:"protocol,omitempty"` // Optional: What host IP to bind the external port to. HostIP string `json:"hostIP,omitempty"`

Discussion:
Many comments in there say "if not specified, default is ..." - but we previously asserted that there are no defaults for the internal API. We should strip those comments out, and leave them in versioned structs only.
cc
Change:
func TestParseSecretConfig(t *testing.T) { var ( <del> testUsername = "Admin" testPassword = "Password" testIP       = "10.20.30.40" </del> <ins> testUsername   = "Admin" testPassword   = "Password" testIP         = "10.20.30.40" testServerFQIN = "ExAmple.com" </ins> ) var testcases = []struct { testName      string

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: kube-controller-manager is unable to locate the credentials of the vCenter host, even though they are defined and cased identically to the hostname in the cloud-provider-config. What you expected to happen: vCenter hostname should not be case-sensitive, or should be documented that it is. It should successfully locate credentials from the manager How to reproduce it (as minimally and precisely as possible): to an upper-case name kube-controller-manager daemon to update the secret to provision storage with the "thin" storage class will stay suck in pending Anything else we need to know?: Log Messages: ` This appears to be induced by the way the vCenter server name is calculated when the secret containing the credentials is parsed[]. The credentialKey is converted to lower case and is then parsed to lookup the server name. Environment: Kubernetes version (use ): v1.14 Cloud provider or hardware configuration: vSphere OS (e.g: ): Unknown Kernel (e.g. ): Unknown Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /area/provider/vmware
/area provider/vmware
Change:
import ( "context" "errors" <ins> "net" </ins> "github.com/gophercloud/gophercloud" "github.com/gophercloud/gophercloud/openstack/compute/v2/servers"

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The Kubernetes master created routes in the neutron router that assign an IPv6 nexthop for a IPv4 prefix. This is not possible and causes a reachability problem between the pods. Example route: What you expected to happen: When describing a node the master has the following information It should detect the address type and choose the correct InternalIP How to reproduce it (as minimally and precisely as possible): Deploy on a Openstack cloud with IPv6 enabled using the following playbook Anything else we need to know?: The wrong next hop is coming from calling the function and nowhere is a check if the address is IPv4 or IPv6 Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Openstack OS (e.g. from /etc/os-release): Ubuntu Xenial Kernel (e.g. ):Install tools: Others: /sig openstack
- Thank you for this detailed analysis. Seems to me that the best way to address this would be to add an IP family argument to getAddressByName() to let it know what V4/V6 family to look for for a next-hop address. In the calls to getAddressByName(), this argument could be set based on the family of route.DestinationCIDR.
Issue is probably related.
Change:
return directDialer } return func(ctx context.Context, network, addr string) (net.Conn, error) { <del> trace := utiltrace.New(fmt.Sprintf("Proxy via HTTP Connect over %s", d.options.transport), utiltrace.Field{Key: "address", Value: addr}) </del> <ins> trace := utiltrace.New(fmt.Sprintf("Proxy via %s protocol over %s", d.options.protocol, d.options.transport), utiltrace.Field{Key: "address", Value: addr}) </ins> defer trace.LogIfLong(500 * time.Millisecond) start := egressmetrics.Metrics.Clock().Now() proxier, err := d.connector.connect()

Discussion:
What happened: egress selector logs HTTP Connect mode in all cases regardless of whether GRPC mode is used or not. This should be changed to look at the mode before logging.
/sig api-machinery
/assign
/triage accepted
Change:
Client: fake.CreateHTTPClient(func(req *http.Request) (*http.Response, error) { m := &MyReq{req} switch { <ins> case m.isFor("GET", "/nodes/node1"): fallthrough case m.isFor("GET", "/nodes/node2"): fallthrough </ins> case m.isFor("GET", "/nodes/node"): return &http.Response{StatusCode: 200, Header: cmdtesting.DefaultHeader(), Body: cmdtesting.ObjBody(codec, test.node)}, nil case m.isFor("GET", "/nodes/bar"): return &http.Response{StatusCode: 404, Header: cmdtesting.DefaultHeader(), Body: cmdtesting.StringBody("nope")}, nil <ins> case m.isFor("PATCH", "/nodes/node1"): fallthrough case m.isFor("PATCH", "/nodes/node2"): fallthrough </ins> case m.isFor("PATCH", "/nodes/node"): data, err := ioutil.ReadAll(req.Body) if err != nil {

Discussion:
They should be consistent with all other commands that allow multiple arguments (since they already allow label selectors). should cordon all of them, not return an error.
Hi , can I take this if no one has been working on it?
Please also refer . These two and should take multiple arguments as it is very common to get subset of nodes in this way . So it would be very nice if these would work:
Change:
client := newClient(t, address) // make sure the gRPC server is up before running tests <del> if err := wait.PollImmediateUntilWithContext(ctx, time.Second, func(ctx context.Context) (bool, error) { ctx, cancel := context.WithTimeout(ctx, 3*time.Second) defer cancel() _, err := client.Status(ctx, &kmsapi.StatusRequest{}) if err != nil { t.Logf("failed to get kms status: %v", err) </del> <ins> ready: for { select { case <-ctx.Done(): t.Fatalf("server failed to start in time: %v", ctx.Err()) default: if done := func() bool { ctx, cancel := context.WithTimeout(ctx, 3*time.Second) defer cancel() _, err := client.Status(ctx, &kmsapi.StatusRequest{}) if err != nil { t.Logf("failed to get kms status: %v", err) } return err == nil }(); done { break ready } time.Sleep(time.Second) </ins> } <del> return err == nil, nil }); err != nil { t.Fatal(err) </del> } t.Run("should be able to encrypt and decrypt through unix domain sockets", func(t *testing.T) {

Discussion:
Drop the and dependencies from to keep the import lighter. /sig auth /triage accepted
/assign Hi, , I created a PR to fix this. I am not sure If I am correct due to the repo seems generated. Would you like to provides some hints for me?
This will likely require a new go module in to move the client-go dep and then mark it as internal, ex: . is the only API machinery dep so we can probably come up with some way to re-implement the wait logic locally? Then we drop these lines so that these imports do not come back again:
Whoa, yeah, I'd take a for loop and a time.Sleep in a test to drop those deps
What is kms using client-go for? Tests only?
These were all needed by the KMS repo back when we had a much more complicated reference implementation which required a key hierarchy. Now they are just used in some tests and mock implementations, so we should be able to simplify things.
I found a place for rate limit. #liggitt
that package just delegates to "", switch that mock provider to use that directly?
Change:
if tc.ExpectError == "" { t.Errorf("%s: expected no error, got %q", k, err.Error()) } <del> if !strings.Contains(err.Error(), tc.ExpectError) { </del> <ins> if tc.ExpectError != "" && !regexp.MustCompile(tc.ExpectError).MatchString(err.Error()) { </ins> t.Errorf("%s: expected error containing %q, got %q", k, tc.ExpectError, err.Error()) } return

Discussion:
unit tests since switching to go1.18 No response No response Weirdly, the test is passing in CI () and failing locally /sig api-machinery auth testing
seems related Jordan, are you using mac ?
yes, though the description in that issue seems to be not just test-only changes to the errors received from invalid certificates (which is what I saw), but actual certificates that previously validated
marking as release blocker until it is determined that go1.18 is not rejecting valid certificates
this needs an assignee and a reproducer we can file as an upstream issue for golang to ask why previously valid certificates now fail validation
marking critical until root-caused and determined whether this is prod-impacting, since (in my opinion) this should block rc0
On linux it works fine: on MacOS, it fails:
Looks like the change in golang that broke the scenario was:
if the only impact is a different failure message on an already-invalid certificate, I don't care and we can update the test to accept either message is what makes me wonder what previously-accepted certificates are now failing
reproducer test case here. this one has no issues under go 1.17 and fails with go 1.18 (stripped down version of ) : :
the new error message is minted here: i suspect it is related to: So essentially this seems to be something that may hit in our case. right?
yeah, if this is scoped to just darwin clients, and only ones using system roots, that greatly narrows the impact
Asked on gophers slack -
xref:
opened to tolerate the additional errors discussion in indicates the tightened validation is very bounded (darwin-only, so clients-only, system roots only), and certificates issued by public CAs would be expected to pass this validation dropping release-blocking label and priority to important-soon, but should still make it into 1.24 to make unit tests pass locally
Change:
Containers: []v1.Container{ { Name:            ctnName, <del> Image:           "registry.k8s.io/stress:v1", </del> <ins> Image:           imageutils.GetE2EImage(imageutils.Agnhost), </ins> ImagePullPolicy: "Always", Env:             env, // 60 min timeout * 60s / tick per 10s = 360 ticks before timeout => ~11.11Mi/tick // to fill ~4Gi of memory, so initial ballpark 12Mi/tick. // We might see flakes due to timeout if the total memory on the nodes increases. <del> Args:      []string{"-mem-alloc-size", "12Mi", "-mem-alloc-sleep", "10s", "-mem-total", memLimit}, </del> <ins> Args:      []string{"stress", "--mem-alloc-size", "12Mi", "--mem-alloc-sleep", "10s", "--mem-total", memLimit}, </ins> Resources: res, }, },

Discussion:
The image is built as a legacy Schema 1 image and will not work with most runtimes soon: ref:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig node
cc You seemed to have built the image from on 2016-06-24T22:29:32 , could you rebuild and push the image?
/sig testing
I actually ran into an issue with this one a few months ago. There was very little in the image for testing and I believe that pointed me to the new test images they are using. We found that this image was quite old and essentially unmaintained.
Where is the new image?
PR to merge stress to agnhost:
Next:
Change:
if tt.cap != tt.args.v.Cap() { t.Errorf("Unexpected capacity: got=%d want=%d", tt.args.v.Cap(), tt.cap) } <ins> if tt.len != tt.args.v.Len() { t.Errorf("Unexpected length: got=%d want=%d", tt.args.v.Len(), tt.len) } for i := 0; i < tt.args.v.Len(); i++ { nameWanted := fmt.Sprintf("test-%d", i) val := tt.args.v.Index(i).Interface() pod, ok := val.(example.Pod) if !ok || pod.Name != nameWanted { t.Errorf("Unexpected element value: got=%s, want=%s", pod.Name, nameWanted) } } </ins> }) } }

Discussion:
has by default, and since 1.22 has the same. They seem to return wrong results in certain situations combined with / . And / also use , so they also don't work correctly. outputs partial list of pods on the node, doesn't evict some of the pods. To make it work correctly, I had to specify works correctly with any , since it's just a performance optimizing parameter. I can't provide an actual concrete example (no = default ), but instead I show how to reproduce it with a smaller I believe that the same problem occurs with create two deployments. there are 5 pods in each. with --selector=app=another-server and , it shows only 4 pods. I could confirm that the problem happens in both case of and regardless namespace, even with , or <details</details<detailsGCP / GKE Standard </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig api-machinery
/sig node
I think this is indeed a bug, after some simple testing, it seems to be an bug unique to 1.24, let me fix it. /assign
/assign
I can reproduce this error in a 1.24 cluster, but not in a 1.23.6 cluster. All clusters are created via kind, and I'm guessing gke may have cherry-picked some commits or had some of their own changes to their branch. So I think this fix should at least cherry-pick to 1.23 to help other distributions fix this issue.
/remove-sig api-machinery
Change:
PromoterE2eRegistry     string `yaml:"promoterE2eRegistry"` BuildImageRegistry      string `yaml:"buildImageRegistry"` InvalidRegistry         string `yaml:"invalidRegistry"` <ins> GcEtcdRegistry          string `yaml:"gcEtcdRegistry"` </ins> GcRegistry              string `yaml:"gcRegistry"` SigStorageRegistry      string `yaml:"sigStorageRegistry"` GcrReleaseRegistry      string `yaml:"gcrReleaseRegistry"`

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Which test(s) are failing: Since when has it been failing: 02/19 20:21 PST Testgrid link: Reason for failure: Image pull failure Anything else we need to know:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig windows cc