jiebi/CodeConvo huggingface dataset:
Change:
// If the pod network size is /113 or larger, the node CIDR will be set to the same // size and this will be rejected later in validation. // <del> // NOTE: Currently, the pod network must be /66 or larger. It is not reflected here, // but a smaller value will fail later validation. // </del> // NOTE: Currently, the design allows a maximum of 64K nodes. This algorithm splits // the available bits to maximize the number used for nodes, but still have the node // CIDR be a multiple of eight.

Discussion:
The comments in mention the IPv6 /66 restriction. This restriction was removed in PR Also, the unit tests show the /66 as the largest subnet. Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/assign rpothier
/sig cluster-lifecycle
/area ipv6
Change:
c.FuzzNoCustom(obj) obj.BindAddress = fmt.Sprintf("%d.%d.%d.%d", c.Intn(256), c.Intn(256), c.Intn(256), c.Intn(256)) obj.ClientConnection.ContentType = c.RandString() <ins> obj.DetectLocal.ClusterCIDRs = getRandomDualStackCIDR(c) </ins> obj.Linux.Conntrack.MaxPerCore = ptr.To(c.Int31()) obj.Linux.Conntrack.Min = ptr.To(c.Int31()) obj.Linux.Conntrack.TCPCloseWaitTimeout = &metav1.Duration{Duration: time.Duration(c.Int63()) * time.Hour}

Discussion:
pull-kubernetes-unit TestRoundTripFuzzing Only noticed the failure once in No response No response No response
/sig network may be caused by
This flakes in /cc
/assign so the problem is that sometimes the fuzzer generates a random string value that contains a comma, and when that gets converted back from v1alpha1, the comma is treated as punctuation rather than as part of the value. we should probably manually fuzz ClusterCIDRs to contain 0-2 actual CIDR values
/triage accepted
Saw here:
Change:
} storage := pv.Spec.Capacity[api.ResourceStorage] w.Write(LEVEL_0, "Capacity:t%sn", storage.String()) <ins> printVolumeNodeAffinity(w, pv.Spec.NodeAffinity) </ins> w.Write(LEVEL_0, "Message:t%sn", pv.Status.Message) w.Write(LEVEL_0, "Source:n")

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /assign What happened: Now that it's a field, it needs a separate entry in 'kubectl describe'
Change:
endpointsHandler.ValidateRequestCount(t, 0) } <ins> func TestCheckLeftoverEndpoints(t *testing.T) { ns := api.NamespaceDefault // Note that this requests *all* endpoints, therefore the NamespaceAll // below. testServer, _ := makeTestServer(t, api.NamespaceAll, serverResponse{http.StatusOK, &api.EndpointsList{ ListMeta: api.ListMeta{ ResourceVersion: "1", }, Items: []api.Endpoints{{ ObjectMeta: api.ObjectMeta{ Name:            "foo", Namespace:       ns, ResourceVersion: "1", }, Subsets: []api.EndpointSubset{{ Addresses: []api.EndpointAddress{{IP: "6.7.8.9"}}, Ports:     []api.EndpointPort{{Port: 1000}}, }}, }}, }}) defer testServer.Close() client := client.NewOrDie(&client.Config{Host: testServer.URL, Version: testapi.Version()}) endpoints := NewEndpointController(client) endpoints.checkLeftoverEndpoints() if e, a := 1, endpoints.queue.Len(); e != a { t.Fatalf("Expected %v, got %v", e, a) } got, _ := endpoints.queue.Get() if e, a := ns+"/foo", got; e != a { t.Errorf("Expected %v, got %v", e, a) } } </ins> func TestSyncEndpointsProtocolTCP(t *testing.T) { ns := "other" testServer, endpointsHandler := makeTestServer(t, ns,

Discussion:
So we'll leak them and/or reuse them perhaps inappropriately. I imagine this could be pretty hard on kube-proxy after a while. Discovered while working on . was suggesting implementing a generic delete-when-parent-is-deleted mechanism, so I may not try to fix this 100% with my current work on .
Generic mechanism proposal was here:
I think it should be enough to check if endpoints match services once just after we initialize, right?
Yeah that should be enough to close this. Although the general mechanism would be nice, too.
Change:
"k8s.io/api/core/v1" "k8s.io/client-go/tools/record" "k8s.io/kubernetes/pkg/kubelet/cadvisor" <ins> kubecontainer "k8s.io/kubernetes/pkg/kubelet/container" </ins> "k8s.io/kubernetes/pkg/util/mount" )

