jiebi/CodeConvo huggingface dataset:
Change:
return err } } <ins> if apierrors.IsNotFound(lastPodError) { // return for compatbility with other functions testing for IsNotFound return lastPodError } </ins> return fmt.Errorf("Gave up after waiting %v for pod %q to be %q", timeout, podName, desc) }

Discussion:
Which jobs are flaking: Which test(s) are flaking: Testgrid link: Reason for failure: Anything else we need to know: Triage links: Spyglass links: Related ginkgo test: /sig cloud-provider-gcp
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : Which jobs are flaking: Anything else we need to know: Triage links: Spyglass links: /sig cloud provider gcp 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
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 cloud-provider
/area provider/gcp cc
cc
do we have an assignee to resolve this?
/assign
GitHub didn't allow me to assign the following users: DangerOnTheRanger. 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 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
The flake seems to be caused by an intermittent race condition related to pod creation and waiting for pod readiness. Right now in the E2E testing framework, there's an if a pod that the caller is trying to wait on doesn't exist. If the pod is created after that branch is executed, the test will prematurely fail. We can see an example of that with (test log edited to show relevant lines): Note the timestamp of pod creation versus when the test failed. Another example from a : And for good measure:
/assign
Change:
fs.StringVar(&s.PasswordFile.BasicAuthFile, "basic-auth-file", s.PasswordFile.BasicAuthFile, ""+ "If set, the file that will be used to admit requests to the secure port of the API server "+ "via http basic authentication.") <ins> fs.MarkDeprecated("basic-auth-file", "Basic authentication mode is deprecated and will be removed in a future release. It is not recommended for production environments.") </ins> } if s.RequestHeader != nil {

Discussion:
This issue was reported in the Description The kube-apiserver includes multiple authentication backends for client request processing. These range in strength from client certificate authentication to simple HTTP Basic Authentication. When using a password (Basic Authentication), the kube-apiserver does not perform a secure comparison of secret values. In theory, this could allow an attacker to perform a timing attack on the comparison. For example, the AuthenticatePassword function simply performs string comparison to authenticate a user’s password (Figure 9.1). Figure 9.1: Username and password authentication handling in Exploit Scenario Alice runs a Kubernetes cluster in production. In order to support multiple organizational “customers,” she configures the cluster with HTTP Basic Authentication. Eve has a large number of username and password pairs for the organization, and uses the side-channel information from string comparison to tune her credential-stuffing attacks. Recommendation Short term, use a safe, constant-time comparison function such as . The comparison function should take the same amount of time regardless of matching prefix data within the password. Long term, deprecate Basic Authentication in favor of more robust and secure options. Add documentation noting that any Basic Authentication is for use only in development scenarios, and not appropriate for production deployments. This will help users create a robust and secure default stance for all deployments. Anything else we need to know?: See for current status of all issues created from these findings. The vendor gave this issue an ID of ATR-K8S-002 and it was finding 18 of the report. The vendor considers this issue Medium Severity. To view the original finding, begin on page 55 of the Environment: Kubernetes version: 1.13.4 Fixed in v1.16.0 by
/sig auth
/area security /kind bug /remove-kind feature
Change:
v1 "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/runtime" "k8s.io/kubernetes/pkg/scheduler/algorithm/predicates" <del> "k8s.io/kubernetes/pkg/scheduler/framework/plugins/migration" </del> framework "k8s.io/kubernetes/pkg/scheduler/framework/v1alpha1" "k8s.io/kubernetes/pkg/scheduler/nodeinfo" )

