jiebi/CodeConvo huggingface dataset:
Code change:
serviceHealthServer := healthcheck.NewServiceHealthServer(hostname, recorder) isIPv6 := ipt.IsIPv6() <ins> var incorrectAddresses []string nodePortAddresses, incorrectAddresses = utilproxy.FilterIncorrectCIDRVersion(nodePortAddresses, isIPv6) if len(incorrectAddresses) > 0 { klog.Warning("NodePortAddresses of wrong family; ", incorrectAddresses) } </ins> proxier := &Proxier{ portsMap:                 make(map[utilproxy.LocalPort]utilproxy.Closeable), serviceMap:               make(proxy.ServiceMap),

Related discussion:
text: What happened: In a dual-stack cluster when specifying both ipv6 and ipv4 addresses in the entries are inserted in ipvs for the ipv6 nodeports but with an invalid ipv4 address; The example shows the ipv4 loopback address but any ipv4 address in will cause a faulty entry. What you expected to happen: No ipv4 entry shall be inserted for the ipv6 nodeport. How to reproduce it (as minimally and precisely as possible): Configure with both ipv4 and ipv6 addresses Bring up a dual-stack cluster with proxy-mode Create a service with ipFamily:IPv6 Do Anything else we need to know?: Proxy-mode=iptables seems to work. With no ipv4 entries are inserted for ipv6 nodeports. In it is recommended to use but doing so makes kube-proxy enter rules for address (in addition to "127.0.0.1"). While these entries cause no harm they can't be used and should not be there. These entries are created for both proxy-mode "iptables" and "ipvs". This should not be handled in this issue but in another (new) issue if needed. Example; Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Kvm's on Ubuntu OS (e.g: ): xcluster Kernel (e.g. ):Install tools: "from scratch" Network plugin and version (if this is a network-related bug): calico/cni:v3.12.0 Others: /sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/area ipvs /area ipv6
/remove-triage unresolved /assign I take this myself if no one objects.
The ipv4 address is obviously a ipv4-converted ipv6 from .
According to the code here (), we may need to filter the before passing it to .
Looks that that's it. Please go ahead and make a PR, or I can do it if you prefer. I will help test the PR of course. Here are some review comments right away; Use v1.IPFamily as param to the filter function rather than The filter function seem usable and generic and may be placed in some "util" package, but leave it as-is and let the maintainers decide that.
Hi feel free to send a PR please, as you have took this already :) I'd like to help review it!
The "addresses" are really CIDRs which make the fix even simpler.
Code change:
go_library( name = "go_default_library", srcs = [ <ins> "bindata.go", </ins> "main.go", <del> ":bindata", ], ) genrule( name = "bindata", srcs = [ "//examples:sources", "//test/images:sources", "//test/fixtures:sources", "//test/e2e/testing-manifests:sources", ], outs = ["bindata.go"], cmd = """ $(location //vendor:github.com/jteeuwen/go-bindata/go-bindata)  -nometadata -o "$(OUTS)" -pkg generated  -prefix $$(pwd)  -ignore .jpg -ignore .png -ignore .md  $(SRCS) """, tools = [ "//vendor:github.com/jteeuwen/go-bindata/go-bindata", </del> ], <ins> tags = ["automanaged"], </ins> )

Related discussion:
text: Cluster logging assumes kubelet stores container log at a specific directory with specific name. Currently the path is: After the CRI work, the path will be: However, we don't have test coverage for this. We don't even know whether the log files are there or not. We should add a node e2e test for this, basically: 1) Create a container which prints logs 2) Check whether the expected log file is created. 3) Check whether the logs are collected in the file as expected. And it would be better to launch a pod to do the check instead of accessing local file system directly, which makes containerizing easier. /cc because you are collecting missing test. /cc
I will try to add a node-e2e test there
I think it's ok to add this for CRI. But there maybe problems on today's interface for rkt. If I'm not wrong, rkt does't store logs at same location with docker. cc/ Is this true?
Thanks! :)
After gets merged, we need to update the test to verify the cri log path.
Code change:
ctx, cancel := context.WithCancel(context.Background()) defer cancel() // Start to follow the container's log. <ins> fileName := file.Name() </ins> go func(ctx context.Context) { podLogOptions := v1.PodLogOptions{ Follow: true, } opts := NewLogOptions(&podLogOptions, time.Now()) <del> ReadLogs(ctx, file.Name(), containerID, opts, fakeRuntimeService, stdoutBuf, stderrBuf) </del> <ins> _ = ReadLogs(ctx, fileName, containerID, opts, fakeRuntimeService, stdoutBuf, stderrBuf) </ins> }(ctx) // log in stdout

Related discussion:
text: Runs k8s with master golang: test Failure was observed on Aug 25th, it is passing after that. However it can be reproduced with stress tool. No response No response It is failing on both ppc and x86 architectures. Steps to reproduce: up golang tip version. clone kubernetes master /sig testing
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
it is a sig node test, sig testing charter is not about doing or maintain tests, we need to remove that old mindset of having a QA department, that is not how software development works or should work :) Besides, thanks for spotting it and submittn a patch /sig node /remove-sig testing
Flaky in
merging this PR will fix the issue
Code change:
return nc.evictionLimiterQPS } <del> // ReducedQPSFunc returns the QPS for when a the cluster is large make </del> <ins> // ReducedQPSFunc returns the QPS for when the cluster is large make </ins> // evictions slower, if they're small stop evictions altogether. func (nc *Controller) ReducedQPSFunc(nodeNum int) float32 { if int32(nodeNum) > nc.largeClusterThreshold {

Related discussion:
text: The arg large-cluster-size-threshold for kube-controller-manager works as zone size threshold when determining node eviction rate. If there are multiple zones, the description for arg stating "cluster" threshold would be missleading. ARG: Matched arg description Multiple zones cluster No response <details</details<details</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 docs
Code change:
name = "go_default_test", srcs = ["healthz_test.go"], embed = [":go_default_library"], <ins> deps = [ "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", ], </ins> ) go_library(

Related discussion:
text: What would you like to be : Add support to the kube-apiserver so that we can disable health-checks via query params. Why is this needed: Currently, the healthz endpoint is inflexible in that any and all health checks are currently executed when the endpoint is hit. Since the kube-apiserver only currently supports a liveness check, this means all persistent health check failures will eventually result in a kubelet driven restart. However, this may not be desirable behavior if you have additional monitoring services layered on top of your control plane. For instance, take the etcd failure from the perspective of the kube-apiserver. Currently, persistent failures during the etcd health check from the api-server healthz endpoint will cause the kube-apiserver to be restarted. This sometimes helps (in the case of a faulty etcd-client connection) but also can be detrimental (the kube-apiserver restarts until the etcd cluster is functioning, then the kube-apiserver bombards the etcd cluster with requests to update local caches, saturating the etcd cluster with requests, causing it to timeout on its own liveness probes and trigger a kubelet-driven restart). Let's say that we could now disable etcd from our liveness health check. Then if we had an external monitoring service, we could ask independently ask etcd if it was healthy and we could also ask the kube-apiserver if it thought etcd was unhealthy. Based on the combination of those answers, we could enable more intelligent responses to certain situation, like restarting the kube-apiserver when it thought etcd was unhealthy but etcd was actually reporting as healthy but not doing so when etcd was actually unhealthy. This feature is backwards-compatible and opt-in. There would be no impact to existing behavior unless these query params are actually used. /sig api-machinery /kind feature
/cc
SGTM
/assign
Code change:
}, } <del> var betaTest *testsuites.StorageClassTest </del> for i, t := range tests { // Beware of closure, use local variables instead of those from // outer scope

Related discussion:
text: <!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --ci-kubernetes-e2e-gci-gce-slow [sig-storage] Dynamic Provisioning DynamicProvisioner [Slow] should provision storage with different parameters 5/13 https://k8s- v1beta1.StorageClass got removed in We should remove the v1beta1 test.
/assign can you help take a look?
/triage accepted
/sig storage
I run the test with the latest from master without removing the beta test and it failed with a different error before getting to the beta test part: Do you have any idea what would've happened in my setup? I redeployed k/k using master HEAD
For this testcase: I saw that the provisioned PD has a size of 1.5Gi according to kubernetes: And in gcloud It's really interesting that the test was expecting 2Gi to be created, is this something that was changed recently?
The logs you posted are showing pd csi as the provisioner. Were you testing with the intree driver or csi driver? The CSI driver should to the nearest Gb. I believe intree does the .
I think I did intree because I didn't send as an argument in my command: It's interesting that the PVC has this annotation too:
mmm something interesting about my setup is that I created the cluster with CSIMigration turned on Do you think that might be forcing the usage of ?
Yes likely. Try with CSIMigration off and see if that helps. If so, then this potentially seems like a rounding bug with the csi driver
Thanks I tried with and it did indeed round up to 2Gi.
Code change:
t.Errorf("No client request should have been made") } } <ins> // TestAdmissionNamespaceExistsUnknownToHandler func TestAdmissionNamespaceExistsUnknownToHandler(t *testing.T) { namespace := "test" mockClient := &client.Fake{ Err: errors.NewAlreadyExists("namespaces", namespace), } store := cache.NewStore(cache.MetaNamespaceKeyFunc) handler := &provision{ client: mockClient, store:  store, } pod := api.Pod{ ObjectMeta: api.ObjectMeta{Name: "123", Namespace: namespace}, Spec: api.PodSpec{ Volumes:    []api.Volume{{Name: "vol"}}, Containers: []api.Container{{Name: "ctr", Image: "image"}}, }, } err := handler.Admit(admission.NewAttributesRecord(&pod, namespace, "pods", "CREATE")) if err != nil { t.Errorf("Unexpected error returned from admission handler") } } </ins>

