jiebi/CodeConvo huggingface dataset:
Code change:
// Grabber provides functions which grab metrics from components type Grabber struct { <del> client                    clientset.Interface externalClient            clientset.Interface grabFromAPIServer         bool grabFromControllerManager bool grabFromKubelets          bool grabFromScheduler         bool grabFromClusterAutoscaler bool masterName                string registeredMaster          bool </del> <ins> client                            clientset.Interface externalClient                    clientset.Interface grabFromAPIServer                 bool grabFromControllerManager         bool grabFromKubelets                  bool grabFromScheduler                 bool grabFromClusterAutoscaler         bool masterName                        string registeredMaster                  bool waitForControllerManagerReadyOnce sync.Once </ins> } // NewMetricsGrabber returns new metrics which are initialized.

Related discussion:
text: subPath should be able to unmount after the subpath directory is deleted [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: tmpfs] [Testpattern: Pre-provisioned PV (default fs)] subPath should support existing directories when readOnly specified in the volumeSource [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: dir-link-bindmounted] [Testpattern: Pre-provisioned PV (default fs)] subPath should support existing single file [LinuxOnly] [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: block] [Testpattern: Pre-provisioned PV (ext3)] volumes should allow exec of files on the volume [sig-storage] In-tree Volumes [Driver: gcepd] [Testpattern: Dynamic PV (default fs)(allowExpansion)] volume-expand Verify if offline PVC expansion works [sig-storage] In-tree Volumes [Driver: gcepd] [Testpattern: Dynamic PV (ext3)] volumes should store data Testgrid link: Reason for failure: Failure fetching metrics: Anything else we need to know: This appears to have restarted abruptly around 2/11-2/12 /sig storage /priority important-soon
xref I think we have a general failure to start containers reliably. Almost every instance of these test failures contained the pod status error of "OCI runtime start failed: container process is already dead: unknown"
after sweeping a bunch of the in-tree test failures, almost all seemed to have as a root cause, triggered by very short-lived containers used to check file content or permissions. The only test I saw failing that didn't seem to fit that was: [sig-storage] In-tree Volumes [Driver: nfs] [Testpattern: Dynamic PV (default fs)] subPath should support non-existent path [sig-storage] In-tree Volumes [Driver: nfs] [Testpattern: Dynamic PV (default fs)] subPath should support existing directory examples: I'd recommend repurposing this issue to address that specifically and leave the OCI issue for the short-lived container issue
Here's a PR for context: So, I think this PR is another example of flakes. Here are some links to previous runs: and same message: This prow: has the above message and a few more, all A lot of in-tree volume issues, but there were some persistent volume ones too.
Code change:
// Grabber provides functions which grab metrics from components type Grabber struct { <del> client                    clientset.Interface externalClient            clientset.Interface grabFromAPIServer         bool grabFromControllerManager bool grabFromKubelets          bool grabFromScheduler         bool grabFromClusterAutoscaler bool masterName                string registeredMaster          bool </del> <ins> client                            clientset.Interface externalClient                    clientset.Interface grabFromAPIServer                 bool grabFromControllerManager         bool grabFromKubelets                  bool grabFromScheduler                 bool grabFromClusterAutoscaler         bool masterName                        string registeredMaster                  bool waitForControllerManagerReadyOnce sync.Once </ins> } // NewMetricsGrabber returns new metrics which are initialized.

