jiebi/CodeConvo huggingface dataset:
Code change:
// Store volume metadata for UnmountDevice. Keep it around even if the // driver does not support NodeStage, UnmountDevice still needs it. <del> if err = os.MkdirAll(deviceMountPath, 0750); err != nil && !corruptedDir { </del> <ins> if err = os.MkdirAll(deviceMountPath, 0750); err != nil { </ins> return errors.New(log("attacher.MountDevice failed to create dir %#v:  %v", deviceMountPath, err)) } klog.V(4).Info(log("created target path successfully [%s]", deviceMountPath))

Related discussion:
text: For the mount point checking here before calling NodePublishVolume, I am wondering it is just for performance optimization, or it has other purposes. Have concern about some drivers might depend on this check if they are not implemented with idenpotency.
Those drivers would be operating in violation of the specification. I'd prefer that we don't penalize already conforming and yet-to-be written drivers in order to accommodate these existing drivers—if they even exist.
More fallout in last night's testing: I introduced a bug into my driver that caused it to panic during ("Writing that data to a set of files in the mounted filesystem"). My handler function is set up to unmount a successfully mounted volume via if it doesn't complete steps 2 and 3 above, in order to deal with this issue's principal complaint. My driver container would crash due to this panic. The kubelet would call on my driver twice, it would crash twice, but the pod still started running. I'm not yet sure whether or not the filesystem got unmounted successfully via the on the first call, but somehow the pod started despite my handler function never completing successfully. I'm going to try to get some more debugging time on this later today to see if I can figure out what the kubelet was doing there.
Studying my code more, I see that my function only unmounted the mounted directory when the containing handler function was returning an error. When unwinding due to a panic, the named return value of type I was inspecting was still nil. Revising the criteria in that function covers both failure reasons (returning an and unwinding due to a panic). Regardless, this further underscores the problem: If a driver makes it as far as mounting a filesystem at the target directory, but fails afterward—including the process crashing and never responding positively to the RPC—the mounting pod will start. That's likely to then cause the pod to fail, for lack of the files it expected to find mounted.
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.
Code change:
// Store volume metadata for UnmountDevice. Keep it around even if the // driver does not support NodeStage, UnmountDevice still needs it. <del> if err = os.MkdirAll(deviceMountPath, 0750); err != nil && !corruptedDir { </del> <ins> if err = os.MkdirAll(deviceMountPath, 0750); err != nil { </ins> return errors.New(log("attacher.MountDevice failed to create dir %#v:  %v", deviceMountPath, err)) } klog.V(4).Info(log("created target path successfully [%s]", deviceMountPath))

Related discussion:
text: 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
/remove-lifecycle stale
Code change:
# have failed before getting to the "echo" in the block below. diff=$(find_files | xargs ${gofmt} -d -s 2>&1) || true if [[ -n "${diff}" ]]; then <del> echo "${diff}" </del> <ins> echo "${diff}" >&2 echo >&2 echo "Run ./hack/update-gofmt.sh" >&2 </ins> exit 1 fi

