jiebi/CodeConvo huggingface dataset:
Code change:
// Allow traffic bound for external IPs that happen to be recognized as local IPs to stay local. // This covers cases like GCE load-balancers which get added to the local routing table. writeLine(natRules, append(dstLocalOnlyArgs, "-j", string(svcChain))...) <ins> // If the service has no endpoints then reject packets coming via externalIP // Install ICMP Reject rule in filter table for destination=externalIP and dport=svcport if len(proxier.endpointsMap[svcName]) == 0 { writeLine(filterRules, "-A", string(kubeServicesChain), "-m", "comment", "--comment", fmt.Sprintf(`"%s has no endpoints"`, svcNameString), "-m", protocol, "-p", protocol, "-d", fmt.Sprintf("%s/32", externalIP), "--dport", fmt.Sprintf("%d", svcInfo.port), "-j", "REJECT", ) } </ins> } // Capture load-balancer ingress.

Related discussion:
text: Is this a request for help? No What keywords did you search in Kubernetes issues before filing this one? externalIPs kube-proxy connection accepted no pods running. icmp reject rules. Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): kubectl version Environment: Cloud provider or hardware configuration: Bare Metal. OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: Others: What happened: is exposed using externalIP construct. pods are backing the service (using scale deployment 0). The pod is expected to run a TCP based server (non-http) client connects to this service using externalIP as dest-ip; connection gets accepted by kube-proxy. What you expected to happen: When no pods are backing service; the connection should have been rejected and definitely not accepted by kube-proxy. How to reproduce it (as minimally and precisely as possible): a service and expose it using externalIP construct pods are present; bring them down using"kubectl scale deployment my_svc --replicas 0 --namespace xyz initiates the connection to this service using externalIP and connection goes fine but to kube-proxy. Anything else we need to know: Info on iptable rules - When service and pods are present the rules like these - pods are not present; iptables rules look like this - that the reject rule exist only for the destination=ServiceIP=10.100.200.6/32 no pods are present; client gets connected to kube-proxy On VM - Based on and ; I manually installed reject rule on INPUT chain. I do not see the issue happening again - meaning client then cannot connect to the server when no pods are present.
I have a suggestion for installing icmp reject rules. Why cant icmp reject rule always present in INPUT chain? kube-proxy do not really need to check if pods are present or not for installing these rules. For the svcip/externaip to pod-ip translation; kube-proxy anyways install the rule to do DNAT in which case the icmp reject rule from INPUT wont be hit. In case when DNAT fails to happen - e.g. in cases like pods not present - icmp reject rule will anyways kick in to reject such packet.
Code change:
// Allow traffic bound for external IPs that happen to be recognized as local IPs to stay local. // This covers cases like GCE load-balancers which get added to the local routing table. writeLine(natRules, append(dstLocalOnlyArgs, "-j", string(svcChain))...) <ins> // If the service has no endpoints then reject packets coming via externalIP // Install ICMP Reject rule in filter table for destination=externalIP and dport=svcport if len(proxier.endpointsMap[svcName]) == 0 { writeLine(filterRules, "-A", string(kubeServicesChain), "-m", "comment", "--comment", fmt.Sprintf(`"%s has no endpoints"`, svcNameString), "-m", protocol, "-p", protocol, "-d", fmt.Sprintf("%s/32", externalIP), "--dport", fmt.Sprintf("%d", svcInfo.port), "-j", "REJECT", ) } </ins> } // Capture load-balancer ingress.

Related discussion:
text: This would be better than accidentally giving the packet to kube-proxy which is always listening on the port and accepting this accidental connection even when it does not intend to. Actually, for now that's how I am putting workaround for this problem in our setup.
That might be a clever answer - I hadn't thought of it that way. Would need good tests and comments.
I can give a shot at testing it. I didnt find a good reference document / todo for testing such changes. If you can help me locate it; I can give it a try.
Code change:
"//pkg/util/async:go_default_library", "//staging/src/k8s.io/api/core/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/types:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/util/intstr:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/wait:go_default_library", "//staging/src/k8s.io/apiserver/pkg/features:go_default_library",