Related discussion:
text: While running one of my soak tests I noticed the error message: I don't see why I should get this error message. Why should it matter if the namespace already exists? It was created as part of the service creation call just beforehand. And the second attempt to create this pod in exactly the same namespace works. Is this a bug?
Running a second time did not produce this error.
I agree it should not matter. The error is produced there, and I suspect there were multiple concurrent calls being made that try to create a resource in a namespace that had not yet existed. We need to update the code in question to swallow the error if the namespace already exists.
FYI - longer term, I would like to eliminate the use of autoprovision of namespace and require you to first create a namespace manually. what is there now is more to preserve existing behavior prior to namespace as object was introduced.
Code change:
// will not need to be updated until new changes are applied (detach is triggered again) time.Sleep(100 * time.Millisecond) verifyVolumeAttachedToNode(t, generatedVolumeName, nodeName1, cache.AttachStateAttached, asw) <del> verifyVolumeReportedAsAttachedToNode(t, logger, generatedVolumeName, nodeName1, true, asw) // After the first detach fails, reconciler will wait for a period of time before retrying to detach. // The wait time is increasing exponentially from initial value of 0.5s (0.5, 1, 2, 4, ...). // The test here waits for 100 Millisecond to make sure it is in exponential backoff period after // the first detach operation. At this point, volumes status should not be updated time.Sleep(100 * time.Millisecond) verifyVolumeAttachedToNode(t, generatedVolumeName, nodeName1, cache.AttachStateAttached, asw) verifyVolumeNoStatusUpdateNeeded(t, logger, generatedVolumeName, nodeName1, asw) // Wait for 600ms to make sure second detach operation triggered. Again, The volume will be // removed from being reported as attached on node status and then added back as attached. // The volume will be in the list of attached volumes that need to be updated to node status. time.Sleep(600 * time.Millisecond) verifyVolumeAttachedToNode(t, generatedVolumeName, nodeName1, cache.AttachStateAttached, asw) verifyVolumeReportedAsAttachedToNode(t, logger, generatedVolumeName, nodeName1, true, asw) </del> <ins> verifyVolumeReportedAsAttachedToNode(t, logger, generatedVolumeName, nodeName1, true, asw, volumeAttachedCheckTimeout) </ins> // Add a second pod which tries to attach the volume to the same node. // After adding pod to the same node, detach will not be triggered any more.

Related discussion:
text: But I may have no time to dig into the cause. Let's see.
cc as the test author.
The problem is that this test has a lot of dependency on the sleeps that are hardcoded with a very narrow scope, but our CI seems to be able to stress it much more. As soon as you slightly change one of the sleep duration it starts to flake locally The test can not make an assumption that timing is perfect, even more in the sub second range can someone in sig-storage review this test and make it less dependant on those tight sleeps?
According to most failures, it failed at Line 660. Let me run some stress locally. with 250ms sleep with 100ms sleep
I agree this test case is too brittle due to its specific timing dependencies. To fix this, I suggest reworking the test case to: 1) Add retry with timeout to wait for final conditions 2) Remove the intermediate timing-based state transition checks. Instead, we can keep track of state transitions in the Fakes and validate those stats. wdyt?
Friendly ping from 1.27 CI Signal that this test is still a noisy flake on the master-blocking dashboard as CI Signal has flagged it in and
Code change:
<del> apiVersion: admissionregistration.k8s.io/v1alpha1 kind: ValidatingAdmissionPolicy metadata: annotations: annotationsKey: annotationsValue creationTimestamp: "2008-01-01T01:01:01Z" deletionGracePeriodSeconds: 10 deletionTimestamp: "2009-01-01T01:01:01Z" finalizers: - finalizersValue generateName: generateNameValue generation: 7 labels: labelsKey: labelsValue managedFields: - apiVersion: apiVersionValue fieldsType: fieldsTypeValue fieldsV1: {} manager: managerValue operation: operationValue subresource: subresourceValue time: "2004-01-01T01:01:01Z" name: nameValue namespace: namespaceValue ownerReferences: - apiVersion: apiVersionValue blockOwnerDeletion: true controller: true kind: kindValue name: nameValue uid: uidValue resourceVersion: resourceVersionValue selfLink: selfLinkValue uid: uidValue spec: auditAnnotations: - key: keyValue valueExpression: valueExpressionValue failurePolicy: failurePolicyValue matchConditions: - expression: expressionValue name: nameValue matchConstraints: excludeResourceRules: - apiGroups: - apiGroupsValue apiVersions: - apiVersionsValue operations: - operationsValue resourceNames: - resourceNamesValue resources: - resourcesValue scope: scopeValue matchPolicy: matchPolicyValue namespaceSelector: matchExpressions: - key: keyValue operator: operatorValue values: - valuesValue matchLabels: matchLabelsKey: matchLabelsValue objectSelector: matchExpressions: - key: keyValue operator: operatorValue values: - valuesValue matchLabels: matchLabelsKey: matchLabelsValue resourceRules: - apiGroups: - apiGroupsValue apiVersions: - apiVersionsValue operations: - operationsValue resourceNames: - resourceNamesValue resources: - resourcesValue scope: scopeValue paramKind: apiVersion: apiVersionValue kind: kindValue validations: - expression: expressionValue message: messageValue messageExpression: messageExpressionValue reason: reasonValue variables: null status: conditions: - lastTransitionTime: "2004-01-01T01:01:01Z" message: messageValue observedGeneration: 3 reason: reasonValue status: statusValue type: typeValue observedGeneration: 1 typeChecking: expressionWarnings: - fieldRef: fieldRefValue warning: warningValue </del>

Related discussion:
text: spec.variables should be marked omitempty. I'm trying to create a validating admission policy that uses in v1.27 as follows: I'm setting : to "Strict" in CreateOptions so that the server will reject requests with unknown fields but it complains that the don't exist in v1.27 and it does make sense because this field was introduced in v1.28: I'm using a 1.28 client.
/sig api-machinery
/assign
/assign /triage accepted
Thanks for raising this! /cc
Code change:
return } <ins> func (az *azPublicIPAddressesClient) GetVirtualMachineScaleSetPublicIPAddress(ctx context.Context, resourceGroupName string, virtualMachineScaleSetName string, virtualmachineIndex string, networkInterfaceName string, IPConfigurationName string, publicIPAddressName string, expand string) (result network.PublicIPAddress, err error) { if !az.rateLimiterReader.TryAccept() { err = createRateLimitErr(false, "VMSSPublicIPGet") return } klog.V(10).Infof("azPublicIPAddressesClient.GetVirtualMachineScaleSetPublicIPAddress(%q,%q): start", resourceGroupName, publicIPAddressName) defer func() { klog.V(10).Infof("azPublicIPAddressesClient.GetVirtualMachineScaleSetPublicIPAddress(%q,%q): end", resourceGroupName, publicIPAddressName) }() mc := newMetricContext("vmss_public_ip_addresses", "get", resourceGroupName, az.client.SubscriptionID, "") result, err = az.client.GetVirtualMachineScaleSetPublicIPAddress(ctx, resourceGroupName, virtualMachineScaleSetName, virtualmachineIndex, networkInterfaceName, IPConfigurationName, publicIPAddressName, expand) mc.Observe(err) return } </ins> func (az *azPublicIPAddressesClient) List(ctx context.Context, resourceGroupName string) ([]network.PublicIPAddress, error) { if !az.rateLimiterReader.TryAccept() { return nil, createRateLimitErr(false, "PublicIPList")

Related discussion:
text: <!-- 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: Node external IP of azure VMSS cannot be obtained when cloud-controller-manager is enabled. Corresponding logs are shown as follows:
/sig azure
/milestone v1.16
Code change:
return nil, err } <del> res := metricObj.(*v1beta2.MetricValueList) </del> <ins> var res *v1beta2.MetricValueList var ok bool if res, ok = metricObj.(*v1beta2.MetricValueList); !ok { return nil, fmt.Errorf("the custom metrics API server didn't return MetricValueList, the type is %v", reflect.TypeOf(metricObj)) } </ins> return res, nil }

Related discussion:
text: <!-- 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: What you expected to happen: kube-controller-manager should not panic. How to reproduce it (as minimally and precisely as possible): Kubernetes 1.12.6, , and Anything else we need to know?: It's running and , and logs says: Don't see any notable errors in . Is that because it's running the old ? Basically, is expecting , but somehow it's getting which I assume Environment: Kubernetes version (use ): v1.12.6 Cloud provider or hardware configuration: AWS EC2 OS (e.g: ): Amazon Linux 2 Kernel (e.g. ): 4.14.109-99.92.amzn2.x86_64
Could be related to , but this happens with all the patches from the issue /sig scalability /cc
/sig autoscaling /assign can you triage please?
/sig-remove scalabilty
/sig remove scalability
/sig scalability remove
/remove-sig scalability
API returned v1.Status instead of v1beta2.MetricValueList. We should check what is the type of the object
/sig instrumention
/assign
/sig instrumentation
seems promising. Is it missing anything?
I've root-caused the issue. Explained here -
Yep, should address the issue.
Code change:
if protocol == "udp" { // TODO: It would be enough to pass 1s+epsilon to timeout, but unfortunately // busybox timeout doesn't support non-integer values. <del> cmd = fmt.Sprintf("echo 'hostName' | nc -w 1 -u %s %d", targetIP, targetPort) </del> <ins> cmd = fmt.Sprintf("echo hostName | nc -w 1 -u %s %d", targetIP, targetPort) </ins> } else { ipPort := net.JoinHostPort(targetIP, strconv.Itoa(targetPort)) // The current versions of curl included in CentOS and RHEL distros

Related discussion:
text: <!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: N/A Which test(s) are failing: should function for node-pod communication: udp Since when has it been failing: Unknown. Testgrid link: The test is currently excluded. Reason for failure: By default, cmd is used to execute commands in Windows containers, but it has some issues executing the command (no output): echo 'hostName' | nc -w 1 -u <targetIP<targetPortBut it has no issues running (output is correct): echo hostName | nc -w 1 -u <targetIP<targetPortThis causes the test "should function for node-pod communication: udp" to fail when using Windows Containers. Anything else we need to know: /sig testing /sig windows