Related discussion:
text: <!-- 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?: When running on my commits locally I got the following error: Affected PRs:
/sig testing
/cc
There's likely something up with your local environment. These jobs are running correctly in CI, although you need to look at the build log for output
Code change:
if len(keySplit) == 5 && keySplit[4] == "device-number" { for i, macElem := range m.aws.networkInterfacesMacs { if macParam == macElem { <del> return fmt.Sprintf("%dn", i), nil </del> <ins> n := i if n > 0 { // Introduce an artificial gap, just to test eg: [eth0, eth2] n++ } return fmt.Sprintf("%dn", n), nil </ins> } } }

Related discussion:
text: What happened: does not handle "holes" in interface device-number correctly, dropping later interfaces. Create instance with eth0, eth1, eth2 ENIs as usual. Remove (eg: by selectively deleting pods) eth1. Only the addresses on eth0 are reported by NodeAddresses. What you expected to happen: Addresses on eth0 and eth2 should be reported.
/sig cloud-provider These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
Code change:
continue } c.watchersBuffer = append(c.watchersBuffer, watcher) <del> // Given that we send bookmark event once at deadline-2s, never push again // after the watcher pops up from the buckets. Once we decide to change the // strategy to more sophisticated, we may need it here. </del> <ins> // Requeue the watcher for the next bookmark if needed. c.bookmarkWatchers.addWatcher(watcher) </ins> } } }

Related discussion:
text: Currently, (best-effort) watch bookmarks are sent just right before the given watch is supposed to timeout: In we're adjusting how the size of watch cache is determined and make it dynamic and more duration-oriented (rather than based on some magic constants) - we're targeting to always keep 5 minutes of history in watch cache. With that change, we should get back to our bookmark policy: change it to (additionally to right before timeout) also send bookmarks every N seconds (setting N to slightly less than expected watch cache history period, so slightly less than X minutes we will use there) scale-test this change (to see if it doesn't introduce non-negligible overhead) if so permanently introduce this change /sig scalability api-machinery
/cc
/cc
/cc
I'm reverting as it broke bookmarks. I'm going to fix and re-submit for review hopefully later this week.
Code change:
if err != nil { return err } <ins> printService(o.Out, "Kubernetes master", o.Client.Host) </ins> services := r.Object.(*api.ServiceList).Items for _, service := range services { var link string

Related discussion:
text: /kind bug What happened: The wording of kubectl cluster-info is misleading. When no cluster is running, it will state (in green) that the kubernetes master is running. What you expected to happen: I would expect a different message, like Or a How to reproduce it (as minimally and precisely as possible): Execute kubectl with no config files, and no local kubernetes cluster running on 8080
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
Code change:
}, } <del> # In the bash-based build (build/lib/release.sh), the images built for amd64 do not use # an arch in their name (but other arches do), and the GCE cluster scripts # (which sideload the images via tarfiles) expect there not to be an arch. </del> # When pushing to gcr.io, we want to use an arch, since the archless name is now used for a # manifest list. Bazel doesn't support manifest lists (yet), so we can't do that either. <del> # For now, we use the archless name for the image tars saved in the server tarball, # to satisfy GCE and other similar providers. (If one were to pull the images via the manifest # list, the arch wouldn't appear in the name either.) </del> [multi_arch_container( name = binary, architectures = SERVER_PLATFORMS["linux"],

Related discussion:
text: What happened: When we build with make to build k8s, it will use 'amd64' in the container names. This is not the case for bazel builds, which are still using something like 'kube-apiserver' instead of 'kube-apiserver-amd64' What you expected to happen: Images build with make or bazel should have 'amd64' in the container name How to reproduce it (as minimally and precisely as possible): make quick-release cat inside tar "RepoTags": ["" make bazel-release cat inside tar "RepoTags": [""
/sig cluster-lifecycle /assign
+1 we need to standardize both builds to generate the same. +1 to add to the bazel build
FYI
+1, cc
bazel / docker build parity SGTM.
+1. Perhaps we should document a standard, like: All docker images that are arch specific should have the arch in the name Arch is only able to be omitted when it's a manifest-based tag (multi-arch) Document legacy exceptions, and hopefully bring them into compliance /cc
i like it. where is the best spot to doc this?
-- please doc as updates to:
Created
Code change:
return job, nil } <del> func getTimeHash(scheduledTime time.Time) uint32 { timeHasher := adler32.New() hashutil.DeepHashObject(timeHasher, scheduledTime) return timeHasher.Sum32() </del> <ins> // Return Unix Epoch Time func getTimeHash(scheduledTime time.Time) int64 { return scheduledTime.Unix() </ins> } // makeCreatedByRefJson makes a json string with an object reference for use in "created-by" annotation value

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): Environment: Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): Debian GNU/Linux 8 (jessie) Kernel (e.g. ): 3.16.36-1+deb8u1 (2016-09-03) x86_64 GNU/Linux What happened: Deployed a scheduled job from this manifest: After some time the jobs are no longer executed: What you expected to happen: Jobs are executed as defined in the manifest. How to reproduce it (as minimally and precisely as possible): Deploy a scheduled job and wait for some time.
Some logs from the controller manager:
Ping. More than 2 weeks and no action at all? Anything else i can do?
I'm also encountering this using both and as concurrency policies, fwiw.
I'm hitting this as well. Kube
Do the jobs start to reschedule if you delete old one? Try running . cc
From kube-controller-manager logs: The job is scheduled for 1:00. I think the "Multiple unmet start times" message is a clue of where things start going downhill. Also, notice how at 1:00 the controller wants to create job (for a whole day, it had failed on ).
Deleting (all) old jobs / pods fixes the problem temporarily. After some time the scheduled jobs face the same issue again.
There's a fix () that I've submitted against master to fix the Replace strategy, I'll mark it for inclusion in 1.4.
The other problem that I see here is this: It is possible that our is creating duplicates. I'll try to investigate that a bit more.
sorry for the delay in response time, I must have missed that while going through issues. Next time you're experiencing problems/have a question wrt Jobs/ScheduledJobs, just ping me directly in the issue.
No problem and I will. Thanks!
I'm still hitting this on
Fix in flight , I'll make sure to cherry-pick it back to 1.4
does this ship in to latest kubernetes release?
yes, this should be present in 1.5, 1.4 cherry-pick hasn't been merged yet.
so this issue is still present in v1.4.6?
Code change:
return job, nil } <del> func getTimeHash(scheduledTime time.Time) uint32 { timeHasher := adler32.New() hashutil.DeepHashObject(timeHasher, scheduledTime) return timeHasher.Sum32() </del> <ins> // Return Unix Epoch Time func getTimeHash(scheduledTime time.Time) int64 { return scheduledTime.Unix() </ins> } // makeCreatedByRefJson makes a json string with an object reference for use in "created-by" annotation value

Related discussion:
text: yes - it is still present there. My fix was merged to 1.4 yesterday. You should wait for the next 1.4.x release.
thanks!
which according to should happen Dec 8th.
any news on the release?
See !msg/kubernetes-dev/o0At2-4KKQ8/_kPVM1XyDAAJ
so v1.4.7 will be released on that same day?
Look like should be available later today: !msg/kubernetes-dev/00lJpT9pxDc/YZfDzCxMDQAJ
Code change:
Annotations: newPodAnnotations(pod), } <ins> dnsServers, dnsSearches, useClusterFirstPolicy, err := m.runtimeHelper.GetClusterDNS(pod) if err != nil { return nil, err } podSandboxConfig.DnsConfig = &runtimeapi.DNSConfig{ Servers:  dnsServers, Searches: dnsSearches, } if useClusterFirstPolicy { podSandboxConfig.DnsConfig.Options = defaultDNSOptions } </ins> if !kubecontainer.IsHostNetworkPod(pod) { <del> dnsServers, dnsSearches, _, err := m.runtimeHelper.GetClusterDNS(pod) if err != nil { return nil, err } podSandboxConfig.DnsConfig = &runtimeapi.DNSConfig{ Servers:  dnsServers, Searches: dnsSearches, Options:  defaultDNSOptions, } </del> // TODO: Add domain support in new runtime interface hostname, _, err := m.runtimeHelper.GeneratePodHostNameAndDomain(pod) if err != nil {

Related discussion:
text: Kubernetes version (use ): HEAD (~v1.6.0-beta.4) Environment: any What happened: I want to use ClusterFirstWithHostNet which was implemented in , but only dockertools (legacy/non-CRI) was updated to support this feature. The CRI dockershim should be modified to support this rewriting the file of Pods with HostNetwork=true as well. This is a bug in v1.6, I hope it can be prioritized to be fixed in v1.6.1, since it's blocking me from using CRI. Since CRI is enabled by default, it's expected that it should have feature parity with the earlier implementation.
Related
- I guess I didn't realize these crossed paths. Do you have time to take a look?
Will take a look
Thanks! Ping me directly on this.
Filed for supporting it in CRI.
Code change:
return done, nil }) <del> if pollErr == wait.ErrWaitTimeout { </del> <ins> if pollErr != nil { </ins> t.Fatalf("failed to get the expected healthz status of !OK for check: %s, error: %v, debug inner error: %v", checkName, pollErr, restErr) } }

Related discussion:
text: {Failed === RUN TestKMSv2Healthz --- FAIL: TestKMSv2Healthz (167.38s) also shown in " TestKMSv2Healthz": 1, Not sure No response No response /sig auth
/assign /triage accepted Use for poll interval Change the poll timeout to 5m Update the poll error check (check if not nil)
Code change:
}, }, }, http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { <del> pinged = true </del> <ins> time.Sleep(3 * time.Second) pinged.Store(true) </ins> service.ServeHTTP(w, r) })) testCtx, cancel := context.WithCancel(context.Background()) defer cancel() go aggregatedManager.Run(testCtx.Done()) <del> require.True(t, waitForEmptyQueue(testCtx.Done(), aggregatedManager)) </del> <ins> require.True(t, waitForQueueComplete(testCtx.Done(), aggregatedManager)) </ins> // immediately check for ping, since Run() should block for local services <del> if !pinged { </del> <ins> if !pinged.Load() { </ins> t.Errorf("service handler never pinged") } }