Related discussion:
text: There is no value by that conversion, even worse it can be misused.
should we use in such case?
I do not think this is a bug. 25% == .25 and int(.25) == 0. ;) Even in the case where the user puts in something like 100% I do not think it's a bug. Users should not put strings like "25%" into intOrString and expect to get the integer 25 out. Likely a user doing that is confused about what format the field takes in. I am not sure why the function GetValueFromIntOrPercent exists, and I bet I am not going to like the answer :)
No. First, this depends on how you do the rounding. If you are rounding up (MaxSurge in Deployments), this is 1. Then, the replica size of the deployment also plays a part. 25% of a controller with 1 replica is different from a controller with 4 replicas, etc.
Also, the fact that IntValue returns 0 for every percentage has nothing to do with any logic. It's purely because the conversion errors out:
the first line there was supposed to be a joke, sorry. :) I know that the actual reason for returning 0 is the % sign means it is not an int. More seriously: I actually agree with the parsing function that percentages are not ints. Users who want to do this should not use IntOrString. Is there a place in the API that wants to do this?
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
/lifecycle frozen /remove-lifecycle stale
Opened to ensure all in-tree callers only call this when the type is Int (or verify it is a parseable number first), and to update the method documentation
Code change:
// ensureSandboxImageExists pulls the sandbox image when it's not present. func ensureSandboxImageExists(client libdocker.Interface, image string) error { <del> dockerCfgSearchPath := []string{"/.docker", filepath.Join(os.Getenv("HOME"), ".docker")} return ensureSandboxImageExistsDockerCfg(client, image, dockerCfgSearchPath) } func ensureSandboxImageExistsDockerCfg(client libdocker.Interface, image string, dockerCfgSearchPath []string) error { </del> _, err := client.InspectImageByRef(image) if err == nil { return nil

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?: What happened: We have a private registry configured (where all images including the sandbox one), are hosted. The registry credentials are being pulled by one of k8s credentials providers () With Kubernetes 1.7 sandbox image failed to be pulled with the following error message: Looks like with this only creds from docker config are being evaluated on the sandbox image pull What you expected to happen: Sandbox image pull should be attempted using credentials returned by not just the basic docker credential provider, but other credentials providers registered in the system. How to reproduce it (as minimally and precisely as possible): 1) Register private repo credentials with one of the k8s credential providers (we've tried with rancher). Configure the to use the image from the the private repo. 2) Make sure you are not logged in to this private repo on the kubelet host 3) Try to create a pod. Sandbox image pull will fail with an error mentioned above. Anything else we need to know?: Non-sandbox images from the same private repo were able to download correctly using private repo credentials provider. Environment: Kubernetes version (use ): 1.7.2 Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig node Just tested the same use case against k8s 1.5.x, it worked fine there and sandbox image was pulled using the credentials passed by the credential provider, not from docker config file. So it might have regressed in 1.7.x (haven't tested it on 1.6, so can't tell for sure)
Confirmed a bug introduced in dockershim. Will file a PR to fix this.
Code change:
// ensureSandboxImageExists pulls the sandbox image when it's not present. func ensureSandboxImageExists(client libdocker.Interface, image string) error { <del> dockerCfgSearchPath := []string{"/.docker", filepath.Join(os.Getenv("HOME"), ".docker")} return ensureSandboxImageExistsDockerCfg(client, image, dockerCfgSearchPath) } func ensureSandboxImageExistsDockerCfg(client libdocker.Interface, image string, dockerCfgSearchPath []string) error { </del> _, err := client.InspectImageByRef(image) if err == nil { return nil

Related discussion:
text: Could you also verify whether fixed your problem?
tested against your commits cherry-picked on top of 1.8 beta, the fix seems to work
thanks.
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/node: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
Code change:
echo "Setting up cluster monitoring using Heapster." detect-project <del> if ! gcloud compute firewall-rules --project "{$PROJECT}" describe monitoring-heapster &>/dev/null; then </del> <ins> if ! gcloud compute firewall-rules --project "${PROJECT}" describe monitoring-heapster &> /dev/null; then </ins> if ! gcloud compute firewall-rules create monitoring-heapster  --project "${PROJECT}"  --target-tags="${MINION_TAG}"  --network="${NETWORK}"  <del> --allow tcp:80 tcp:8083 tcp:8086 tcp:9200; then echo "Failed to set up firewall for monitoring" && false </del> <ins> --allow tcp:80 tcp:8083 tcp:8086; then echo -e "${color_red}Failed to set up firewall for monitoring ${color_norm}" && false </ins> fi fi <del> # Re-use master auth for Grafana get-password ensure-temp-dir sed -e "s/{KUBE_USER}/$KUBE_USER/g"  -e "s/{KUBE_PASSWORD}/$KUBE_PASSWORD/g"  "${KUBE_ROOT}/cluster/addons/cluster-monitoring/influx-grafana-pod.json"  > "${KUBE_TEMP}/influx-grafana-pod.json" </del> local kubectl="${KUBE_ROOT}/cluster/kubectl.sh" <del> if "${kubectl}" create -f "${KUBE_TEMP}/influx-grafana-pod.json" &> /dev/null  && "${kubectl}" create -f "${KUBE_ROOT}/cluster/addons/cluster-monitoring/influx-grafana-service.json" &> /dev/null  && "${kubectl}" create -f "${KUBE_ROOT}/cluster/addons/cluster-monitoring/heapster-pod.json" &> /dev/null; then local dashboard_url="http://$(${kubectl} get -o json pod influx-grafana | grep hostIP | awk '{print $2}' | sed 's/[,|"]//g')" echo echo "Grafana dashboard will be available at $dashboard_url. Wait for the monitoring dashboard to be online." echo "Use the master user name and password for the dashboard." echo </del> <ins> local grafana_host="" if "${kubectl}" create -f "${KUBE_ROOT}/cluster/addons/cluster-monitoring/" &> /dev/null; then # wait for pods to be scheduled on a node. 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}}) 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 </ins> else <del> echo "Failed to Setup Monitoring" </del> <ins> echo -e "${color_red}Failed to Setup Monitoring ${color_norm}" </ins> teardown-monitoring fi fi

Related discussion:
text: examples/monitoring/influx-grafana- and friends NEED to be replaced by a replication controller ASAP. As it stands they are bad examples. Also, they should probably move to contrib/monitoring to match contrib/logging and contrib/dns
Code change:
fi; # BEGIN_PROMETHEUS_TO_SD - name: prometheus-to-sd-exporter <del> image: k8s.gcr.io/prometheus-to-sd:v0.5.0 </del> <ins> image: k8s.gcr.io/prometheus-to-sd:v0.11.1 </ins> command: - /monitor - --stackdriver-prefix={{ prometheus_to_sd_prefix }}/addons

Related discussion:
text: the following images are using old client-go that would not work correctly starting 1.22+ if those images use in-cluster config(mounted service account token) to talk to kube-apiserver: if the above images use in-cluster config, they should use client-go 1.14+. xref: /assign /cc /sig instrumentation /priority important-soon
/triage accepted
Code change:
if svcInfo.localTrafficDSR { externalIPEndpoints = hnsLocalEndpoints } <del> // Try loading existing policies, if already available hnsLoadBalancer, err = hns.getLoadBalancer( externalIPEndpoints, loadBalancerFlags{isDSR: svcInfo.localTrafficDSR, sessionAffinity: sessionAffinityClientIP, isIPv6: proxier.isIPv6Mode}, sourceVip, externalIP.ip, Enum(svcInfo.Protocol()), uint16(svcInfo.targetPort), uint16(svcInfo.Port()), ) if err != nil { klog.ErrorS(err, "Policy creation failed") continue </del> <ins> if len(externalIPEndpoints) > 0 { // Try loading existing policies, if already available hnsLoadBalancer, err = hns.getLoadBalancer( externalIPEndpoints, loadBalancerFlags{isDSR: svcInfo.localTrafficDSR, sessionAffinity: sessionAffinityClientIP, isIPv6: proxier.isIPv6Mode}, sourceVip, externalIP.ip, Enum(svcInfo.Protocol()), uint16(svcInfo.targetPort), uint16(svcInfo.Port()), ) if err != nil { klog.ErrorS(err, "Policy creation failed") continue } externalIP.hnsID = hnsLoadBalancer.hnsID klog.V(3).InfoS("Hns LoadBalancer resource created for externalIP resources", "externalIP", externalIP, "hnsID", hnsLoadBalancer.hnsID) } else { klog.V(3).InfoS("Skipped creating Hns LoadBalancer for externalIP resources", "externalIP", externalIP, "hnsID", hnsLoadBalancer.hnsID) </ins> } <del> externalIP.hnsID = hnsLoadBalancer.hnsID klog.V(3).InfoS("Hns LoadBalancer resource created for externalIP resources", "externalIP", externalIP, "hnsID", hnsLoadBalancer.hnsID) </del> } // Create a Load Balancer Policy for each loadbalancer ingress for _, lbIngressIP := range svcInfo.loadBalancerIngressIPs {

Related discussion:
text: During a Kubernetes deployment the connectivity to web services from Windows nodes is flapping. There are intermittent traffic delays and some errors observed on web services during the deployment. Post deployment the flapping is no longer observed. No flapping in connectivity during the deployment. Create a deployment with multiple services and monitor connectivity. No response <details20 </details<detailsAKS </details<details</details<details</details<details</details<details</details
/sig windows
/triage accepted /priority important-soon
Code change:
type JSONPath struct { name       string parser     *Parser <del> stack      [][]reflect.Value // push and pop values in different scopes cur        []reflect.Value   // current scope values </del> beginRange int inRange    int endRange   int <ins> lastEndNode *Node </ins> allowMissingKeys bool }

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: (or in my instance) with does not correctly handle nested range statements. For example, one would expect that the following: would result in a list being output similar to this: but instead, results in a list being output like this: What you expected to happen: Nested range statements complete in the order in which they are specified in jsonpath query. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.11.0 Cloud provider or hardware configuration: OpenShift 3.11.141 on vSphere 6.5 OS (e.g: ): RHEL 7.7 Kernel (e.g. ): 3.10.0 Install tools:
/sig cli
/area kubectl
/assign
/sig api-machinery
/remove-sig cli
/remove-area cli /area api
Those labels are not set on the issue: <detailsIn response to : /remove-area cli /area api 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-area kubectl
Code change:
} func copyToPod(f cmdutil.Factory, cmd *cobra.Command, stdout, stderr io.Writer, src, dest fileSpec) error { <del> if len(src.File) == 0 { </del> <ins> if len(src.File) == 0 || len(dest.File) == 0 { </ins> return errFileCannotBeEmpty } reader, writer := io.Pipe() // strip trailing slash (if any) <del> if strings.HasSuffix(string(dest.File[len(dest.File)-1]), "/") { </del> <ins> if dest.File != "/" && strings.HasSuffix(string(dest.File[len(dest.File)-1]), "/") { </ins> dest.File = dest.File[:len(dest.File)-1] }

Related discussion:
text: <!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: panics What you expected to happen: Syntax error, as it is not legit cp syntax. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Occurs in every version 1.9.x and 1.10.x, but 1.8.x is safe. is similar, but it has a fix candidate already going in, that is not fixing this, so opening a separate issue. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: VM OS (e.g. from /etc/os-release): Ubuntu 18.04 Kernel (e.g. ): /sig cli
It seems to be fixed in 1.11 by
It was merged three months ago, any idea why it isn't in 1.10 too?
It was merged on March 31 and 1.10 was released on March 27: Can confirm it is not present in 1.10: Maybe we can cherry-pick it?
I've opened
Fixed by /close
Closing this issue. <detailsIn response to : Fixed by 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:
return &container, nil } } <ins> for _, container := range pod.Spec.InitContainers { if container.Name == containerName { return &container, nil } } </ins> return nil, fmt.Errorf("container %s not found", containerName) }

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: When referencing init container's env value from its fields, kubelet complains What you expected to happen: Init container should be supported to get env values from its own fields, as to How to reproduce it (as minimally and precisely as possible): a pod with init container refering its fields value as env value kubectl create -f test-pod-1.yaml cannot be created pod events Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g: ):Kernel (e.g. ):Install tools: Others:
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
The err happens at this line , it seems that we should search for init containers as well
Code change:
}, }, { <del> testName:           "node exists by node name", existsByProviderID: false, providerIDErr:      errors.New("unimplemented"), existsByNodeName:   true, </del> <ins> testName:           "exists by instance id", existsByProviderID: true, providerIDErr:      nil, hasInstanceID:      true, </ins> nodeNameErr:        nil, <del> expectedCalls:      []string{"instance-exists-by-provider-id", "instance-id"}, </del> <ins> expectedCalls:      []string{"instance-id", "instance-exists-by-provider-id"}, expectedNodeExists: true, </ins> node: &v1.Node{ ObjectMeta: metav1.ObjectMeta{ Name: "node0", }, <del> Spec: v1.NodeSpec{ ProviderID: "node0", </del> <ins> }, }, { testName:           "does not exist by no instance id", existsByProviderID: true, providerIDErr:      nil, hasInstanceID:      false, nodeNameErr:        cloudprovider.InstanceNotFound, expectedCalls:      []string{"instance-id"}, expectedNodeExists: false, node: &v1.Node{ ObjectMeta: metav1.ObjectMeta{ Name: "node0", </ins> }, }, }, { <del> testName:           "does not exist by node name", </del> <ins> testName:           "provider id returns error", </ins> existsByProviderID: false, providerIDErr:      errors.New("unimplemented"), <del> existsByNodeName:   false, </del> <ins> hasInstanceID:      true, </ins> nodeNameErr:        cloudprovider.InstanceNotFound, <del> expectedCalls:      []string{"instance-exists-by-provider-id", "instance-id"}, </del> <ins> expectedCalls:      []string{"instance-exists-by-provider-id"}, expectedNodeExists: false, </ins> node: &v1.Node{ ObjectMeta: metav1.ObjectMeta{ Name: "node0",

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The change here removes exiternal id, but the call to instance id was not made used at all, it will always return false. At this time no node was able to register What you expected to happen: ProviderId was used in check How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment:
similar to are you using --cloud-provider in your controller manager? are you also setting it on your kubelet?
I'm using acs-engine to deploy the cluster. Config is as following: I've proposed a fix. PTAL
/sig cluster-lifecycle