Discussion:
https://k8s- https://k8s- cc: /kind bug /priority failing-test
Thanks a lot for reporting this! I think I have a fix PR for this issue. Or should we roll PR back?
I've kicked off testing of your PR. If it fixes the cross build, then that may be the easier path than reverting. cc: (sig-node leads)
I also fixed it in since it also touches the imports in that file. Would love to not rebase it yet again for this.
That call would be up to or they would have to determine which approach they prefer (fix on it's own in a small PR, or fix as part of a larger PR to prevent rebase).
Smaller is probably better; that way if the combined one needs to be reverted it doesn't re-break cross as a result. Will rebase if necessary (will depend on queue order.)
Change:
KUBELET_PID=$! PROXY_LOG=/tmp/kube-proxy.log <del> "${GO_OUT}/kube-proxy"  </del> <ins> sudo "${GO_OUT}/kube-proxy"  </ins> -v=${LOG_LEVEL}  --master="http://${API_HOST}:${API_PORT}" >"${PROXY_LOG}" 2>&1 & PROXY_PID=$! SCHEDULER_LOG=/tmp/kube-scheduler.log <del> "${GO_OUT}/kube-scheduler"  </del> <ins> sudo "${GO_OUT}/kube-scheduler"  </ins> -v=${LOG_LEVEL}  --master="http://${API_HOST}:${API_PORT}" >"${SCHEDULER_LOG}" 2>&1 & SCHEDULER_PID=$!

Discussion:
/kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --
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
looks like started a few days ago ! /sig cluster-lifecycle
cc
fix was sent earlier
/sig cluster-lifecycle
thanks :) i saw it yesterday and forgot to raise the issue. i should have checked the PR queue :)
Change:
"Histogram": gstruct.Ignore(), })) } <ins> func haveKeys(keys ...string) types.GomegaMatcher { gomega.ExpectWithOffset(1, keys).ToNot(gomega.BeEmpty()) matcher := gomega.HaveKey(keys[0]) if len(keys) == 1 { return matcher } for _, key := range keys[1:] { matcher = gomega.And(matcher, gomega.HaveKey(key)) } return matcher } </ins>