Related discussion:
text: pull-kubernetes-unit sometimes fails with data race. TestDirty I think the test was 3 months ago with the flaking state. There are two issues. First, updating and reading a bool-type variable is not thread-safe. and there is also another problem checking the state before completely syncing it. No response /sig api-machinery
/assign
/triage accepted
Code change:
f := framework.NewDefaultFramework("volume-limits-on-node") ginkgo.BeforeEach(func() { e2eskipper.SkipUnlessProviderIs("aws", "gce", "gke") <ins> // If CSIMigration is enabled, then the limits should be on CSINodes, not Nodes, and another test checks this e2eskipper.SkipIfCSIMigrationEnabled() </ins> c = f.ClientSet framework.ExpectNoError(framework.WaitForAllNodesSchedulable(c, framework.TestContext.NodeSchedulableTimeout)) })

Related discussion:
text: Right now, we have e2e test for that executes only CSI mock driver with artificial limit of 2 volumes per node. We need a test with real CSI driver(s). Proposal: Allow individual test storage drivers to specify if they support CSI limits. Add a test that picks a random node and creates as many pods with a PV that the volume can handle (128 on GCE!). Check that the node can't handle any other volume. Make this test part of . Add similar test(s) for in-tree volume plugins. Make sure the tests work with in-tree volume plugins migrated to CSI.
/sig storage
/assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
This sounds important /remove-lifecycle rotten /lifecycle frozen
/priority backlog
To add to this I believe we should test that an in-tree plugin and its "replacement" CSI Driver share the same attach limits (both max and current usage)
/cc
I see this test has been here: But I want to add a more basic/faster version of the test that simply checks if a driver has then has been set in CSINode, similar to wdyt, would it be useful?
This is a really old issue :-D. I think the required test has been implemented, however, we do not run it in CI, because it takes too much time to provision 128 PDs that a GCP node can handle. /unassign That sounds useful!
/assign opened to close this for good :)
Code change:
cidrBlocks := make([]string, 0, len(vpcs.Vpcs[0].CidrBlockAssociationSet)) for _, cidr := range vpcs.Vpcs[0].CidrBlockAssociationSet { <ins> if aws.StringValue(cidr.CidrBlockState.State) != ec2.VpcCidrBlockStateCodeAssociated { continue } </ins> cidrBlocks = append(cidrBlocks, aws.StringValue(cidr.CidrBlock)) } return cidrBlocks, 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: If secondard CIDR are disassociated and associated again, AWS LoadBalancer creation fails. It's due to the VPC state is like so CIDRBlock is twice to securityGroup rules, which result in error What you expected to happen: only associated CIDR are considered when calculate VPC CIDR How to reproduce it (as minimally and precisely as possible): and then associated a secondary CIDR AWS CLB Service Anything else we need to know?: Environment: Kubernetes version (use ): <=1.18.0 Cloud provider or hardware configuration: aws OS (e.g: ): linux Kernel (e.g. ): linux Install tools: kops/eks Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
Code change:
func newCmdConfigSetAuthInfo(out io.Writer, options *createAuthInfoOptions) *cobra.Command { cmd := &cobra.Command{ <del> Use:                   fmt.Sprintf("set-credentials NAME [--%v=path/to/certfile] [--%v=path/to/keyfile] [--%v=bearer_token] [--%v=basic_user] [--%v=basic_password] [--%v=provider_name] [--%v=key=value]", clientcmd.FlagCertFile, clientcmd.FlagKeyFile, clientcmd.FlagBearerToken, clientcmd.FlagUsername, clientcmd.FlagPassword, flagAuthProvider, flagAuthProviderArg), </del> <ins> Use: fmt.Sprintf( "set-credentials NAME [--%v=path/to/certfile] "+ "[--%v=path/to/keyfile] "+ "[--%v=bearer_token] "+ "[--%v=basic_user] "+ "[--%v=basic_password] "+ "[--%v=provider_name] "+ "[--%v=key=value] "+ "[--%v=exec_command] "+ "[--%v=exec_api_version] "+ "[--%v=arg] "+ "[--%v=key=value]", clientcmd.FlagCertFile, clientcmd.FlagKeyFile, clientcmd.FlagBearerToken, clientcmd.FlagUsername, clientcmd.FlagPassword, flagAuthProvider, flagAuthProviderArg, flagExecCommand, flagExecAPIVersion, flagExecArg, flagExecEnv, ), </ins> DisableFlagsInUseLine: true, Short:                 i18n.T("Sets a user entry in kubeconfig"), Long:                  createAuthInfoLong,

Related discussion:
text: Now it's possible to configure third-party auth providers using command with option. It's nice to have the same possibility for the recently . Example: To specify the executable path we can run This will generate a new config for the user: Various auxiliary configuration options are also could be . For instance: to define an argument for the executable; to set an environment variable; to specify a desired API version. /kind feature
I'm going to start working on this when the API is promoted to beta.
/sig auth
/assign
Can someone share why you can't do : Is there a way to set map values (e.g. something that is -name: value ; versus something that is -context: )
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
I would like to work on it, if this is still persist.
cc
This still seems useful and is outstanding. any objections to taking it over?
No, it's okay, I'm working on it. I'll post the code this week, sorry for the delay
I think this would help out with generating valid kubectl configurations for our EKS developers. I'm using Pulumi to build EKS environments and if all the flags are available, I think I can generate the necessary entries to assume a role. Thanks! Ex: name: k8s.developer user: exec: apiVersion: args: token -i cluster-eksCluster- -r arn:aws:iam:::role/k8sDevAdminRole- command: aws-iam-authenticator env: null
done :)
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
/priority important-longterm