Related discussion:
text: But, that showed up once so far from what I've seen.
The "error getting c-m metrics" failures appear to have just restarted:
/priority critical-urgent bumping priority since we're seeing significant numbers of failures that just started in the last two days
this is failing many test runs per day, do you have updated status on this?
I haven't had chance to fully debug this yet. looked into this little bit and he suspected that these tests started to flake same time around was merged. I should be able to take a closer look tomorrow.
This occurrence fails because it's trying to get the metrics from the kube-controller-manager pod but it is not ready until one minute later if we grep in the kube-apiserver for the controller pod name we can observe that after the pod is up it starts to get 200 instead of 404
keeping open until shows this is resolved
seen again in
this time the container is running but still it can't find it
the errors comes from the request to the apiserver on How can we check that the pod is found and that the apiserver found it?
the first successful get of /metrics logged by the controller manager in that run is at: We're also not checking the error in the once.Do to make sure the pod was running, and once running, we should probably then also check the metrics path on the pod. Maybe something like this:
still happening: message logging missed using the correct errors, so the messages aren't helpful:
what's this stack trace in the apiserver? is this related? a 503 shouldn't cause that, right?
again it seems is not really waiting because it fails just 200 ms after the INFO msg, I think is because it checks if the pod is running, but the message is that the pod doesn't really exist. The fact that there are 9 tests failing with the same error and we are using has to be related to the way Ginkgo use parallel.
It turns out that the method used to wait for the controller manager pod fails if the pod doesn't exist
Ah, so first we should wait for the pod to exist, then be ready, then return metrics
This start to look promising
yes, looks good. thanks for all the work /close
Closing this issue. <detailsIn response to : yes, looks good.
Code change:
// Grabber provides functions which grab metrics from components type Grabber struct { <del> client                    clientset.Interface externalClient            clientset.Interface grabFromAPIServer         bool grabFromControllerManager bool grabFromKubelets          bool grabFromScheduler         bool grabFromClusterAutoscaler bool masterName                string registeredMaster          bool </del> <ins> client                            clientset.Interface externalClient                    clientset.Interface grabFromAPIServer                 bool grabFromControllerManager         bool grabFromKubelets                  bool grabFromScheduler                 bool grabFromClusterAutoscaler         bool masterName                        string registeredMaster                  bool waitForControllerManagerReadyOnce sync.Once </ins> } // NewMetricsGrabber returns new metrics which are initialized.