Discussion:
/sig scheduling /priority important-soon See as an example. Part of /assign
GitHub didn't allow me to assign the following users: angao. 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 : /sig scheduling /priority important-soon 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
thx, I will do it soon.
Change:
}, }, } <del> err := testutils.StartPods(cs, 1, ns, string(uuid.NewUUID()), *initPausePod(f, *podConfig), true, framework.Logf) </del> <ins> wg.Add(1) go func() { defer wg.Done() err := testutils.StartPods(cs, 1, ns, string(uuid.NewUUID()), *initPausePod(f, *podConfig), true, framework.Logf) if err != nil { errChan <- err } }() } wg.Wait() close(errChan) var errs []error for err := range errChan { </ins> if err != nil { <del> return cleanUp, err </del> <ins> errs = append(errs, err) </ins> } } <ins> if len(errs) > 0 { return cleanUp, errors.NewAggregate(errs) } </ins> nodeNameToPodList = podListForEachNode(cs) for _, node := range nodes {

Discussion:
From After , Multi-AZ Clusters tests in 1.19 and 1.20 started timing out as createBalancedPodForNodes is extremely inefficient in scale: for each node (out of 5k), it lists all pods in a cluster serially (each list takes ~5s), which translates to ~7 hours. Optimizing this function by listing pods once and then in memory by Spec.NodeName /kind bug /priority critical-urgent /sig scheduling
/triage accepted
/assign
/reopen Looks that ComputeCPUMemFraction took only 12 minutes, but it stuck later, on It is scheduling one pod per each node: Which is waiting 5s to be ready: 5k nodes * 5s = ~7h
Reopened this issue. <detailsIn response to : /reopen 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 Can you do the pod creations in parallel?
Yes, good idea. I'll update to do that
Change:
}, }, Spec: v1.PodSpec{ <del> RestartPolicy: v1.RestartPolicyNever, </del> <ins> RestartPolicy: restartPolicy, </ins> Containers: []v1.Container{ { Name:  "client",

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:
kube::util::ensure_clean_working_dir _tmpdir="$(kube::realpath "$(mktemp -d -t verify-generated-files.XXXXXX)")" <del> kube::util::trap_add "rm -rf ${_tmpdir}" EXIT </del> _tmp_gopath="${_tmpdir}/go" _tmp_kuberoot="${_tmp_gopath}/src/k8s.io/kubernetes" mkdir -p "${_tmp_kuberoot}/.." <del> cp -a "${KUBE_ROOT}" "${_tmp_kuberoot}/.." </del> <ins> git worktree add "${_tmp_kuberoot}" kube::util::trap_add "git worktree remove -f ${_tmp_kuberoot} && rm -rf ${_tmpdir}" EXIT </ins> cd "${_tmp_kuberoot}" # clean out anything from the temp dir that's not checked in

Discussion:
In the codegenerator we have: So basically we process only packages that are explicitly requested by the user and ignore ones that are imported. So in order to have the conversion func imported by the generator, the package where it lives has to be explicitly imported. So we should basically always pass all input packages to conversion generator. This is problematic, when regenerating conversions, we simply pass to input directories only those that were changed in the meantime: We should fix that - probably by passing all CONVERSIONDIRS as inputs to conversion-gen /kind-bug
I think this caused Not sure if was related yet.
It's the other way around - this is the main bug and root cause and the other that you linked is a consequence.
Also - FYI
I actually already started looking into it - so let me assign this.
is out for review
/triage accepted
Change:
// 2.  configAuthInfo.auth-path (this file can contain information that conflicts with #1, and we want #1 to win the priority) // 3.  if there is not enough information to idenfity the user, load try the ~/.kubernetes_auth file // 4.  if there is not enough information to identify the user, prompt if possible <del> func getUserIdentificationPartialConfig(configAuthInfo clientcmdapi.AuthInfo, fallbackReader io.Reader, persistAuthConfig restclient.AuthProviderConfigPersister) (*restclient.Config, error) { </del> <ins> func (config *DirectClientConfig) getUserIdentificationPartialConfig(configAuthInfo clientcmdapi.AuthInfo, fallbackReader io.Reader, persistAuthConfig restclient.AuthProviderConfigPersister) (*restclient.Config, error) { </ins> mergedConfig := &restclient.Config{} // blindly overwrite existing values based on precedence

Discussion:
When I want to use basic-auth, kubectl will display the password I entered: I think it is more sensible to hide the password?
And it seems that kubectl request for username/password twice...
I'll take this. There is a library here: That appears to do the trick, but we need some refactoring so that it can read from an arbitrary reader to fit our usecase.
This was fixed by but I didn't close this issue. Closing it now.
Change:
#   make #   make all #   make all WHAT=cmd/kubelet GOFLAGS=-v <del> #   make all GOGCFLAGS="-N -l" #     Note: Use the -N -l options to disable compiler optimizations an inlining. #           Using these build options allows you to subsequently use source #           debugging tools like delve. </del> <ins> #   make all GOLDFLAGS="" #     Note: Specify GOLDFLAGS as an empty string for building unstripped binaries, which allows #           you to use code debugging tools like delve. When GOLDFLAGS is unspecified, it defaults #           to "-s -w" which strips debug information. Other flags that can be used for GOLDFLAGS #           are documented at https://golang.org/cmd/link/ </ins> endef .PHONY: all ifeq ($(PRINT_HELP),y)

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: I ran to build latest Kubernetes source code, and then I see the binaries are still stripped: And I can not use dlv to debug the binary: In Makefile, I see the following comments: But that seems not correct in my build. What you expected to happen: I expected Kubernetes binaries with debug info. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Latest Kubernetes source code. Cloud provider or hardware configuration: A virtual machine with 2 cores and 8GB RAM. OS (e.g: ): 18.04 LTS (Bionic Beaver) Kernel (e.g. ): Linux workstation 4.15.0-23-generic -Ubuntu SMP Wed May 23 18:02:16 UTC 2018 x8664 x8664 x86_64 GNU/Linux Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig release
It is the problem of "-ldflags -s -w" and I will provide a PR ASAP. /cc
please set to an empty string and see if that helps
Yes, this is my fix solution (Remove '-s -w' from goldflags). Meanwhile, I had verified that it works.
I tried and it works! So I think the comments in the Makefile need to be updated a bit since only is not enough for debugger to debug Kubernetes binaries.
It should work after you explicitly specify GOLDFLAGS="" in command line. If GOLDFLAGS is not specified, the default value is "-w -s". It turns out all binaries are built as stripped.
yes, please update comments in the Makefile to
in my case for kubernetes1.13.5, removing '-s -w' from goldflags is enough.
Change:
// WaitForPodCondition waits a pods to be matched to the given condition. func WaitForPodCondition(c clientset.Interface, ns, podName, desc string, timeout time.Duration, condition podCondition) error { e2elog.Logf("Waiting up to %v for pod %q in namespace %q to be %q", timeout, podName, ns, desc) <ins> var lastPodError error </ins> for start := time.Now(); time.Since(start) < timeout; time.Sleep(poll) { pod, err := c.CoreV1().Pods(ns).Get(context.TODO(), podName, metav1.GetOptions{}) <ins> lastPodError = err </ins> if err != nil { if apierrors.IsNotFound(err) { e2elog.Logf("Pod %q in namespace %q not found. Error: %v", podName, ns, err) <del> return err </del> <ins> } else { e2elog.Logf("Get pod %q in namespace %q failed, ignoring for %v. Error: %v", podName, ns, poll, err) </ins> } <del> e2elog.Logf("Get pod %q in namespace %q failed, ignoring for %v. Error: %v", podName, ns, poll, err) </del> continue } // log now so that current pod info is reported before calling `condition()`

Discussion:
Which jobs are flaking: Which test(s) are flaking: Testgrid link: Reason for failure: Anything else we need to know: Triage links: Spyglass links: Related ginkgo test: /sig cloud-provider-gcp
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : Which jobs are flaking: Anything else we need to know: Triage links: Spyglass links: /sig cloud provider gcp 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
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 cloud-provider
/area provider/gcp cc
cc
do we have an assignee to resolve this?
/assign
GitHub didn't allow me to assign the following users: DangerOnTheRanger. 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 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
The flake seems to be caused by an intermittent race condition related to pod creation and waiting for pod readiness. Right now in the E2E testing framework, there's an if a pod that the caller is trying to wait on doesn't exist. If the pod is created after that branch is executed, the test will prematurely fail. We can see an example of that with (test log edited to show relevant lines): Note the timestamp of pod creation versus when the test failed. Another example from a : And for good measure:
/assign
Change:
// Search for vendor-specific plugins as well as default plugins in the CNI codebase. vendorDir := vendorCNIDir(vendorCNIDirPrefix, confType) cninet := &libcni.CNIConfig{ <del> Path: []string{binDir, vendorDir}, </del> <ins> Path: []string{vendorDir, binDir}, </ins> } network := &cniNetwork{name: confList.Name, NetworkConfig: confList, CNIConfig: cninet} return network, nil

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help?: Yes What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): cni binaries, cni vendorDirPrefix Is this a BUG REPORT or FEATURE REQUEST? : feature What happened: Inconsistent find-path priority order for cni binaries in CNI: The priority order is vendor dir bin dir The priority order is bin dir vendor dir What you expected to happen: It would be better if this behavior is consistent. Most probably, vendor dir bin dir makes more sense. /cc:
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. Prevent issues from auto-closing with an comment. 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 /remove-lifecycle stale
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Change:
t.Errorf("Deleter() failed: %v", err) } } <ins> func TestGetVolumeLimit(t *testing.T) { tmpDir, err := utiltesting.MkTmpdir("cinderTest") if err != nil { t.Fatalf("can't make a temp dir: %v", err) } cloud, err := getOpenstackCloudProvider() if err != nil { t.Fatalf("can not instantiate openstack cloudprovider : %v", err) } defer os.RemoveAll(tmpDir) plugMgr := volume.VolumePluginMgr{} volumeHost := volumetest.NewFakeVolumeHostWithCloudProvider(tmpDir, nil, nil, cloud) plugMgr.InitPlugins(ProbeVolumePlugins(), nil /* prober */, volumeHost) plug, err := plugMgr.FindPluginByName("kubernetes.io/cinder") if err != nil { t.Fatalf("Can't find the plugin by name") } attachablePlugin, ok := plug.(volume.VolumePluginWithAttachLimits) if !ok { t.Fatalf("plugin %s is not of attachable type", plug.GetPluginName()) } limits, err := attachablePlugin.GetVolumeLimits() if err != nil { t.Errorf("error fetching limits : %v", err) } if len(limits) == 0 { t.Fatalf("expecting limit from openstack got none") } limit, _ := limits[util.CinderVolumeLimitKey] if limit != 10 { t.Fatalf("expected volume limit to be 10 got %d", limit) } } func getOpenstackCloudProvider() (*openstack.OpenStack, error) { cfg := getOpenstackConfig() return openstack.NewFakeOpenStackCloud(cfg) } func getOpenstackConfig() openstack.Config { cfg := openstack.Config{ Global: struct { AuthURL    string `gcfg:"auth-url"` Username   string UserID     string `gcfg:"user-id"` Password   string TenantID   string `gcfg:"tenant-id"` TenantName string `gcfg:"tenant-name"` TrustID    string `gcfg:"trust-id"` DomainID   string `gcfg:"domain-id"` DomainName string `gcfg:"domain-name"` Region     string CAFile     string `gcfg:"ca-file"` }{ Username:   "user", Password:   "pass", TenantID:   "foobar", DomainID:   "2a73b8f597c04551a0fdc8e95544be8a", DomainName: "local", AuthURL:    "http://auth.url", UserID:     "user", }, BlockStorage: openstack.BlockStorageOpts{ NodeVolumeAttachLimit: 10, }, } return cfg } </ins>

Discussion:
We merged to allow configurable volume limits for Cinder. But proposed adding such a limit to as well, among other things this will enable us to support node specific limits more easily - /sig openstack /sig storage /sig scheduling
/assign
cc
/kind feature
This will require updating in-tree Openstack cloudprovider code. are we onboard with that?
What would be the extent of the modification? It must not break current compatibility, and the in-tree provider is scheduled for removal this year. I'm ok with it as long as existing users aren't broken by it.
it should be a change into which would add a new configurable field. It would be backward compatible but would allow admins to configure different limits on a node if they must.
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect