jiebi/CodeConvo huggingface dataset:
Change:
} status := &v1.LoadBalancerStatus{} <del> status.Ingress = []v1.LoadBalancerIngress{{IP: vip.Address}} </del> if floatingPool != "" && !internalAnnotation { floatIPOpts := floatingips.CreateOpts{ FloatingNetworkID: floatingPool,

Discussion:
When creating a service passing the annotation , two IPs are created in the service, a private and a public: Having a private IP is not a desired scenario for service discovery in federated global environments. If we have, for example, a cluster in GKE and join a local OpenStack cluster, this private IP is written in the DNS zone but the GKE cluster won't be able to access it. We could add an annotation to say we don't want the private IP to be registered in service's LoadBalancer Ingress field, like: or And when it's false, only the public IP would be written in the service, therefore in the DNS zone /kind feature
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 openstack /sig federation
'' sounds better.
I don't like adding annotations just to make things work. I counter-propose just not publishing the private IP whenever there is also a floating-ip (without a configuration option to control this behaviour).
Change:
"io/ioutil" "path" "strings" <del> "syscall" </del> "github.com/GoogleCloudPlatform/kubernetes/pkg/kubelet/dockertools" "github.com/GoogleCloudPlatform/kubernetes/pkg/kubelet/network"

Discussion:
/priority critical-urgent /priority failing-test /kind bug /status approved-for-milestone This test has been failing since 2017-11-22 in which is on the , and prevents us from cutting [v1.9.0-beta.1] (kubernetes/sig-release). Is there work ongoing to bring this job back to green? https://k8s- first bad: https://k8s- this is also failing on (non-release-blocking) triage cluster suspect commit range:
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code freeze, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
/remove-area platform/gke bad copy-pasta
This is a new test that was for a 1.9 alpha feature but actually exposed a bug with a different 1.8 alpha feature. Some discussion in . Since this seems to be a bug introduced in 1.8, I'm not sure if it needs to block 1.9. cc
Change:
<ins> #!/bin/bash # Copyright 2015 The Kubernetes Authors All rights reserved. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. # This script is invoked by crond every minute to check if monit is # up and oom protected. If down it restarts monit; otherwise, it exits # after applying oom_score_adj PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin PROGNAME=monit FULLPATH=/usr/bin/$PROGNAME pids=$(pidof $FULLPATH) if [[ "${pids}" == "" ]]; then service $PROGNAME start sleep 10 fi # Apply oom_score_adj: -901 to processes pids=$(pidof $FULLPATH) for pid in "${pids}"; do echo -901 > /proc/$pid/oom_score_adj done </ins>

Discussion:
The cluster I created on Friday (at head) was running over the weekend, and when I tried to talk to it this morning, I couldn't. SSH'ing into the master, I couldn't hit and Docker isn't running and neither is monit so what happened to monit? found in monit. My questions are: "Why?" and "Should we try to debug this further?" pointed out that a possible preventative measure is to have a cron job running that kicks monit if it's dead. I left the cluster running, so if anyone would like me to run commands or would like to dig in more, please let me know.
I haven't thought much about this, but it may be related to Docker being slow at restarting? As a side note, it seems like pretty poor design that monit dies if it fails to restart something.
Could you please take a look at this? Thanks!
you started the cluster on Friday, could you connect to apiserver using kubectl ? you see any errors in the file ?
cc
, the cluster functioned on Friday; I was running tests against it. (If you look at the monit log I pasted above, it appears it was functioning for quite a while.) don't see any errors there, but I can dump it here if it would help (it's quite long, obviously).
out-of-memory errors seen/logged around the time when monit failed to fork a child process. seems to consume 400m of memory. not sure why it is so high the fork did fail because of insufficient memory, but this is a guess and no logs to substantiate it
Just as an explicit followup, there were at least 8 out-of-memory errors that happened on that instance (a master) from the logs in —is this normal? I can provide several different logs or VM access for interested parties...
Regardless of the cause of the problem (which I agree would be interesting to discover) it seems like we need a cron job or something to make sure that monit is always running. can you look into how we can babysit our babysitter?
I will take a look this one today since there are several ones related to each other: , , ...
Change:
// nodeConditionMessageFmt is the message for evictions due to resource pressure. nodeConditionMessageFmt = "The node had condition: %v. " // containerMessageFmt provides additional information for containers exceeding requests <del> containerMessageFmt = "Container %s was using %s, which exceeds its request of %s. " </del> <ins> containerMessageFmt = "Container %s was using %s, request is %s, has larger consumption of %v. " </ins> // containerEphemeralStorageMessageFmt provides additional information for containers which have exceeded their ES limit containerEphemeralStorageMessageFmt = "Container %s exceeded its local ephemeral storage limit %q. " // podEphemeralStorageMessageFmt provides additional information for pods which have exceeded their ES limit

Discussion:
when the pod is evicted due to low imagefs.available, the prompt is difficult to understand. it showed: But the container was evicted not by exceeding its request of 0 ephemeral-storage, but due to reaching the evictionHard of the node. The correct prompt message points out the reason for the pod eviction. don't print "which exceeds its request of 0.", because the container was evicted not by exceeding its request of 0. % oc label mcp worker custom-kubelet-eviction=small-pods evictionHard by creating a kubeletconfig % oc create -f custom-kubelet- custom-kubelet- several minutes, the mcp worker finish rolling out to the latest mc a pod % oc create -f hello-pod- hello-pod- a large file in container, make imagefs.available < 90Gi (the current available disk size is 111G ) command terminated with exit code 137 the node status the pod status % oc get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES hello-pod-2 0/1 ContainerStatusUnknown 1 7m58s 10.131.0.7 ip-10-0-213- <none<none% oc get pod hello-pod-2 -o yaml No response <details</details<detailsaws </details<details</details<details</details<details</details<details</details
/sig node
/assign
/assign
/triage accepted
Change:
import ( "context" "fmt" <ins> "os" "strings" </ins> "k8s.io/api/core/v1" "k8s.io/kubernetes/pkg/cloudprovider"

Discussion:
<!-- 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: When useInstanceMetadata is set to true for vmss nodes, their providerID is wrong. What you expected to happen: Their providerID should be in format azure:///subscriptions/&lt;subscription-id/resourceGroups/&lt;rg-name/providers/Microsoft.Compute/virtualMachineScaleSets/&lt;scaleset-name/virtualMachines/&lt;instance-id 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:
/sig azure
adding priority important-soon so that this issue can stay in 1.10. Please update if incorrect. /priority important-soon
Change:
}, } } func (s *disruptiveTestSuite) getTestSuiteInfo() TestSuiteInfo { return s.tsInfo }

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: [sig-storage] In-tree Volumes [Driver: local][LocalVolumeType: block] [Testpattern: Pre-provisioned PV (block volmode)] disruptive[Disruptive] Should test that pv used in a pod that is force deleted while the kubelet is down cleans up when the kubelet returns. Since when has it been failing: 10/8/19 Testgrid link: https://k8s- Reason for failure: Introduced by but root cause is probably Anything else we need to know:
/assign
/milestone 1.17 /priority important-soon this is consistently failing in release-master-informing job could you please take a look?
The provided milestone is not valid for this repository. Milestones in this repository: [, , , , , , , , ] Use to clear the milestone. <detailsIn response to : /milestone 1.17 /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
/milestone v1.17
Change:
var metadataAccessor = meta.NewAccessor() <ins> var attachFunc = attach.DefaultAttachFunc </ins> type RunObject struct { Object  runtime.Object Mapping *meta.RESTMapping

Discussion:
The command provides a flag but this doesn't do anything. most likely the flag shouldn't exist. I have no idea how kustomize could be useful here to start a single pod. This creates a pod, and shows that is ignored: No response <details</details<detailsAzure, K3OS</details<detailsOSX 11.6.1 (Big Sur) </detailsNo response No response No response
/sig cli
This comes from the inclusion of DeleteFlags: brings in FilenameFlags: has Kustomize, resulting in the flag: I suspect there are many flags from DeleteFlags that don't really apply to . : Not sure what this would do : seems to be ignored and : doesn't seem to be used : doesn't seem to be used : also probably doesn't apply There might be others as well...
It seems to delete object which created by command.
I agree, As far as I can see, , and have this deleteFlags exposure.
/assign
/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
/triage accepted
Change:
notMount = true } if !notMount { <del> linuxHostUtil := hostutil.NewHostUtil() mntInfo, err := linuxHostUtil.FindMountInfo(bindPathTarget) </del> <ins> // It's already mounted, so check if it's bind-mounted to the same path samePath, err := checkSubPathFileEqual(subpath, bindPathTarget) </ins> if err != nil { <del> return false, "", fmt.Errorf("error calling findMountInfo for %s: %s", bindPathTarget, err) </del> <ins> return false, "", fmt.Errorf("error checking subpath mount info for %s: %s", bindPathTarget, err) </ins> } <del> if mntInfo.Root != subpath.Path { </del> <ins> if !samePath { </ins> // It's already mounted but not what we want, unmount it if err = mounter.Unmount(bindPathTarget); err != nil { return false, "", fmt.Errorf("error ummounting %s: %s", bindPathTarget, err)

Discussion:
When we merged - we introduced comparison of subpath sources: But subpaths source comparison never works properly for all volume types, even if subpath and source remains unchaged. This is because we are comparing wrong things. For a given volume - is usually: But according - the root is - . This means that - if creation of a container times out, then another container can not start until old container exits, because subapth comparison above will be false and kubelet will try to umount the subpath bind mount and it will keep failing with "device is busy" errors. So subpath bind mount can not be reused at all. This is sort of expensive, for containers that use selinux. Because it means each container creation will potentially run recursive chcon again on the entire subpath etc.
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 node /sig storage
cc
/remove-sig node
Change:
apiVersion: v1 kind: ReplicationController metadata: <del> name: kube-dns-v18 </del> <ins> name: kube-dns-v19 </ins> namespace: kube-system labels: k8s-app: kube-dns <del> version: v18 </del> <ins> version: v19 </ins> kubernetes.io/cluster-service: "true" spec: replicas: $DNS_REPLICAS selector: k8s-app: kube-dns <del> version: v18 </del> <ins> version: v19 </ins> template: metadata: labels: k8s-app: kube-dns <del> version: v18 </del> <ins> version: v19 </ins> kubernetes.io/cluster-service: "true" spec: containers:

Discussion:
Observed weird memory spikes for both the dns healthz and kube-dns pods in production. Kube-dns didn't oom because there's enough headroom, but healthz did. I can't explain the spikes yet. I tried a bunch of different repros: no , bad nslookup command, sharing the node with cpu hogs etc, but was unable to trigger it. The memory grows, but stays under 10Mi. As a short term mitigation, we stole some ram from kube-dns, because it was always comfortably within limits. Related b/
can be closed -- healthz has been removed
-- close issue?
Change:
} <ins> func TestEmptySubsets(t *testing.T) { ns := metav1.NamespaceDefault om := func(name string) metav1.ObjectMeta { return metav1.ObjectMeta{Namespace: ns, Name: name} } endpoints := &corev1.EndpointsList{ Items: []corev1.Endpoints{{ ObjectMeta: om("foo"), Subsets:    nil, }}, } fakeClient := fake.NewSimpleClientset() if endpoints != nil { fakeClient = fake.NewSimpleClientset(endpoints) } epAdapter := reconcilers.NewEndpointsAdapter(fakeClient.CoreV1(), nil) reconciler := reconcilers.NewMasterCountEndpointReconciler(1, epAdapter) endpointPorts := []corev1.EndpointPort{ {Name: "foo", Port: 8080, Protocol: "TCP"}, } err := reconciler.RemoveEndpoints("foo", net.ParseIP("1.2.3.4"), endpointPorts) if err != nil { t.Errorf("unexpected error: %v", err) } } </ins> func TestCreateOrUpdateMasterService(t *testing.T) { ns := metav1.NamespaceDefault om := func(name string) metav1.ObjectMeta {

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: In kubernetes 1.15, Panic happends in kube-apiserver. Subsets[0] is nil when endpoints has no subsets The Panic happens in here: And everything returns to normal when we delete the endpoints in etcd What you expected to happen: Maybe kube-apiserver should print error,not panic How to reproduce it (as minimally and precisely as possible): The host's iowait of ETCD is high Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration:NA OS (e.g: ):Kernel (e.g. ):Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig release
/remove-sig release /sig api-machinery
/assign
Change:
d.wg.Wait() } <del> // PublishResources implements [DRAPlugin.PublishResources]. func (d *draPlugin) PublishResources(ctx context.Context, resources Resources) { </del> <ins> // PublishResources implements [DRAPlugin.PublishResources]. Returns en error if // kubeClient or nodeName are unset. func (d *draPlugin) PublishResources(ctx context.Context, resources Resources) error { if d.kubeClient == nil { return errors.New("no KubeClient found to publish resources") } if d.nodeName == "" { return errors.New("no NodeName was set to publish resources") } </ins> d.mutex.Lock() defer d.mutex.Unlock()

Discussion:
When calling draplugin.Start without supplying kubeclient no error is reported, while the kubeclient is vital for further announcement of resourceSlice. An error needs to be returned when nodeName or kubeclient parameters are not set. Do not supply kubeclient parameter when creating draplugin, for isntance here: No response master <details</details<details</details<details</details<details</details<details</details
/sig node /triage accepted /project 95
Change:
clientCA, err := s.getClientCA() if err != nil { <del> return err </del> <ins> if _, ignorable := err.(ignorableError); !ignorable { return err } else { glog.Warning(err) } </ins> } if err = c.ApplyClientCert(clientCA.ClientCA, servingInfo); err != nil { return fmt.Errorf("unable to load client CA file: %v", err)

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: When I start the core API server with , it populates the ConfigMap in namespace with the requestheader CA. This allows the extension API server to dynamically discover the CA and use it for validating the client certificate of aggregator layer. See for documentation However, if the core API server doesn't use certificate based authentication for it's clients i.e. flag isn't set in core API server then the extension API server fails to start with error message I believe this is coming from bootstrap code in extension API server . What you expected to happen: Extension API server should be able to start and not require that both and be present in the ConfigMap. This allows Kubernetes clusters which don't use certificate based authentication for core API server to be able to dynamically discover the requestheader-ca instead of having to mount it as a secret. How to reproduce it (as minimally and precisely as possible): Create a Kubernetes cluster which uses non certificate based authentication for core API server like Webhook based authentication. Example: You can launch an Amazon EKS cluster which uses Webhook based authentication following steps outlined . Setup aggregator layer by adding flags mentioned . CA certificate and client certificate for aggregator layer can be generated using and . Deploy metrics server to cluster following steps in Deployment section of README Get logs of metrics server pod and it should be failing with error message above Anything else we need to know?: It's possible there is a reason which is not evident to me as to why extension API server would require both client-ca-file and requestheader-client-ca-file to be present in the ConfigMap. Environment: Kubernetes version (use ): 1.10.3 Cloud provider or hardware configuration: Amazon EKS OS (e.g. from /etc/os-release): Kubernetes control plane and nodes = Amazon Linux 2 (2017.12) LTS Release Candidate (4.14.42).
/sig api-machinery /cc
since it looks like the at-mention didn't take
/sig auth /assign
Thanks Jordan. This is something we are interested in contributing to and ask for being cherrypicked to patch releases of 1.10.x and 1.11.x. That conversation can wait once we have the PR out.

Quick update: I'm working on sending a PR for this issue by this week
- Now that this is merged, can we open up the possibility of cherry picking to 1.10.x and 1.11.X please?
sure, opened , ,
Change:
for _, test := range tests { for i, podInfo := range test.podInfoList { testPod := podInfo.pod <del> hash, isValid := ecache.getHashEquivalencePod(testPod) if isValid != podInfo.hashIsValid { </del> <ins> eclassInfo := ecache.getEquivalenceClassInfo(testPod) if eclassInfo == nil && podInfo.hashIsValid { </ins> t.Errorf("Failed: pod %v is expected to have valid hash", testPod) } <del> // NOTE(harry): the first element will be used as target so // this logic can't verify more than two inequivalent pods if i == 0 { targetHash = hash targetPodInfo = podInfo } else { if targetHash != hash { if test.isEquivalent { t.Errorf("Failed: pod: %v is expected to be equivalent to: %v", testPod, targetPodInfo.pod) </del> <ins> if eclassInfo != nil { // NOTE(harry): the first element will be used as target so // this logic can't verify more than two inequivalent pods if i == 0 { targetHash = eclassInfo.hash targetPodInfo = podInfo } else { if targetHash != eclassInfo.hash { if test.isEquivalent { t.Errorf("Failed: pod: %v is expected to be equivalent to: %v", testPod, targetPodInfo.pod) } </ins> } } }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Today, . This seems unnecessary and should be done once for all the nodes. Is this a BUG REPORT or FEATURE REQUEST?: /kind enhancement /sig scheduling cc:
/assign Thanks, will send fix per slack discussion.
/cc
Change:
"federation-apiserver", "--bind-address=0.0.0.0", "--etcd-servers=http://localhost:2379", <del> "--service-cluster-ip-range=10.0.0.0/16", </del> "--secure-port=443", "--client-ca-file=/etc/federation/apiserver/ca.crt", "--tls-cert-file=/etc/federation/apiserver/server.crt",

Discussion:
Federation system started via kubefed is broken on master Kubernetes version (use ): Environment: Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: kube- Others: What happened: As part of - change the api-server options were moved out from genericapiserver package. One of the options moved was - but when using to start a federation plane it still starts with following option: Which obviously results in pod never coming up because that option no longer exists there. I am working on fixing it. cc
Fixed in . Also in
Change:
"k8s.io/kubernetes/pkg/apis/storage/v1/util", "k8s.io/kubernetes/pkg/capabilities", "k8s.io/kubernetes/pkg/client/conditions", <ins> "k8s.io/kubernetes/pkg/cloudprovider/providers", </ins> "k8s.io/kubernetes/pkg/controller", "k8s.io/kubernetes/pkg/controller/deployment/util", "k8s.io/kubernetes/pkg/controller/nodelifecycle",

Discussion:
What happened: There is to manage import ways under but that doesn't work at our upstream CI. We can enable it by But if doing that, we will face the following error with What you expected to happen: I hope the check is always running to block invalid import ways at upstream CI system. How to reproduce it (as minimally and precisely as possible): As line into arguments.InputDirs of
/sig testing /area e2e-test-framework