Discussion:
Node e2e features is failing after PR for graduating swap to beta is merged. After is merged. Test needs to be adjusted for the extra field for swap usage. No response /sig node
/cc
/assign
/triage accepted /priority critical-urgent
Change:
clientNodeInfo, serverNodeInfo nodeInfo ) <del> logContainsFn := func(text string) wait.ConditionFunc { </del> <ins> logContainsFn := func(text, podName string) wait.ConditionFunc { </ins> return func() (bool, error) { <del> logs, err := e2epod.GetPodLogs(cs, ns, podClient, podClient) </del> <ins> logs, err := e2epod.GetPodLogs(cs, ns, podName, podName) </ins> if err != nil { // Retry the error next time. return false, nil

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: n/a Which test(s) are failing: "should resolve connection reset issue [Slow]" Since when has it been failing: it never worked Testgrid link: n/a Reason for failure: The image used for the test is using only IPv4 Anything else we need to know: We should: [x] refactor the code to support IPv6 [ ] ~consolidate the image in agnhost~ [x] configure an IPv6 job to test network https://k8s-,%20IPv6,%20master
/assign /sig-network
GitHub didn't allow me to assign the following users: Billy99. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign /sig-network 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 network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Those labels are not set on the issue: <detailsIn response to : /remove-triage unresolved 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
/help wanted
/help wanted /good-first-issue
/remove-good-first-issue the agnhost promotion process is not something easy for new contributors
Hi, I would like to contribute to this.
good, thanks
sorry , I needed to fix it and I took over, thanks for stepping up /assign /remove help-wanted
OK.Yesterday I have refactor the code to support IPv6, but I understand wrong about consolidate the image in agnhost. I'm sorry for not being able to help.
no worries, it was trickier than I thought, thanks again for your help
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
/remove-lifecycle stale
Change:
}, NodeName: node.Name, }), true, framework.Logf) <ins> if err != nil { return err } </ins> } for _, node := range nodes { By("Compute Cpu, Mem Fraction after create balanced pods.") computeCpuMemFraction(cs, node, requestedResource) } <ins> return nil </ins> } func computeCpuMemFraction(cs clientset.Interface, node v1.Node, resource *v1.ResourceRequirements) (float64, float64) {

Discussion:
Chronically failing test. Perhaps covers deprecated behavior? /sig scalability /assign
shows up in
/sig scheduling is one of scheduling e2e test.
/assign I'll check this one.
According to the log, the balanced pods were not created by scheduler, the cpu/mem usage was unchanged.
This test failing every other run. Fix or disable? Blocking 1.7?
similar to , move to 1.8, but I'll still working on that.
Change:
) const ( <del> nodeShutdownReason          = "Shutdown" nodeShutdownMessage         = "Node is shutting, evicting pods" nodeShutdownNotAdmitMessage = "Node is in progress of shutting down, not admitting any new pods" dbusReconnectPeriod         = 1 * time.Second </del> <ins> nodeShutdownReason             = "Terminated" nodeShutdownMessage            = "Pod was terminated in response to imminent node shutdown." nodeShutdownNotAdmittedReason  = "NodeShutdown" nodeShutdownNotAdmittedMessage = "Pod was rejected as the node is shutting down." dbusReconnectPeriod            = 1 * time.Second </ins> ) var systemDbus = func() (dbusInhibiter, error) {

Discussion:
When using Graceful Node Shutdown feature, status and reason of "shutdown" pod are confusing for users. See where I attempt to address this confusion by documenting the behavior. However, it would be great to improve messages. Perhaps the following renaming: Reason "Shutdown" is confusing because it may appear as a process of shutting down. Better message will also be useful. Reason and Message changed for pods terminated in response to Node shutdown. Shutdown the node and observer the pod status. KEP: kubernetes/enhancements /cc /sig node /help /good-first-issue Kubernetes version (use ): 1.19+ (with feature enabled)
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 : #### What happened: /cc /sig node /help /good-first-issue Kubernetes version (use ): 1.19+ (with feature enabled) </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
/cc
/assign
/assign
Change:
// TODO(#40229): Remove the docker-exec-handler flag. fs.StringVar(&c.DockerExecHandlerName, "docker-exec-handler", c.DockerExecHandlerName, "Handler to use when executing a command in a container. Valid values are 'native' and 'nsenter'.") fs.MarkDeprecated("docker-exec-handler", "this flag will be removed and only the 'native' handler will be supported in the future.") <del> fs.StringVar(&c.NonMasqueradeCIDR, "non-masquerade-cidr", c.NonMasqueradeCIDR, "Traffic to IPs outside this range will use IP masquerade.") </del> <ins> fs.StringVar(&c.NonMasqueradeCIDR, "non-masquerade-cidr", c.NonMasqueradeCIDR, "Traffic to IPs outside this range will use IP masquerade. Set to '0.0.0.0/0' to never masquerade.") fs.MarkDeprecated("non-masquerade-cidr", "will be removed in a future version") </ins> fs.StringVar(&c.PodCIDR, "pod-cidr", "", "The CIDR to use for pod IP addresses, only used in standalone mode.  In cluster mode, this is obtained from the master.") fs.StringVar(&c.ResolverConfig, "resolv-conf", c.ResolverConfig, "Resolver configuration file used as the basis for the container DNS resolution configuration.") fs.BoolVar(&c.CPUCFSQuota, "cpu-cfs-quota", c.CPUCFSQuota, "Enable CPU CFS quota enforcement for containers that specify CPU limits")

Discussion:
When the ip-masq-agent is activated, kubelet installs a rule that looks like: which is nonsensical.
Change:
// must unmounted prior to detach. // If a volume with the name volumeName does not exist in the list of // attached volumes, an error is returned. <del> SetVolumeGloballyMounted(volumeName v1.UniqueVolumeName, globallyMounted bool) error </del> <ins> SetVolumeGloballyMounted(volumeName v1.UniqueVolumeName, globallyMounted bool, devicePath string) error </ins> // DeletePodFromVolume removes the given pod from the given volume in the // cache indicating the volume has been successfully unmounted from the pod.

Discussion:
We fixed invalid device path in bunch of places via - but call still could use invalid device path. That check can sometimes use invalid path and hence can cause UnmountDevice operation to fails even though device has already been unmounted. /sig storage /sig openstack /assign
Actually this does not affect version 1.10 onwards. Not sure if 1.9 is still supported. I think I will close this for now. /close
I just noticed that 1.9 is still supported and hence it is probably worth fixing there for now.
How come the check can "sometimes" use invalid device path?
So on Cinder for example - call would return something like as attach device path. But if you see the linked PR(), will do a and use that device path for global mount. In general it is always a good idea to use device path returned by as single source of truth. This applies to something like EBS with NVMe too where device is discovered via call (but nvme disks aren't directly affected by this bug because returned device path on EBS is bogus).
So on EBS with NVMe for example - check will always fail (but still return success) because it will use something like as device path which does not actually exist on the node.
You said the issue only happens "sometimes". Can you clarify why it only happens occasionally?
doesn't the linked PR make it clear? detection based on the drive serial number (aka It's cinder ID) on the kubelet itself. As for why - Cinder sometimes returns wrong device path on call, I don't know. But it happens and we have worked around it.
Fixed by
Change:
./cmd/libs/go2idl/deepcopy-gen                     | grep "^$(PRJ_SRC_PATH)"                          | xargs go list -e -f '{{.Dir}} {{.Dir}}/*.go');   <del> echo $$DIRECT $$INDIRECT | sed 's/ / nt/g';        </del> <ins> echo $$DIRECT $$INDIRECT | sed 's/ / =,/g' | tr '=,' 'nt';  </ins> ) | sed "s|$$(pwd -P)/||" > $@.tmp;                     cmp -s $@.tmp $@ || cat $@.tmp > $@ && rm -f $@.tmp