Related discussion:
text: thanks for all the work 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
Fixed by
Code change:
return nil } <del> func getAppArmorFS() (string, error) { mountsFile, err := os.Open("/proc/mounts") if err != nil { return "", fmt.Errorf("could not open /proc/mounts: %v", err) } defer mountsFile.Close() scanner := bufio.NewScanner(mountsFile) for scanner.Scan() { fields := strings.Fields(scanner.Text()) if len(fields) < 3 { // Unknown line format; skip it. continue } if fields[2] == "securityfs" { appArmorFS := path.Join(fields[1], "apparmor") if ok, err := utilpath.Exists(utilpath.CheckFollowSymlink, appArmorFS); !ok { msg := fmt.Sprintf("path %s does not exist", appArmorFS) if err != nil { return "", fmt.Errorf("%s: %v", msg, err) } return "", errors.New(msg) } return appArmorFS, nil } } if err := scanner.Err(); err != nil { return "", fmt.Errorf("error scanning mounts: %v", err) } return "", errors.New("securityfs not found") } </del>

Related discussion:
text: As mentioned the return value of is not being used any longer and the entire method can be removed. The usage of was removed in Now there is no need to have the function and store it's result at all. /sig node /kind cleanup /good-first-issue /help-wanted KEP xref:
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 : As mentioned the return value of is not being used any longer and the entire method can be removed. /kind cleanup /good-first-issue /help-wanted 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
/triage accepted
/assign
I am having issues submitting the pull request. I removed that portion of the code under however this is my first time contributing and would like some help submitting this new updated version..
/assign
/assign
/assign
/assign
Code change:
For Kubernetes 1.0, we strongly recommend running the following set of admission control plug-ins (order matters): ``` <del> --admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota </del> <ins> --admission-control=NamespaceLifecycle,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota </ins> ```

Related discussion:
text: We should have a single NamespaceLifecycle plugin that enforces the Namespace rules now that all providers are off NamespaceAutoProvision. We may also want to make this no longer a user choice to configure and hard-wire the server to always run this check first to simplify configuration errors. For an example
Code change:
// AUTO-GENERATED FUNCTIONS START HERE. DO NOT EDIT. var map_Endpoint = map[string]string{ "":           "Endpoint represents a single logical "backend" implementing a service.", <del> "addresses":  "addresses of this endpoint. The contents of this field are interpreted according to the corresponding EndpointSlice addressType field. Consumers must handle different types of addresses in the context of their own capabilities. This must contain at least one address but no more than 100.", </del> <ins> "addresses":  "addresses of this endpoint. The contents of this field are interpreted according to the corresponding EndpointSlice addressType field. Consumers must handle different types of addresses in the context of their own capabilities. This must contain at least one address but no more than 100. These are all assumed to be fungible and clients may choose to only use the first element. Refer to: https://issue.k8s.io/106267", </ins> "conditions": "conditions contains information about the current status of the endpoint.", "hostname":   "hostname of this endpoint. This field may be used by consumers of endpoints to distinguish endpoints from each other (e.g. in DNS names). Multiple endpoints which use the same hostname should be considered fungible (e.g. multiple A values in DNS). Must be lowercase and pass DNS Label (RFC 1123) validation.", "targetRef":  "targetRef is a reference to a Kubernetes object that represents this endpoint.",

Related discussion:
text: Taking only into consideration the first endpoint which is in the same zone of the node or has no zone dependency and is ready for serving. & Would it make sense to reopen this issue?
I don't follow entirely what you are suggesting, can you elaborate?
kube-proxy should understand which zone a node is in and prefer endpoints in the same zone.
but that is unrelated to this issue, topology is considered See KEPs related, topology-aware-routing was replaced by topology-aware-hints
thank you for clarifying. It seems ambiguous to me to have a zone attribute and a hint attribute. I fail to implement the hinting on a service in v1.23.8, but this is urelated to this issue.
heh, don't worry, this topic is complex and we went through different solutions, you have more historical context on the KEPs I linked above and this thread in the mailing list
Code change:
rt.CapabilityArgs["bandwidth"] = bandwidthParam } <ins> // Set the PodCIDR rt.CapabilityArgs["ipRanges"] = [][]cniIpRange{{{Subnet: plugin.podCidr}}} </ins> return rt, nil }

Related discussion:
text: /kind feature The CNI "capability arguments" parameter - currently used to pass port mappings - has a few new capabilities: bandwidth limiting and network address management. The dockershim's networking driver should use them. The network address is just passing the PodCIDR dynamically to the plugin, so it no longer has to retrieve it from the APIServer. Bandwidth limiting is already implemented in Kubenet. It is configured via annotations. There is no upgrade risk in providing these values; non-compliant plugins will simply ignore them. Administrators need to explicitly enable each capability individually in their CNI configuration file. To avoid skew between runtimes, the other runtimes should also be upgraded to pass these. We may also wish to look in to a way to add this more directly to the CRI, so we don't have this skew problem, but that's a different issue.
/sig network
/assign
fyi.
Looks like this was never done for CRI?
cc
Code change:
source "${KUBE_ROOT}/hack/lib/init.sh" if [[ ! -f "${KUBE_ROOT}/vendor/BUILD" ]]; then <del> echo "${KUBE_ROOT}/vendor/BUILD does not exist." echo echo "Run ./hack/update-bazel.sh" </del> <ins> echo "${KUBE_ROOT}/vendor/BUILD does not exist." >&2 echo >&2 echo "Run ./hack/update-bazel.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:
# Clean up kubectl delete namespace my-namespace <del> ############## </del> <ins> ###################### </ins> # Pods in Namespaces # <del> ############## </del> <ins> ###################### </ins> ### Create a new namespace # Pre-condition: the other namespace does not exist

Related discussion:
text: The desciption of --all-namespaces is listing the requested object(s) across all namespaces. Namespace in current context is ignored even if specified with --namespace." But when I used the following command: error: namespace may not be empty when retrieving a resource by name no namespace set on resource pods "counter" The error messages are unclear, and the second message isn't labeled as an error even.
And why couldn't use --all-namespaces flag?
You're asking for a specific pod name (counter) in all namespaces, which is a nonsensical query. The pod name is not a grep-like filter, it's a specific name. Yeah, the errors could be better. Describe could work, but potentially generates a LOT of information and API calls.
But I found the following API is supported now. Get The result is: has the more information. Do we need to support the following kubectl command(using the above API) or just return clear error messages? get pods counter --all-namespaces
I'd be ok with this being implemented via the field selector.
The issue is still here :). What's our expected result? I'd like to contribute this.
, after check the code, the URL was built by ; do you mean we should update it; or avoid to use , instead, build url () directly.
After checking the code, it's better to add fieldSelector to , is created for fieldSelector. Will submit a PR based on .
getting an object with a particular name across all namespaces seems like something we shouldn't encourage... it breaks the assumption of namespace independence.
, so we'll only update message for this issue? for example:
Disagree. Need easy way to troubleshouting the problem "why pods is stuck in Pending status". It's tiring for every pod to find who created it and in which namespace. In the logs there is only the name of the pod.
Now, with field selectors we can do To further my understanding, I'd ask:- doesn't itself break independence? One can search by label across all namespaces, it feels funny for by name to be special.
Code change:
checkNode := func(i int) { // We check the nodes starting from where we left off in the previous scheduling cycle, // this is to make sure all nodes have the same chance of being examined across pods. <del> nodeInfo := g.nodeInfoSnapshot.NodeInfoList[(g.lastProcessedNodeIndex+i)%allNodes] </del> <ins> nodeInfo := g.nodeInfoSnapshot.NodeInfoList[(g.nextStartNodeIndex+i)%allNodes] </ins> fits, failedPredicates, status, err := g.podFitsOnNode( ctx, state,

Related discussion:
text: What would you like to be : A unit test that verifies the evaluation order of the nodes in the scheduler. Why is this needed: The scheduler evaluates the nodes in a specific order until it finds a pre-defined minimum number of feasible nodes. To give all nodes a fair chance of being evaluated, in each scheduling cycle, the scheduler starts evaluating from where it left off in the previous cycle. This is captured by the parameter in  We need to add a unit test that captures regressions related to this behavior to avoid bugs like /sig scheduling /priority important-soon /help
/assign
/remove-help
Code change:
if *confDoc { // Note: this assumes that you're running from the root of the kube src repo <del> header, err := ioutil.ReadFile("test/conformance/cf_header.md") if err == nil { fmt.Printf("%snn", header) </del> <ins> templ, err := template.ParseFiles("test/conformance/cf_header.md") if err != nil { fmt.Printf("Error reading the Header file information: %snn", err) } data := struct { Version string }{ Version: *version, </ins> } <ins> templ.Execute(os.Stdout, data) </ins> } totalConfTests = 0

Related discussion:
text: What happened: The Conformance Document currently has a static header that is displayed from a file. The release information in the header should reflect proper release number so that the document reflect the current state. What you expected to happen: Should show proper current release information How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
in reaction to comments is still hardcoded to mention v1.9 at the top, could we parameterize this?
/sig testing /area conformance /release-note-none
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
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
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close 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
/reopen
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
/remove-lifecycle rotten
/priority backlog
This seems to have been addressed at Should we just close this?
No, specifically did not address this issue, this should stay open. See
Code change:
func newAzureAuthProvider(_ string, cfg map[string]string, persister restclient.AuthProviderConfigPersister) (restclient.AuthProvider, error) { // deprecated in v1.22, remove in v1.25 <del> // this should be updated to use klog.Warningf in v1.24 to more actively warn consumers </del> warnOnce.Do(func() { <del> klog.V(1).Infof(`WARNING: the azure auth plugin is deprecated in v1.22+, unavailable in v1.25+; use https://github.com/Azure/kubelogin instead. </del> <ins> klog.Warningf(`WARNING: the azure auth plugin is deprecated in v1.22+, unavailable in v1.25+; use https://github.com/Azure/kubelogin instead. </ins> To learn more, consult https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins`) })

Related discussion:
text: Replace the azure auth plugin deprecation with a in v1.24 xref: /assign /milestone v1.24 /triage accepted /sig auth
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten /lifecycle frozen
/assign
/priority important-soon /kind cleanup deprecation
Code change:
"os" "testing" <del> "github.com/Azure/azure-sdk-for-go/services/compute/mgmt/2019-03-01/compute" "github.com/Azure/go-autorest/autorest/to" </del> "github.com/stretchr/testify/assert" "k8s.io/api/core/v1"

Related discussion:
text: <!-- Please only use this template for submitting enhancement requests -- What would you like to be : related to Why is this needed: /assign /sig azure
here is the way about how to get MaxDataDiskCount: and then build kubelet, copy kubelet to agent node and then get MaxDataDiskCount data: There are 207 VM sizes totally.
Update: this command could get VM size list easily: