jiebi/CodeConvo huggingface dataset:
Code change:
return pod, podStats } <ins> func makePIDStats(nodeAvailablePIDs string, numberOfRunningProcesses string, podStats map[*v1.Pod]statsapi.PodStats) *statsapi.Summary { val := resource.MustParse(nodeAvailablePIDs) availablePIDs := int64(val.Value()) parsed := resource.MustParse(numberOfRunningProcesses) NumberOfRunningProcesses := int64(parsed.Value()) result := &statsapi.Summary{ Node: statsapi.NodeStats{ Rlimit: &statsapi.RlimitStats{ MaxPID:                &availablePIDs, NumOfRunningProcesses: &NumberOfRunningProcesses, }, }, Pods: []statsapi.PodStats{}, } for _, podStat := range podStats { result.Pods = append(result.Pods, podStat) } return result } </ins> func makeMemoryStats(nodeAvailableBytes string, podStats map[*v1.Pod]statsapi.PodStats) *statsapi.Summary { val := resource.MustParse(nodeAvailableBytes) availableBytes := uint64(val.Value())

Related discussion:
text: Hard eviction means we trigger eviction with no grace period while soft eviction means that we obey a grace period. Test should check for that.
I have opened a PR based on what I could understand using a debugger and the other tests. This is my first time contributing to the codebase. Happy to take brutal feedback.
Hi, i would like to support this issue. Let me know if any help is required.
/assign
Code change:
# Contributing <del> Welcome to Kubernetes! If you are interested in contributing to the [Kubernetes code repo](README.md) then checkout the [Contributor's Guide](https://git.k8s.io/community/contributors/guide/) </del> <ins> Welcome to Kubernetes! To learn more about contributing to the [Kubernetes code repo](README.md), check out the [Contributor's Guide](https://git.k8s.io/community/contributors/guide/). </ins> <del> The [Kubernetes community repo](https://github.com/kubernetes/community) contains information on how the community is organized and other information that is pertinent to contributing. </del> <ins> The [Kubernetes community repo](https://github.com/kubernetes/community) contains information about how to get started, how the community organizes, and more. ## Sign the CLA You must sign the [Contributor License Agreement](https://git.k8s.io/community/contributors/guide/getting-started.md#sign-the-cla) in order to contribute. </ins> [![Analytics](https://kubernetes-site.appspot.com/UA-36037335-10/GitHub/CONTRIBUTING.md?pixel)]()

Related discussion:
text: Explicitly state in this repo's . The CNCF received a user complaint that the CLA requirement is non-obvious until a contributor opens a PR (i.e., after the work is already done). Given that the CLA requirement is a minimum of two links away from , the complaint seems reasonable. It also seems reasonable to explicitly state that contributors must sign a license agreement.
/sig docs
Code change:
healthzServer healthcheck.ProxierHealthUpdater, nodePortAddresses []string, ) (*Proxier, error) { <del> // Set the route_localnet sysctl we need for if err := utilproxy.EnsureSysctl(sysctl, sysctlRouteLocalnet, 1); err != nil { return nil, err </del> <ins> if utilproxy.ContainsIPv4Loopback(nodePortAddresses) { // Set the route_localnet sysctl we need for exposing NodePorts on loopback addresses klog.InfoS("Setting route_localnet=1, use nodePortAddresses to filter loopback addresses for NodePorts to skip it https://issues.k8s.io/90259") if err := utilproxy.EnsureSysctl(sysctl, sysctlRouteLocalnet, 1); err != nil { return nil, err } </ins> } // Proxy needs br_netfilter and bridge-nf-call-iptables=1 when containers

Related discussion:
text: Just similar to , for service with type nodeport , iptable proxy should add IsLoopback check for nodeAddress. Line 1104-1106 check nodeAddress is localhost address or not for ipvs mode proxy but for iptable mode proxy , when deal with nodePort type service, there is no similar check for nodeAddress since the use of localhost addresses for nodeports is the only know reason to require (), Just for the purpose of security ,this requirement shall be removed for proxy-mode=itable. Start a cluster with proxy-mode=iptable and some services Do; iptable -Ln | grep 127.0.0.1 just as says : ipv6+iptables , ::1 is not work for Nodeport all supporting proxy-mode=iptable any any /sig network /kind cleanup /area iptable
/sig network
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /area iptable 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
/kind cleanup
maybe I'm missing something, but this was discussed in this issue and iptables needs to use localhost for nodeports, if we remove that we can break users. ipvs is different and it never needed loopback for nodeports
set sysctlRouteLocalnet when running in IPtable mode may still face a risk from CVE-2020-8558, so why not disable it in the future version?
because there are users that depend on that behavior, I can't remember the details , the referenced issue has them
I support finding a way to get to the end-state of not supporting nodeports on localhost, but I don't know the path.
/assign
it seems that localhost;nodeport is also used in blogs and forums the only tool we have for these situations is to add a feature gate and rollout the change in several releases, users can always set the sysctl value by themselves to recover previous behavior. should I create a small KEP to deprecate the behavior of setting the TTL? since is inconsistent with the other kube-proxy modes, there is a security risk and the workaround is quite simple, it seems a reasonable decision
I don't think we have a clear path to changing a defsult behavior, even one that is ill-advised.
Code change:
healthzServer healthcheck.ProxierHealthUpdater, nodePortAddresses []string, ) (*Proxier, error) { <del> // Set the route_localnet sysctl we need for if err := utilproxy.EnsureSysctl(sysctl, sysctlRouteLocalnet, 1); err != nil { return nil, err </del> <ins> if utilproxy.ContainsIPv4Loopback(nodePortAddresses) { // Set the route_localnet sysctl we need for exposing NodePorts on loopback addresses klog.InfoS("Setting route_localnet=1, use nodePortAddresses to filter loopback addresses for NodePorts to skip it https://issues.k8s.io/90259") if err := utilproxy.EnsureSysctl(sysctl, sysctlRouteLocalnet, 1); err != nil { return nil, err } </ins> } // Proxy needs br_netfilter and bridge-nf-call-iptables=1 when containers

Related discussion:
text: As much as I'd like it to be the default, I think the only way to get there is to add a flag with compatible default behavior and encourage people to turn it on. e.g. add a kube-proxy config like defaulting to true, and encourage people/tools to set it to false.
I've found a better way ;)
/triage accepted
Code change:
gcloud compute firewall-rules create "${INSTANCE_PREFIX}-monitoring-heapster" --project "${PROJECT}"  --allow tcp:80 tcp:8083 tcp:8086 --target-tags="${MINION_TAG}" --network="${NETWORK}" <del> local kubectl="${KUBE_ROOT}/cluster/kubectl.sh" local grafana_host="" echo "waiting for monitoring pods to be scheduled." for i in `seq 1 10`; do grafana_host=$("${kubectl}" get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}} | sed s/://g) if [[ ${grafana_host} != *"<"* ]]; then break fi sleep 10 done if [[ ${grafana_host} != *"<"* ]]; then echo echo -e "${color_green}Grafana dashboard will be available at ${color_yellow}http://${grafana_host}${color_green}. Wait for the monitoring dashboard to be online.${color_norm}" echo else echo -e "${color_red}Monitoring pods failed to be scheduled!${color_norm}" fi </del> <ins> echo echo -e "${color_green}Grafana dashboard will be available at ${color_yellow}https://${KUBE_MASTER_IP}/api/v1beta1/proxy/services/monitoring-grafana/${color_green}. Wait for the monitoring dashboard to be online.${color_norm}" echo </ins> } function teardown-monitoring-firewall {