Discussion:
I don't know where the at the beginning of the target comes from, but probably from assumptions about sed version that are wrong. I had to update to gnu-sed 4.2.2 to build.
Also ootb on a Mac doesn't work with the rules specified (on el capitan):
does work
I take it back - updating sed did not appear to work. EDIT: I take that back, I had to clean after fixing paste.
most recent OSX version is UNIX certified, a POSIX requires as file argument when reading input from stdin. For , is only guaranteed to work in GNU sed, you need to insert literal newline and tab character there for portability.
Can someone with a mac send a patch? I don't have a mac...
It's update and every should end in instead of having no arguments. , Tim Hockin wrote:
(user should update sed, make needs changes to paste) , Clayton Coleman wrote:
I think we should stick to portable way for , it's too risky for relying on GNUism. If you don't mind, I will make a PR.
Sure, thanks , Cuong Manh Le wrote:
Are you sure the worked? I pull the latest from master, then run the same command above, I got: File is empty.
Make sure you are in your GOPATH in the correct spot for Kube On Jul 14, 2016, at 2:47 AM, Cuong Manh Le wrote: Are you sure the Makefile worked? I pull the latest from master, then run the same command above, I got: F0714 13:36:50. ] Error: Failed making a parser: unable to add directory "": unable to import "": expected 'package', found 'EOF' make: * [Makefile.generatedfiles:201: gendeepcopy] Error 255 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .
If you get the "expected 'package', found 'EOF'" message it is usually because something somewhere failed, and left an empty .go file. make cleangenerated , Cuong Manh Le wrote:
From BSD sed man page: Maybe try that?
It's not about ERE ( enables it), it's about expanding escape sequences in RHS of search and replace .
Change:
v1 "k8s.io/api/core/v1" storage "k8s.io/api/storage/v1" <ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" </ins> ) func NewStorageClass(params map[string]string, allowedTopologies []v1.TopologySelectorTerm) *storage.StorageClass {

