jiebi/CodeConvo huggingface dataset:
Change:
// PodMetrics sets resource usage metrics of a pod. type PodMetrics struct { metav1.TypeMeta <ins> // Standard object's metadata. // More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata // +optional </ins> metav1.ObjectMeta // The following fields define time interval from which metrics were

Discussion:
no explanation for metadata filed of NodeMetrics/PodMetrics, code: should be like $ kubectl explain NodeMetrics KIND: NodeMetrics VERSION: DESCRIPTION: NodeMetrics sets resource usage metrics of a node. FIELDS: apiVersion <stringAPIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: kind <stringKind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: metadata <Objecttimestamp <string-required- The following fields define time interval from which metrics were collected from the interval [Timestamp-Window, Timestamp]. usage <map[string]string-required- The memory usage is the memory working set. window <string-required- and $ kubectl explain PodMetrics KIND: PodMetrics VERSION: DESCRIPTION: PodMetrics sets resource usage metrics of a pod. FIELDS: apiVersion <stringAPIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: containers <[]Object-required- Metrics for all containers are collected within the same time window. kind <stringKind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: metadata <Objecttimestamp <string-required- The following fields define time interval from which metrics were collected from the interval [Timestamp-Window, Timestamp]. window <string-required- able to see the explanation for metadata filed of NodeMetrics/PodMetrics Kubernetes Version: v1.22.0-rc.0+
/sig instrumentation
/kind documentation /assign /triage accepted
Change:
framework.Logf("Waiting for %s to complete.", podClient.Name) err = e2epod.WaitForPodSuccessInNamespace(f.ClientSet, podClient.Name, ns.Name) if err != nil { <del> // Collect pod logs when we see a failure. logs, logErr := e2epod.GetPodLogs(f.ClientSet, f.Namespace.Name, podClient.Name, "client") if logErr != nil { framework.Failf("Error getting container logs: %s", logErr) } // Collect current NetworkPolicies applied in the test namespace. policies, err := f.ClientSet.NetworkingV1().NetworkPolicies(f.Namespace.Name).List(context.TODO(), metav1.ListOptions{}) if err != nil { framework.Logf("error getting current NetworkPolicies for %s namespace: %s", f.Namespace.Name, err) } // Collect the list of pods running in the test namespace. podsInNS, err := e2epod.GetPodsInNamespace(f.ClientSet, f.Namespace.Name, map[string]string{}) if err != nil { framework.Logf("error getting pods for %s namespace: %s", f.Namespace.Name, err) } pods := []string{} for _, p := range podsInNS { pods = append(pods, fmt.Sprintf("Pod: %s, Status: %sn", p.Name, p.Status.String())) } </del> <ins> pods, policies, logs := collectPodsAndNetworkPolicies(f, podClient) </ins> framework.Failf("Pod %s should be able to connect to service %s, but was not able to connect.nPod logs:n%snn Current NetworkPolicies:nt%vnn Pods:nt%vnn", podClient.Name, service.Name, logs, policies.Items, pods) // Dump debug information for the test namespace.

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: The NetworkPolicy e2e test fails regardless of which CNI plugin is enabled. The test assumes the client Pod can recheck connectivity after updating its label, but the client won't restart after the first failure, so the second check will always fail. What you expected to happen: The test should succeed if a CNI plugin implements NetworkPolicy correctly. How to reproduce it (as minimally and precisely as possible): a CNI that supports NetworkPolicy. the e2e test by focusing "should allow ingress access from updated pod". test will always fail. Anything else we need to know?: Environment: Kubernetes version (use ): 16.3 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig testing /assign
/remove-sig testing /sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
I see this in Calico 3.10 as well confirming that its definitely an issue.
Change:
kubectl expose rc my-nginx --port=80 --type=LoadBalancer ``` <del> This should print the service that has been created, and map an external IP address to the service. </del> <ins> This should print the service that has been created, and map an external IP address to the service. Where to find this external IP address will depend on the environment you run in.  For instance, for Google Compute Engine the external IP address is listed as part of the newly created service and can be retrieved by running ```bash kubectl get services ``` In order to access your nginx landing page, you also have to make sure that traffic from external IPs is allowed. Do this by opening a firewall to allow traffic on port 80. </ins> ### Next: Configuration files Most people will eventually want to use declarative configuration files for creating/modifying their applications.  A [simplified introduction](simple-yaml.md)

Discussion:
nginx example missing step to create firewall rule (tcp:80 targettag:kubernetes-minion) from these instructions:
Change:
framework.ExpectEqual(retrievedDriver2.UID, createdDriver2.UID) ginkgo.By("listing") <del> driverList, err = client.List(context.TODO(), metav1.ListOptions{}) </del> <ins> driverList, err := client.List(context.TODO(), metav1.ListOptions{LabelSelector: "test=" + f.UniqueName}) </ins> framework.ExpectNoError(err) <del> framework.ExpectEqual(len(driverList.Items), numDriversAfter, "list should have %d items, got: %s", numDriversAfter, driverList) </del> <ins> framework.ExpectEqual(len(driverList.Items), 2, "filtered list should have 2 items, got: %s", driverList) </ins> ginkgo.By("deleting") <del> err = client.Delete(context.TODO(), createdDriver1.Name, metav1.DeleteOptions{}) framework.ExpectNoError(err) err = client.Delete(context.TODO(), createdDriver2.Name, metav1.DeleteOptions{}) framework.ExpectNoError(err) driverList, err = client.List(context.TODO(), metav1.ListOptions{}) framework.ExpectNoError(err) framework.ExpectEqual(len(driverList.Items), numDriversBefore, "list should have %d items, got: %s", numDriversBefore, driverList) </del> <ins> for _, driver := range driverList.Items { err := client.Delete(context.TODO(), driver.Name, metav1.DeleteOptions{}) framework.ExpectNoError(err) retrievedDriver, err := client.Get(context.TODO(), driver.Name, metav1.GetOptions{}) switch { case apierrors.IsNotFound(err): // Okay, normal case. case err != nil: framework.Failf("expected 404, got %#v", err) case retrievedDriver.DeletionTimestamp != nil: // Okay, normal case. default: framework.Failf("CSIDriver should have been deleted or have DeletionTimestamp, but instead got: %s", retrievedDriver) } } </ins> }) // TODO: promote to framework.ConformanceIt

Discussion:
https://k8s- CSIInlineVolumes should support ephemeral VolumeLifecycleMode in CSIDriver API 8/5 https://k8s- No response /sig storage
/triage accepted
/assign
Change:
podVolume.Name, format.Pod(pod), err) <ins> allVolumesAdded = false </ins> continue }

Discussion:
Deployment/Service manifest: logs from events: In aws, the volume is attached, On the box: In only one is mounted: Where can I debug this further?
Take a look at the on your master for events related to your volume . That will show you when the volume was attached/detached. It appears that your volume attached without issue so there should be nothing unusual here. Then take a look at on the node that the volume is supposed to be attached to. Looks for the UID of your pod (). I suspect one of your mounts is failing. It looks like you are using hyperkube so it might be a mount namespace propagation issue.
I believe this happens when the RC/Pod is being created shortly after the PV or PVC. The latter two appear to need several seconds to be fully available (even if the status is already set to "Bound"). I ran into the same issue with a NFS PV. When I delete and create PV+PVC+SVC+RC all in one go, the associated Pod will be in ContainerCreating state for several seconds (10,<60), then log the warning event and afterwards be created without any problems or further delays. When I first create PV+PVC, wait for several seconds (30) and only then create SVC+RC, the pod will be created immediately and no warning event will be logged. One oddity I noticed is that the PVC will have capacity 0 and empty access modes (as shown by ), even though it was setup to request ROX for 1Gi and the PV provides 1Gi with ROX. This might be a different bug, though.
Thanks for digging into it The capacity 0 issue () was fixed by PR and is in v1.3.5. This is more or less expected behavior. The mount logic has exponential backoff so if it rapidly encounters PVC/PV does not exist, it'll back off the retries resulting in a longer mount time. We can consider optimizing this particular scenario. But I'll lower the priority on this for now and remove the milestone.
Maybe the "Bound" status could be delayed, so the RC would be held back for a while and be scheduled only when the PVC is actually ready?
I don't think the RC actually waits for PVC to be bound before scheduling.

I have also this problem using deployment with HELM, I deploy all my pv,pvc,deploy,svc in one Charts, and my pod who requiere a volume from the PVC get scheduled and stay in ContainerCreating mode. I need to wait minutes or delete pods for they correctly get rescheduled using the volume. Here is the log when the pod get automaticly deleted (after minutes) : It would be awesome if the deployment or RC wait for the PVC to be bound before schedule !
may slightly improve this situation as the maximum backoff time of 2 minutes will not fire anymore.
Note that the same error is thrown when node-size == C5 or M5 for kubectl and with kops . Solution is to set node as t2 machines. Due to it seems.
Reading from the new solution is:
Change:
### Starting a Kubemark cluster <del> To start a Kubemark cluster on GCE you need to create an external cluster (it can be GCE, GKE or any other cluster) by yourself, build a kubernetes release (e.g. by running `make quick-release`) and run `test/kubemark/start-kubemark.sh` script. This script will create a VM for master components, Pods for HollowNodes </del> <ins> To start a Kubemark cluster on GCE you need to create an external kubernetes cluster (it can be GCE, GKE or anything else) by yourself, make sure that kubeconfig points to it by default, build a kubernetes release (e.g. by running `make quick-release`) and run `test/kubemark/start-kubemark.sh` script. This script will create a VM for master components, Pods for HollowNodes </ins> and do all the setup necessary to let them talk to each other. It will use the configuration stored in `cluster/kubemark/config-default.sh` - you can tweak it however you want, but note that some features may not be implemented yet, as

Discussion:
A glitch I experienced when following the : Although it might be obvious, it doesn't hurt to expand "external cluster" to "external kubernetes cluster". Also, the guide doesn't mention I need to configure my kubectl to target the "external kubernetes cluster" while it's actually required.
Change:
# KUBE_RACE="-race" KUBE_GOFLAGS="-tags 'integration no-docker' "  KUBE_RACE=""  <ins> KUBE_TIMEOUT="${KUBE_TIMEOUT}"  </ins> KUBE_TEST_API_VERSIONS="$1"  KUBE_API_VERSIONS="v1,experimental/v1alpha1"  "${KUBE_ROOT}/hack/test-go.sh" test/integration

Discussion:
The first line logged from the integration test is the last line from the service account token test is then the test panics with: I think the tests are just running too close the the timeout. On successful runs, the tests take ~115 seconds, which is ridiculously close to the threshold. For example: see
ok, do you want to send a PR to increase the timeout to 3 or 4 minutes?
Sure, I can do that tonight

cc
Has this test failed more than once, or did the two-minute timeout just happen to occur in the middle of it?
I think 2 minutes is not sufficient for the integration tests. See comment at
Change:
<del> /* Copyright 2018 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package util import ( "time" ) // Clock provides an interface for getting the current time type Clock interface { Now() time.Time } // RealClock implements a clock using time type RealClock struct{} // Now returns the current time with time.Now func (RealClock) Now() time.Time { return time.Now() } </del>

Discussion:
We should use /kind cleanup
/remove-kind feature /good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /remove-kind feature /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 scheduling /triage accepted
/assign
Change:
"github.com/GoogleCloudPlatform/kubernetes/pkg/api/errors" "github.com/GoogleCloudPlatform/kubernetes/pkg/client" "github.com/GoogleCloudPlatform/kubernetes/pkg/client/cache" <ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/client/record" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/cloudprovider" "github.com/GoogleCloudPlatform/kubernetes/pkg/fields" "github.com/GoogleCloudPlatform/kubernetes/pkg/labels"

Discussion:
If a LoadBalancer cannot be created (e.g. quota limit hit), there is currently no way to know why other than reviewing the logs (?). We could put an status message / object into LoadBalancerStatus.
We could make an event for this too Justin Santa Barbara < :
+1 for event
I think that is reasonable, but we need to be careful how we define it. Event also sounds good. , Justin Santa Barbara < :
I'm in favor of status as well as an event. The pattern I recommend is an array of conditions, similar to NodeCondition, where each contains at least a Status, Reason, and Message.
+1 for an event. I'd argue this is important enough for usability that we should get it into v1.
How often does this failure mode occur?
I unfortunately don't have stats, but it can happen for a handful of reasons. I think these are the most likely: Cloud provider unavailability/errors Ran out of quota from the cloud provider The cluster is using a cloud provider that doesn't support external load balancers I expect the third one is most common by far. We could perhaps move that into the API object validation rather than writing events to handle that particularly case, but using events would solve all the cases together.
Change:
} if !bFoundDisk { <del> return nil, fmt.Errorf("detach azure disk failure, disk %s not found, diskURI: %s", diskName, diskURI) </del> <ins> // only log here, next action is to update VM status with original meta data klog.Errorf("detach azure disk: disk %s not found, diskURI: %s", diskName, diskURI) </ins> } newVM := compute.VirtualMachineScaleSetVM{

Discussion:
What happened: made sure that API calls to Azure that return a HTTP code 200 with an embedded error are retried. Nevertheless, we observe a series of errors during the Azure Disk detach backoff while calling , and the detach operation is immediately cancelled. Happy scenario: the disk is to be re-attached to the same VM. The reconciler's will update the VMSS instance and the previous detach error will be masked. It takes 15 min for the detach call to timeout but the disk will eventually get re-attached after several VMSS updates (). Not-so-happy scenario: the disk is to be re-attached to another VM. The same errors as in will be thrown indefinitely. controller-manager's logs: What you expected to happen: The backoff succeeds and the failed detach operation gets retried. How to reproduce it: A single Pod with a single Azure Disk. This seems quite hard to reproduce, but it is happening consistently in one of our customer's resource group (eastus). Anything else we need to know?: Environment: Kubernetes version: branch (kubernetes/kubernetes Cloud provider: Azure (via AKS-Engine) OS: Ubuntu 16.04.6 LTS Kernel: 4.15.0-1042-azure Install tools: Network plugin and version: Others: /sig azure paging
/assign
Change:
) load("@io_bazel_rules_go//go:def.bzl", "go_repositories") <del> load("@io_bazel_rules_docker//docker:docker.bzl", "docker_repositories") </del> <ins> load("@io_bazel_rules_docker//docker:docker.bzl", "docker_repositories", "docker_pull") </ins> go_repositories( go_version = "1.8.3",

Discussion:
BUG REPORT Kubernetes version 2 Environment: Install tools: What happened: The code in takes care to supply the flag so it will wait on a lock to avoid interference between multiple processes modifying the table. If you read the source you discover it does this by creating a file . However, when is running in a container, is in a local filesystem, so it is not able to lock against processes running on the host or in other containers. And before you decide that the answer is to mount from the host, look at all the issues around leaking netns, e.g. Credit for pointing this out to me. Credit for pointing out locking functionality was to a few months back
Ironically, this is caused by a bugfix that moved to file-based locking. Previously, iptables would lock by reserving an abstract unix socket, which is tied to the network namespace.
Some discussion also in and following comments.
I experimented with this: but it didn't work on CoreOS, as the host wasn't using a version of iptables that used the file lock yet. Just ended up creating a directory call
I guess I should file this as an issue against kubeadm and any of the other sources of kube-proxy container config.
/assign
Should we leave this open (waiting for ... ?)
Waiting for I guess... (which I'm reviewing now)
i think this should not be marked as complete until the kubeadm fixes are in.
/reopen
/close fix in
Change:
}, { // failed syncVolume do not bind when pvc is prebound to pv with mismatching volumeModes <del> "14-8-1 - do not bind when pv is prebound to pvc with mismatching volumeModes", </del> <ins> "14-8-1 - do not bind when pvc is prebound to pv with mismatching volumeModes", </ins> withVolumeVolumeMode(&modeBlock, newVolumeArray("volume14-8-1", "10Gi", "", "claim14-8-1", v1.VolumePending, v1.PersistentVolumeReclaimRetain, classEmpty)), withVolumeVolumeMode(&modeBlock, newVolumeArray("volume14-8-1", "10Gi", "", "claim14-8-1", v1.VolumePending, v1.PersistentVolumeReclaimRetain, classEmpty)), withClaimVolumeMode(&modeFile, newClaimArray("claim14-8-1", "uid14-8-1", "10Gi", "", v1.ClaimPending, nil)),

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?: /kind bug What happened: If a user specifies volumeMode: Block in creating PVC and neither plug-in nor external provisioner doesn't support block, a PV is created, but is not bound to the PVC because the PV and PVC don't match. So, PVC will stay pending forever without any error messages. What you expected to happen: In above case, a proper error message is shown to users to make them understand what's wrong. How to reproduce it (as minimally and precisely as possible): up plug-in and external provisioner that don't support block. PVC using volumeMode: Block. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: KVM OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: hack/local-up- Others: /sig storage
Change:
rbacv1helpers.NewRule(Write...).Groups(legacyGroup).Resources("replicationcontrollers", "replicationcontrollers/scale", "serviceaccounts", "services", "services/proxy", "endpoints", "persistentvolumeclaims", "configmaps", "secrets").RuleOrDie(), <ins> rbacv1helpers.NewRule(Write...).Groups(discoveryGroup).Resources("endpointslices").RuleOrDie(), </ins> rbacv1helpers.NewRule(Write...).Groups(appsGroup).Resources( "statefulsets", "statefulsets/scale", "daemonsets",

Discussion:
Users are not able to view by default as part of the or roles like they are with Users with or roles should be able to view like they are with Have a user with permissions on a namespace. Try to run the command I asked about this in slack and was told that it was an oversight that it wasn't to the default roles. Kubernetes version (use ): 1.21 Cloud provider or hardware configuration: n/a OS (e.g: ): n/a Kernel (e.g. ): n/a Install tools: n/a Network plugin and version (if this is a network-related bug): n/a Others: n/a
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 security
/sig auth