Related discussion:
text: After starting kubernetes cluster on GCE with ./kube-, I cannot connect to grafana dashboard.
It might be related to
How are you trying to access the dashboard - via the proxy or using the nodeIP ?
I'm trying to access grafana via host ip of the node. This is the address written by kube- ``Grafana dashboard will be available at http://XXX.'' Is there a proxy for grafana? AFAIK, we have services with forwarding rules only for elasticsearch and kibana.
We also tried to connect using api proxy (http://localhost:8001/api/v1beta1/proxy/services/monitoring-grafana) and we see sth weird like "{{}}".
That looks like angular crashed part way through. What does the javascript console in your browser show? Brendan On Feb 24, 2015 5:18 AM, "Piotr Szczesniak" wrote:
monitoring-grafana:8 GET http://localhost:8001/api/v1beta1/proxy/ns/default/services/monitoring- monitoring-grafana:11 GET http://localhost:8001/api/v1beta1/proxy/ns/default/services/monitoring- monitoring-grafana:13 Uncaught ReferenceError: require is not definedmonitoring-grafana:13 (anonymous function) monitoring-grafana:19 GET http://localhost:8001/api/v1beta1/proxy/ns/default/services/monitoring-
is it still possible to connect to grafa using nodeIP?
Yes. It should still be possible. The firewall rules are setup on GCE by default to access Grafana. I assume you are running on GCE. , Piotr Szczesniak wrote:
Can you check if firewall rules are setup to access Grafana? , Vishnu Kannan wrote:
I set up cluster using hack/dev-build-and- In Google Developer Console under Compute-Network Load Balancing-Forwarding Rules I can see only the following entries: elasticsearch-logging us-central1 104.154.82.11 TCP/9200 elasticsearch-logging kibana-logging us-central1 104.154.82.224 TCP/5601 kibana-logging
Can you look at "Firewall rules"? , Piotr Szczesniak
OK.
Code change:
gcloud compute firewall-rules create "${INSTANCE_PREFIX}-monitoring-heapster" --project "${PROJECT}"  --allow tcp:80 tcp:8083 tcp:8086 --target-tags="${MINION_TAG}" --network="${NETWORK}" <del> local kubectl="${KUBE_ROOT}/cluster/kubectl.sh" local grafana_host="" echo "waiting for monitoring pods to be scheduled." for i in `seq 1 10`; do grafana_host=$("${kubectl}" get pods -l name=influxGrafana -o template -t {{range.items}}{{.currentState.hostIP}}:{{end}} | sed s/://g) if [[ ${grafana_host} != *"<"* ]]; then break fi sleep 10 done if [[ ${grafana_host} != *"<"* ]]; then echo echo -e "${color_green}Grafana dashboard will be available at ${color_yellow}http://${grafana_host}${color_green}. Wait for the monitoring dashboard to be online.${color_norm}" echo else echo -e "${color_red}Monitoring pods failed to be scheduled!${color_norm}" fi </del> <ins> echo echo -e "${color_green}Grafana dashboard will be available at ${color_yellow}https://${KUBE_MASTER_IP}/api/v1beta1/proxy/services/monitoring-grafana/${color_green}. Wait for the monitoring dashboard to be online.${color_norm}" echo </ins> } function teardown-monitoring-firewall {

Related discussion:
text: Seems that grafana is working fine, it is available at: https://<masterIP/api/v1beta1/proxy/services/monitoring-grafana/ Message printed by kube- is bit incorrect, I'll fix it.
Thanks for the fix Closing this issue!
Code change:
if e, a := expected, buf.String(); e != a { t.Errorf("expectedn%vngotn%v", e, a) } <del> expectedErr := `No resources found. </del> <ins> expectedErr := `No resources found in test namespace. </ins> ` if e, a := expectedErr, errbuf.String(); e != a { t.Errorf("expectedErrn%vngotn%v", e, a)

Related discussion:
text: So I started using namespaces for the first time, and I ran: nothing was showing up...I was really confused, debugging stuff for 30+ minutes.. finally I was like, even tho this is really dumb, maybe they are behind a namespace, so I did: and finally my pods showed up. so yes there is: but this should really be the default, shouldn't it? You will save people a lot of time if you make this fix. tbh, this is a really crappy cli design in this case.
While this might sound like a good idea if you're running a single deployment with a few pods, once you start running multiple dozens of deployments and objects it starts to become less and less useful to have this become the default. I also suspect exposing all objects without specifying namespace is probably a non-goal. Namespaces were created for a reason which is to logically segment resources together. In my opinion, what you are suggesting just nullifies the entire purpose of namespaces.
I think this is more of a usability bug. kubectl get pods gives the list of all pods in default namespace.By default no pods are present in default namespace. So it does give a message saying No Resources found. Improving this message a little bit will be helpful like No Resources found in default namespace
/sig cli
I could implement this if that's alright with you !
sure, how about
We should wait for kubernetes members to comment if this change should be taken up
The title of this issue could use an update, if the priority has been shifted to improving the output of an empty namespace. Maybe it's early to claim the consensus seems to be that --all-namespaces should not be the default, but I personally agree that it shouldn't be. Take note of the shorthand , to make typing it a bit easier, or the option to to something other than to get around typing your namespace altogether.
:) IMHO, is innocent. But we could make the messages more clear. For example, will show also. And is a bit long, but a is too simple to describe our intent, "all namespaces of cluster or all some resource of some namespace", so puzzled. My conclusion: is competent, namespace is ok, making more clear message is enough.
"~" is already implemented as in , in .
Code change:
if e, a := expected, buf.String(); e != a { t.Errorf("expectedn%vngotn%v", e, a) } <del> expectedErr := `No resources found. </del> <ins> expectedErr := `No resources found in test namespace. </ins> ` if e, a := expectedErr, errbuf.String(); e != a { t.Errorf("expectedErrn%vngotn%v", e, a)

Related discussion:
text: Not sure if I came across as suggesting a new shorthand or if I misread your comment, but for clarity's sake there it is.
the problem is that the nixos-rebuild command is not available on non-NixOS linux machines. However, the underlying issue is that if we run we get this error:
Code change:
6. Get the Kubernetes source: ```sh <del> go get github.com/GoogleCloudPlatform/kubernetes cd $GOPATH/src/github.com/GoogleCloudPlatform/kubernetes </del> <ins> mkdir -p $GOPATH/src/github.com/GoogleCloudPlatform git clone https://github.com/GoogleCloudPlatform/kubernetes.git cd kubernetes </ins> ``` ### Setup

Related discussion:
text: I was running through the vSphere instructions a couple weeks ago and got hung up on the clusterresource issue documented here: Seeing that is was fixed and how i didn't make much progress - I decdied to start over from scratch on a new vm. Now it appears that something is broken on git as seems i cant pull the source anymore -- or maybe the instructions are broken. ( Tried this on two seperate ubuntu 14.04 vms to make sure it wasn't something on first machine) Can't seem to get past this.... go get can't load package: package no buildable Go source files in Maybe i am missing something?
Our root repo isn't actually a go package as there are no buildable files there. Instead I'd follow the instructions here: Where did you see those instructions? I'd love to fix it up.
Thanks for the heads up! I will give those instructions a try. Here is what I was using:
Has that changed recently? I recall copying the initial set of instructions from the GCE guide.
You might have caught a snapshot when the instructions were broken. There was a lot in flight there. I'll send a PR to fix up the instructions.
Thanks .
Code change:
return fmt.Errorf("detach azure disk failure, disk %s not found, diskURI: %s", diskName, diskURI) } <del> vm.StorageProfile.DataDisks = &disks </del> <ins> newVM := compute.VirtualMachineScaleSetVM{ Sku:      vm.Sku, Location: vm.Location, VirtualMachineScaleSetVMProperties: &compute.VirtualMachineScaleSetVMProperties{ HardwareProfile: vm.HardwareProfile, StorageProfile: &compute.StorageProfile{ OsDisk:    vm.StorageProfile.OsDisk, DataDisks: &disks, }, }, } </ins> ctx, cancel := getContextWithCancel() defer cancel()

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!--What happened: When attach/detach azure disk in vmss, it updates whole VM info, including: networkProfile, storageProfile, while this would lead to race condition when there is also network related setting changing in k8s cloud provider in the mean time. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug /sig azure /assign
Code change:
// lastStatusReportTime is the time when node status was last reported. lastStatusReportTime time.Time <ins> // lastContainerStartedTime is the time of the last ContainerStarted event observed per pod lastContainerStartedTime *timeCache </ins> // syncNodeStatusMux is a lock on updating the node status, because this path is not thread-safe. // This lock is used by Kubelet.syncNodeStatus function and shouldn't be used anywhere else. syncNodeStatusMux sync.Mutex

Related discussion:
text: These tests have flaked consistently since merged: in many cases, they are the only failure in a test run: Either the functionality introduced by that PR is not reliable, or the test is faulty. /sig node /priority critical-urgent /assign
/milestone v1.19
/assign
Looks like this is failing ~5% of pull-kubernetes-node-e2e runs
FYI
Looks like there might still be a race somewhere looking at the kubelet logs Success case: Fail case:
Looking at it more, it seems like is unexpectedly empty here Success: Fail:
Stacks of interest I think we might be dealing with a stale If there is a call before the container is to the Pod in the runtime and the is called within the 2 second default cache period, it seems possible that the in the could have no containers.
what do you think of this analysis? If so, any obvious solutions occur to you?
If I'm correct, didn't introduce this; just the e2e test exposed an existing bug in the kubelet.
That all looks correct. I'm taking a look at the proposed solutions
Code change:
go_version=($(go version)) if [[ "${go_version[2]}" < "go1.4" ]]; then kube::log::usage_from_stdin <<EOF Detected go version: ${go_version[*]}. Kubernetes requires go version 1.4 or greater. Please install Go version 1.4 or later. EOF exit 2 fi

Related discussion:
text: Example: I have a fixing PR ready, will send it in a moment.
/sig docs /assign closing because linked pr fixed this
/close
Code change:
and FOOSERVICE_PORT_8765_TCP_ADDR that are populated with proper values. release: v1.9 file: test/e2e/common/pods.go <ins> - testname: Pods, delete a collection codename: '[k8s.io] Pods should delete a collection of pods [Conformance]' description: A set of pods is created with a label selector which MUST be found when listed. The set of pods is deleted and MUST NOT show up when listed by its label selector. release: v1.19 file: test/e2e/common/pods.go </ins> - testname: Pods, assigned hostip codename: '[k8s.io] Pods should get a host IP [NodeConformance] [Conformance]' description: Create a Pod. Pod status MUST return successfully and contains a valid

Related discussion:
text: [x] Original approval issue: 09 July 2020 [x] Two weeks soak end date: 24 July 2020 This issue is created to allow edit by /wip /hold According to this APIsnoop query, there are still an endpoint which is untested. a set of 3 Pods with a static label within a Namespace. that all 3 Pods with the label in the Namespace are created. the set of Namespaced Pods with a label via DeleteCollection. that all Pods with the label have been deleted. Discover useragents: List endpoints hit by the test: Display endpoint coverage change: Two other endpoints tested here have tests in progress to conformance already. If a test with these calls gets merged, test coverage will go up by 1 points This test is also created with the goal of conformance promotion.
/sig testing /sig architecture /area conformance
During Conformance Meeting: Is there a way to write this test so it is resource agnostic? If we are just changing the resource... can be parameterize the resource-type
/assign
GitHub didn't allow me to assign the following users: heyste. 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
Test to be created using "Polling" and not "Watch tooling"
/reopen Merged Issue open, waiting for Promotion PR
Reopened this issue. <detailsIn response to : /reopen Merged Issue open, waiting for Promotion PR Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig node
The test appears to be flaking, need to reach out to #sig-node for some feedback.
Can you point us to the link of the flaky tests? Thanks!
The Promotion The testgrid Thank you!
Code change:
"k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <del> "k8s.io/apimachinery/pkg/fields" </del> "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/util/wait" "k8s.io/apimachinery/pkg/watch"

Related discussion:
text: <!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --ci-kubernetes-e2e-gci-gce-serial (gce-cos-master-serial) Kubernetes e2e suite.[sig-scheduling] SchedulerPriorities [Serial] Pod should avoid nodes that have avoidPod annotation June 19th 2021 () Testgrid: https://k8s- Prow history: Looks like pods are scheduled where they shouldn't be? : The tests passes in maybe 20% of the builds, but it looks random, so I don't treat it as a flake. At the moment there are also sig-storage tests consistently failing in this job: , They don't look related though. /sig scheduling /kind failing-test
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
/milestone v1.22
try to have a look.
try to have a look.
/cc
This is expected. The feature (which was alpha) is now disabled by default. Users can still enable it by switching to a v1beta1 scheduler component config. Let's remove the test.