jiebi/CodeConvo huggingface dataset:
Change:
klog.V(2).InfoS("Volume reconstruction finished") } <del> func (rc *reconciler) updateStatesNew(reconstructedVolumes map[v1.UniqueVolumeName]*globalVolumeInfo) { </del> <ins> func (rc *reconciler) updateStates(reconstructedVolumes map[v1.UniqueVolumeName]*globalVolumeInfo) { </ins> for _, gvl := range reconstructedVolumes { err := rc.actualStateOfWorld.AddAttachUncertainReconstructedVolume( //TODO: the devicePath might not be correct for some volume plugins: see issue #54108

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 --We have even encountered such case that pod continuously reports “Unable to attach or mount volumes for pod;...” when kubelet restarted. The reasons are listed in details as below: , as result of apiserver instantaneous unstablility, dswp get pvc‘s pv spec failed, then the pvc volume does not be to dsw. , syncStates() lists all the volume directories locally, and recontructs the volume from local volume, if the volume isn't in dsw, it will put the recontructed volume to asw, but now the volume.OuterVolumeSpecName isn't correct. chance, at this time, In , the fail to pvc volume is to dsw again normally in reconcile() -mountAttachVolumes(), it compares dsw and asw by volume's innerVolumename, it's all the same. but it could not sense the OuterVolumeSpecName dismatch. so it will not re-mount again to update asw cache , it checks pod's volume attach or mount success by comparing volume.OuterVolumeSpecName and , but this pv'c OuterVolumeSpecName isn't correct in asw. so pod continuously reports “Unable to attach or mount volumes for pod;...” reconcile() could sense the reconstruct volume's dismatch to the dsw, then re-mount again to make volume cache consistency Kubernetes version (use ): 1.19.4 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 node
/triage accepted
/assign
CC
I think this is a point that can be optimized. /cc
I will give a fix for this
Thanks for reporting the issue, this innerSpecName and outerSpecName are confusing and cause issues. Please ping me for review when you have a fix. Thanks!
Please don't triage your own issues immediately, give someone else a chance to review them :( /sig storage
okay, I know
Change:
GCE_SOAK_CONTINUOUS_SKIP_TESTS=( "Density.*30spods" "Elasticsearch" <del> "Etcd.*SIGKILL" </del> "externalsloadsbalancer" "identicallysnamedsservices" "networkspartition" "Services.*Typesgoessfrom" <ins> "${DISRUPTIVE_TESTS[@]}"       # avoid component restarts. </ins> ) GCE_RELEASE_SKIP_TESTS=(

Discussion:
We should be testing the reliability of a long-running cluster. These tests kill/restart components or nodes in the cluster, defeating the purpose of a soak cluster.
Example tests: NodessResize Services.restarting DaemonRestart NodessResize Reboot Etcd failure
Agreed. Some of them already seem to be skipped: GCESOAKCONTINUOUSSKIPTESTS=( "Density.30spods" "Elasticsearch" "Etcd.SIGKILL" "externalsloadsbalancer" "identicallysnamedsservices" "networkspartition" "Services.Typesgoessfrom" ) Q
FYI
It'd be hard to prevent regression as more tests are . It might be better if we explicitly define a set of DISRUPTIVETESTS, and include them wherever needed, e.g., GCEPARALLELSKIPTESTS and GCESOAKCONTINUOUSSKIPTESTS. That way, people who are adding tests will be aware of the category. WDYT?
Agreed, that seems like a good idea. Want to send in a PR? Or at least open an issue?
Change:
NumberAvailable:        0, }, <del> msg:  "Waiting for rollout to finish: 0 out of 1 new pods have been updated...n", </del> <ins> msg:  "Waiting for daemon set "foo" rollout to finish: 0 out of 1 new pods have been updated...n", </ins> done: false, }, {

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:
apiVersion: apps/v1 kind: DaemonSet metadata: <del> name: npd-v0.8.7 </del> <ins> name: npd-v0.8.8 </ins> namespace: kube-system labels: k8s-app: node-problem-detector <del> version: v0.8.7 </del> <ins> version: v0.8.8 </ins> kubernetes.io/cluster-service: "true" addonmanager.kubernetes.io/mode: Reconcile spec: selector: matchLabels: k8s-app: node-problem-detector <del> version: v0.8.7 </del> <ins> version: v0.8.8 </ins> template: metadata: labels: k8s-app: node-problem-detector <del> version: v0.8.7 </del> <ins> version: v0.8.8 </ins> kubernetes.io/cluster-service: "true" spec: containers: - name: node-problem-detector <del> image: k8s.gcr.io/node-problem-detector/node-problem-detector:v0.8.7 </del> <ins> image: k8s.gcr.io/node-problem-detector/node-problem-detector:v0.8.8 </ins> command: - "/bin/sh" - "-c"

Discussion:
/cc Can and npd v0.8.8(with ) fix this problem? /sig node Example: node-problem-  /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
Yes, the and npd v0.8.8(with kubernetes/node-problem-detector) should fix this problem
/triage accepted /assign
There are other files that are needed to be updated, for reference Could you please update.
Change:
#run the script once to download the dependent java libraries into the image RUN mkdir /output <del> RUN build/gen-swagger-docs.sh v1 https://raw.githubusercontent.com/GoogleCloudPlatform/kubernetes/master/api/swagger-spec/v1.json https://raw.githubusercontent.com/GoogleCloudPlatform/kubernetes/master/pkg/api/v1/register.go </del> <ins> RUN mkdir /swagger-source RUN wget https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/swagger-spec/v1.json -O /swagger-source/v1.json RUN build/gen-swagger-docs.sh v1 https://raw.githubusercontent.com/GoogleCloudPlatform/kubernetes/master/pkg/api/v1/register.go RUN rm /output/* RUN rm /swagger-source/* </ins> ENTRYPOINT ["build/gen-swagger-docs.sh"]

Discussion:
From gen-swagger-docs should read the local swagger spec rather than fetching it from That way it generates release api-reference when run-gen-swagger-docs is run in release branch and it generates api-reference for HEAD code, when the script is run on HEAD.
Assigning to as per discussion.
Blocks
Change:
found := true writer := newLogWriter(stdout, stderr, opts) msg := &logMessage{} <ins> baseName := filepath.Base(path) dir := filepath.Dir(path) </ins> for { if stop || (limitedMode && limitedNum == 0) { klog.V(2).InfoS("Finished parsing log file", "path", path)

Discussion:
won't output logs after kubelet rotate log filer of the container. kubectl output logs correctly after the log file is rotated. the config to . So kubelet will rotate the log soon. Build a image with this program a deploy with the previous image. the command No response <details</details<detailsNone </details<details</details<details</details<details</details<details</details
/sig node
/area kubelet
/triage accepted /priority important-longterm
/assign since you sent a PR already
Ran into this issue!
Change:
klog.V(5).Infof("Delete service (%s): START clusterName=%q", serviceName, clusterName) serviceIPToCleanup, err := az.findServiceIPAddress(ctx, clusterName, service, isInternal) <del> if err != nil { </del> <ins> if err != nil && !retry.HasStatusForbiddenOrIgnoredError(err) { </ins> return err }

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: controller-manager is stuck in deleting an incorrectly configured LB type service. it cannot be recovered until restarted. What you expected to happen: controller-manager should recover. At least it should allow us to create the service without restarting it. How to reproduce it (as minimally and precisely as possible): put a random IP in above yaml and make sure the resource group doen't exist. Anything else we need to know?: Environment: Kubernetes version (use ): 1.12.4 Cloud provider or hardware configuration: AKS OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig azure
I also want to add that the above repro is stuck in 403. It's possible for it to be stuck in 404 as well when the SP has the right permission.
Can you share the log for 404?
Thanks for reporting the issue. /assign Do you mean other services couldn't be configured when this happens?
correct.
FYI, we had the same issue when the Idle Timeout annotation was set to "3" which isn't a supported case. Will this PR also cover this edge case ?
Unfortunately , this is still not fixed. The idle timeout is not 403 or 404. We need another fix for this (and possibly more for other annotations)
Change:
} // Create the deployment for CoreDNS or retain it in case the CoreDNS migration has failed during upgrade <del> if hasCoreDNSMigrationFailed { </del> <ins> if !canMigrateCorefile { </ins> if err := apiclient.CreateOrRetainDeployment(client, coreDNSDeployment, kubeadmconstants.CoreDNSDeploymentName); err != nil { return err }

Discussion:
What happened: Coredns failed to start in 1.17 deployment when it tried to retain a backed up Corefile with error message: Caddyfile via flag: open /etc/coredns/Corefile: no such file or directory What you expected to happen: Coredns starts normally with the backed-up Corefile How to reproduce it (as minimally and precisely as possible): Deploy a k8s 1.17 cluster and trigger coredns Corefile migration and make it fail. In our case, this was triggered in a three master -setup with 'old' method of running 'kubeadm init' for each master. Also the core-dns docker image used was tagged with '1.6.7-1', apparently causing the corefile migration version check to fail Anything else we need to know?: This seems to be caused by Both 'key' and 'path' are set to 'Corefile-backup' when this function is called. Should the 'path' always stay as 'Corefile' because that is where the container expects to find the config file? Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-02-16T17:51:57Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.3", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-02-16T17:47:13Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: Custom deployment in Openstack environment OS (e.g: ): NAME="SLES" VERSION="15-SP1" VERSIONID="15.1" PRETTYNAME="SUSE Linux Enterprise Server 15 SP1" Kernel (e.g. ): 12.14-197.29-default Install tools: kubeadm Network plugin and version (if this is a network-related bug): Others:
/sig cluster-lifecycle
/assign
/area kubeadm
Change:
"k8s.io/kubernetes/pkg/api" apierrors "k8s.io/kubernetes/pkg/api/errors" <ins> storageerr "k8s.io/kubernetes/pkg/api/errors/storage" </ins> "k8s.io/kubernetes/pkg/api/unversioned" "k8s.io/kubernetes/pkg/fields" "k8s.io/kubernetes/pkg/labels"

Discussion:
Honestly I'm not sure if this is a bug or a feature, but didn't expect it. Filing this to track.
I think it's a bug. Nothing in the code base depends on it that I can see (edit: namespace deletion does, but only via an in-server call which I'd like to see fixed), and we don't let other delete-related fields mutate during update (deleteGracePeriodSeconds)
Change:
t.checkDNSRecordFrom( fmt.Sprintf("%s.%s.svc.%s", serviceNameLocal, f.Namespace.Name, framework.TestContext.ClusterDNSDomain), func(actual []string) bool { <del> return len(actual) >= 1 && actual[0] == fooHostname+"." && actual[1] == "2001:db8::29" </del> <ins> return len(actual) >= 2 && actual[0] == fooHostname+"." && actual[1] == "2001:db8::29" </ins> }, "cluster-dns-ipv6", moreForeverTestTimeout)

Discussion:
We've seen this line of panic from time to time. It is caused by an index out of bounds. The array length check on that line seems to be incorrect. We see this flakiness when running in ipv6 or dualstack-ipv6-primary environments. We do not see this flakiness in ipv4 environments. We've seen these flakes over several months. No response incorrect array length check on , and the right most is out of bounds. No response /sig
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 testing
/milestone 1.25 as this is a networking conformance test that fails
The provided milestone is not valid for this repository. Milestones in this repository: [, , , , , , , , , , , ] Use to clear the milestone. <detailsIn response to : /milestone 1.25 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
/milestone v1.25
/sig network
/assign
thanks for catching it
There is confusion whether or not this is a conformance test. We don't believe it is. The test description does not include . I'll remove the label from the PR.
Change:
for i, uc := range uss.clients { uss.integrators[i] = fq.NewIntegrator(uss.clk) fsName := fmt.Sprintf("client%d", i) <del> uss.expectedInqueue = uss.expectedInqueue + fmt.Sprintf(`				apiserver_flowcontrol_current_inqueue_requests{flowSchema=%q,priorityLevel=%q} 0%s`, fsName, uss.name, "n") </del> <ins> uss.expectedInqueue = uss.expectedInqueue + fmt.Sprintf(`				apiserver_flowcontrol_current_inqueue_requests{flow_schema=%q,priority_level=%q} 0%s`, fsName, uss.name, "n") </ins> for j := 0; j < uc.nThreads; j++ { ust := uniformScenarioThread{ uss:    uss,

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : API priority and fairness metrics have labels such as "priorityLevel" and "flowSchema". These should be "prioritylevel" and "flowschema" respectively. These metrics have been to an exception list: Why is this needed: snake_case is consistent with other metrics. /sig api-machinery /kind cleanup /cc Do we want to do this before 1.20 beta?
yes, lets do that.
/triage accepted Yes, we do not want to go to beta with known wrongness in the metrics.
Change:
return fmt.Errorf("one or more files must be specified as -f rsrc.yaml or --filename=rsrc.json") } } <del> if len(o.newAnnotations) < 1 && len(o.removeAnnotations) < 1 { </del> <ins> if len(o.newAnnotations) < 1 && len(o.removeAnnotations) < 1 && !o.list { </ins> return fmt.Errorf("at least one annotation update is required") } return validateAnnotations(o.removeAnnotations, o.newAnnotations)

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : add --list option to kubectl annotate command Why is this needed: like kubectl label commandshow annotations quickly
/sig cli These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
/assign
Change:
*flexVolume // Runner used to teardown the volume. runner exec.Interface <del> volume.MetricsNil </del> } var _ volume.Unmounter = &flexVolumeUnmounter{}

Discussion:
kind feature What happened: Currently there is no mechanism to report metrics as the flex plugins are not enabled to collect metrics. All flex volumes lack this feature as compared to in-tree/built-in drivers even though it is possible to collect such metrics for most of the plugins. What you expected to happen: Depending on the availability of the metrics from the mounted FS, flex plugins should allow to report metrics for the FS. How to reproduce it (as minimally and precisely as possible): The default behavior that can be proved easily by just running a command similar to the following command on a node that is running a flex volume. This will show that there are no metrics collected for flex volumes. kubectl proxy $curl 127.0.0.1:8001/api/v1/nodes/<IP/proxy/stats/summary Environment**: Kubernetes version (use ): 1.12 Cloud provider or hardware configuration: local x86 OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Linux KubeStorage 4.4.0-130-generic -Ubuntu SMP Thu Jun 14 08:53:28 UTC 2018 x8664 x8664 x86_64 GNU/Linux Install tools: Others: /sig storage
+1 Yes, it will be good, if flex volume can support atleast the default metrics( i.e ), which most of the volume plugins support now. Based upon flex plugin "capabilities" parameters, it can be decided, whether the plugin supports "default metrics" or "nil metrics".
Change:
servicehelpers "k8s.io/cloud-provider/service/helpers" "k8s.io/klog/v2" azcache "k8s.io/legacy-cloud-providers/azure/cache" <ins> "k8s.io/legacy-cloud-providers/azure/retry" </ins> utilnet "k8s.io/utils/net" )

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: controller-manager is stuck in deleting an incorrectly configured LB type service. it cannot be recovered until restarted. What you expected to happen: controller-manager should recover. At least it should allow us to create the service without restarting it. How to reproduce it (as minimally and precisely as possible): put a random IP in above yaml and make sure the resource group doen't exist. Anything else we need to know?: Environment: Kubernetes version (use ): 1.12.4 Cloud provider or hardware configuration: AKS OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig azure
I also want to add that the above repro is stuck in 403. It's possible for it to be stuck in 404 as well when the SP has the right permission.
Can you share the log for 404?
Thanks for reporting the issue. /assign Do you mean other services couldn't be configured when this happens?
correct.
FYI, we had the same issue when the Idle Timeout annotation was set to "3" which isn't a supported case. Will this PR also cover this edge case ?
Unfortunately , this is still not fixed. The idle timeout is not 403 or 404. We need another fix for this (and possibly more for other annotations)
Change:
// GetHTTPCodeFromTestContainer executes a curl via kubectl exec in a test container and returns the status code. func (config *NetworkingTestConfig) GetHTTPCodeFromTestContainer(ctx context.Context, path, targetIP string, targetPort int) (int, error) { <del> cmd := fmt.Sprintf("curl -g -q -s -o /dev/null -w %%{http_code} http://%s:%d%s", targetIP, targetPort, </del> <ins> cmd := fmt.Sprintf("curl -g -q -s -o /dev/null -w %%{http_code} http://%s%s", net.JoinHostPort(targetIP, strconv.Itoa(targetPort)), </ins> path) stdout, stderr, err := e2epod.ExecShellInPodWithFullOutput(ctx, config.f, config.TestContainerPod.Name, cmd) // We only care about the status code reported by curl,

Discussion:
sig-testing-kind: cloud-provider-kind (IPv6), master (dev) [non-serial] (IPv6),%20master%20(dev)%20%5Bnon-serial%5D No response /sig network cc
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
Checking It fails to get a value from the healtcheck nodeport however, it seems it is listening there /help /sig network you were recently working on this area of healthcecks and ip families, does this ring a bell? This should be easy to reproduce using kind and cloud-provider-kind if someone wants to help
This request has been marked as needing help from a contributor. 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 : Checking however, it seems it is listening there /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
/assign
it is not a flake, curl from test container fails because of bad url formatting (for ipv6 hosts).
embarrassing, now I can see it was obvious
Change:
if [ $? -eq 0 ]; then if ! which nsenter > /dev/null; then echo "Do not find nsenter. Install it." <del> mkdir -p /tmp/nsenter-install cd /tmp/nsenter-install curl https://www.kernel.org/pub/linux/utils/util-linux/v2.24/util-linux-2.24.tar.gz | tar -zxf- </del> <ins> NSENTER_BUILD_DIR=$(mktemp -d /tmp/nsenter-build-XXXXXX) cd $NSENTER_BUILD_DIR curl https://www.kernel.org/pub/linux/utils/util-linux/v2.31/util-linux-2.31.tar.gz | tar -zxf- </ins> sudo apt-get update sudo apt-get --yes install make sudo apt-get --yes install gcc <del> cd util-linux-2.24 </del> <ins> cd util-linux-2.31 </ins> ./configure --without-ncurses make nsenter sudo cp nsenter /usr/local/bin <del> rm -rf /tmp/nsenter-install </del> <ins> rm -rf $NSENTER_BUILD_DIR </ins> fi fi

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Code inspection caused me to notice is installing downloading an ancient util-linux in order to build nsenter in a hard coded directory under /tmp. What you expected to happen: A more current version of util-linux would be download into a /tmp directory with a securely generated name. How to reproduce it (as minimally and precisely as possible): Read the section of marked "Install nsenter for ubuntu images". Anything else we need to know?: It's easy enough to use mktemp and download a newer util-linux and I have patches to do so. An alternative might be to do something like with nsenter via a container, but jpetazzo's container is also not actively curated and is using an old version of util-linux too. It's probably not appropriate to simply calculate the latest util-linux and download it, versus a specific one by version. But that means a steady stream of tweaks to update the version in use as new util-linux come out and are demonstrated to still be compatible. Would be a nice place to add CI as Trusty's LTS with a couple more years of support so this issue is unfortunately likely to hang around. Environment: OS (e.g. from /etc/os-release): Ubuntu Trusty Tahr
/sig testing
/assign