Discussion:
Was just perusing the code and looks like we translate regional disks into the "zonal volume ID fmt", and there doesn't seem to be any tests for regional disks running so we should confirm that this works and fix it if it doesn't /assign /cc
/sig storage
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
/remove-lifecycle stale
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
/lifecycle frozen /assign
/assign
Change:
} if daemon.Generation <= daemon.Status.ObservedGeneration { if daemon.Status.UpdatedNumberScheduled < daemon.Status.DesiredNumberScheduled { <del> return fmt.Sprintf("Waiting for rollout to finish: %d out of %d new pods have been updated...n", daemon.Status.UpdatedNumberScheduled, daemon.Status.DesiredNumberScheduled), false, nil </del> <ins> return fmt.Sprintf("Waiting for daemon set %q rollout to finish: %d out of %d new pods have been updated...n", name, daemon.Status.UpdatedNumberScheduled, daemon.Status.DesiredNumberScheduled), false, nil </ins> } if daemon.Status.NumberAvailable < daemon.Status.DesiredNumberScheduled { <del> return fmt.Sprintf("Waiting for rollout to finish: %d of %d updated pods are available...n", daemon.Status.NumberAvailable, daemon.Status.DesiredNumberScheduled), false, nil </del> <ins> return fmt.Sprintf("Waiting for daemon set %q rollout to finish: %d of %d updated pods are available...n", name, daemon.Status.NumberAvailable, daemon.Status.DesiredNumberScheduled), false, nil </ins> } return fmt.Sprintf("daemon set %q successfully rolled outn", name), true, nil }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: In our CI, we run multiple times in parallel when we update multiple deployments. This lets us see the status of all deployments as they run. When a deployment succeeds, the final message tells us the name of the deployment. However, the intermediate "Waiting for rollout to finish" messages do not say the name of the deployment. This means that in order to look at multiple rollouts in parallel, we need to manually pipe through another command to prefix it with the rollout name. What you expected to happen: Each line to mention the rollout name. How to reproduce it (as minimally and precisely as possible): Update any deployment, run , note that intermediate status names don't contain the deployment name. Anything else we need to know?: Arguably another fix would be to allow you to pass multiple rollouts to and have kubectl handle polling multiple deployments in parallel. Environment: This is still true on master by code inspection.
Reiterating the mentions to trigger a notification: <detailsIn response to : 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:
# curl-ing the metrics-server service downloads 14 bytes of unprintable binary # data and sets a return code of success (0). if ! $kubectl exec "$linux_command_pod" --  <del> curl -s -m 20 "http://$service_ip:$service_port" &> $output_file; then </del> <ins> curl -s -m 20 --insecure "https://$service_ip:$service_port" &> $output_file; then </ins> cleanup_deployments echo "Failing output: $(cat $output_file)" echo "FAILED: ${FUNCNAME[0]}"

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add Support for Windows Server version 2004 and 20H2. Why is this needed: Windows Server version 1909 is going end of life.
/sig windows /triage accepted