jiebi/CodeConvo huggingface dataset:
Change:
// make mountpoint rw/ro work as expected //FIXME revisit pkg/util/mount and ensure rw/ro is implemented as expected mode := "rw" <del> if rbd.readOnly { </del> <ins> if rbd.ReadOnly { </ins> mode = "ro" } rbd.plugin.execCommand("mount", []string{"-o", "remount," + mode, globalPDPath, dir})

Discussion:
etcd cluster backing apiserver died spontaneously, after restart apiserver pulled up the pods on different machines. Node storage was backed by ext4 over rbd, which became mounted on several nodes at once. That could have possibly led to data corruption. I guess that the proper way to mount rbd volume is to take a lock on it first, which will at least fail if it's locked somewhere else, requiring manual intervention, but not destroying data. The lock should be optional, in case a proper cluster fs is mounted over the rbd. In this case there was clearly no need for accessing the data from several pods so ext4 is deemed a proper fs.
, Vladimir Pouzanov < :
want to get some detail. How is your pod-to-rbd mapping like? Since rbd image is a block device, it can be used by one pod at a time. I am not sure if locking is a proper way to go - if the pod holds a lock but dies in the middle of mounting, the rbd image (or any other volume type) is then excluded from access. In such case, a high level coordination at apiserver is a better place to resolve this problem.
Here's my rc: I guess it's better to have a lock to be cleaned up manually rather than to have non-cluster fs to be mounted in several locations at once?
thanks, this pod looks good to me. what would cause multiple nodes run the same pod?
I don't know the exact reason of why kubelet didn't unmount the old fs, but after apiserver and scheduler were restarted pod got allocated on different node.
It is a scary thing to see etcd down, it is meant to be reliable...
Unfortunately I don't have long-term logging in test cluster so I have no idea why it actually died. but using kubedns as primary node resolver was clearly a bad idea, once it died, nodes stuck with no resolver at all.
your thought on HA?
Wrong Tim St. Clair?
- you HAVE to be ready to handle network partitions - the old node might still be alive and even using the volume, but the apiserver can't see the node, so it thinks it deletes the pod and starts it elsewhere. If RBD corrupts itslef in this case, it is not useful and we should strip it from the codebase.

, Huamin Chen wrote:
that makes sense. rbd doesn't corrupt itself. This is inconsistency happens when you have two pods mounting the same rbd image. How does GCE PD handle/prevent this case?
It doesn't allow more than one read-write attachment. Multiple read-only attachments is OK. Better to fail than to allow corruption. , Huamin Chen wrote:
That's neat. I have a lock fencing for rbd, testing now.
Change:
// skipPodUpdate checks whether the specified pod update should be ignored. // This function will return true if //   - The pod has already been assumed, AND <del> //   - The pod has only its ResourceVersion, Spec.NodeName, Annotations, ManagedFields and/or Finalizers //     updated. </del> <ins> //   - The pod has only its ResourceVersion, Spec.NodeName, Annotations, //     ManagedFields, Finalizers and/or Conditions updated. </ins> func (sched *Scheduler) skipPodUpdate(pod *v1.Pod) bool { // Non-assumed pods should never be skipped. isAssumed, err := sched.SchedulerCache.IsAssumedPod(pod)

Discussion:
What happened: An extra scheduling attempt is observed in some scenarios when kube-scheduler already has already assumed a pod and this has entered the binding routine. If, during this time, a pod update is received, the pod is back to the scheduling queue, even if binding succeeds. This is the correct behavior, as scheduling conditions might change. However this updates could just be unrelated status updates, such as updates to pod conditions. We observe an extra scheduling attempt, which is visible in the log line: Which indicates that an attempt was made when the pod was already scheduled. What you expected to happen: No extra scheduling attempts How to reproduce it (as minimally and precisely as possible): This depends on other controllers running on the cluster that might report pod conditions. One such controller is
/sig scheduling
Change:
testName                 string subsets                  []corev1.EndpointSubset epLabels                 map[string]string <ins> epAnnotations            map[string]string </ins> endpointsDeletionPending bool maxEndpointsPerSubset    int32 existingEndpointSlices   []*discovery.EndpointSlice

Discussion:
If I modify a custom endpoint, the kubectl annotation is mirrored to the generated endpoint slice Since the kubect last-applied-configuration tracks the status of the object, it shouldn't be mirrored since it doesn't apply to the generated object a custom endpoint an update on any of the fields the generated endpoint slice annotations /sig network
ping
if we agree this is a bug, the fix is just and adding some tests of course :)
Thanks for catching this! Agree this is a bug that we should fix.
/triage accepted
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue 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
Hey, I'm on it!
Hi While I have made the update mentioned in the above comment, I feel a bit lost on where to add/update tests. I understand that I probably shouldn't raise a PR without trying to add a few tests for this issue. So could you possibly guide me to the correct files(s) I should be looking into where the annotations for updated EndpointSlices are being tested?
Hey I think the easiest place to add tests might be here: You could add another test case where the Endpoints object had this label and then ensure that label was not copied over to an EndpointSlice.
Alright I'll check out these tests. Thank you!
/assign
Change:
// The CSIDriverRegistry feature gate is needed for this test in Kubernetes 1.12. Context("CSI attach test using mock driver [Feature:CSIDriverRegistry]", func() { tests := []struct { <del> name             string driverAttachable bool deployDriverCRD  bool </del> <ins> name            string disableAttach   bool deployDriverCRD bool </ins> }{ { <del> name:             "should not require VolumeAttach for drivers without attachment", driverAttachable: false, deployDriverCRD:  true, </del> <ins> name:            "should not require VolumeAttach for drivers without attachment", disableAttach:   true, deployDriverCRD: true, </ins> }, { <del> name:             "should require VolumeAttach for drivers with attachment", driverAttachable: true, deployDriverCRD:  true, </del> <ins> name:            "should require VolumeAttach for drivers with attachment", deployDriverCRD: true, </ins> }, { <del> name:             "should preserve attachment policy when no CSIDriver present", driverAttachable: true, deployDriverCRD:  false, </del> <ins> name:            "should preserve attachment policy when no CSIDriver present", deployDriverCRD: false, </ins> }, } for _, t := range tests { test := t It(t.name, func() { var err error <del> init(testParameters{registerDriver: test.deployDriverCRD, attachable: test.driverAttachable}) </del> <ins> init(testParameters{registerDriver: test.deployDriverCRD, disableAttach: test.disableAttach}) </ins> defer cleanup() _, claim, pod := createPod()

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: in Which test(s) are failing: Since when has it been failing: 2019-02-27 () -- since it was Testgrid link: Reason for failure: Timeout: Anything else we need to know: /kind failing-test /sig storage /priority important-soon /milestone v1.14 cc
cc Could you help with this please?
/assign
Neither of the failing tests mentioned in this issue are present in testgrid anymore. is all clear
Change:
Calls    []string IP       net.IP Machines []string <del> Zone     string </del> <ins> Zone </ins> } func (f *FakeCloud) addCall(desc string) {

Discussion:
Comments that the PR bot adds solely to trigger email notification of a label change, should be immediately deleted by the bot after it adds them. I have no idea what team to assign this to... cc/
, David Oppenheimer wrote:
(Motivation, of course, is to avoid having PR threads that are 90% bot comments...)
should really be an issue over in that's where (some of) the bots live. Lets make a list of which comments we want deleted immediately. [x] Label size. [x] Needs rebase. [x] test this stale CI [x] test this pending CI [x] PR changed after LGTM, removing LGTM. [x] Comment about blocking based on the paths touched (old docs) [x] unapproved cherrypick comment [x] cherrypicks must set a milestone [x] ok to test from bot I don't want to make it all comments. There are way too many times people have asked me "Why did the bot add 'do-not-merge'?" and I can just link them the comment 2 lines above which tells exactly why....
"Test this" with an issue is also useful, isn't it? On Apr 7, 2016 6:30 PM, "Eric Paris" wrote:
OK to test Add to whitelist On Apr 7, 2016 6:30 PM, "Eric Paris" wrote:
I was envisioning deleting the by the bot. (every 48 hours after LGTM, when retesting right before merge) not those by users (with an issue) After LGTM the bot will add , that one I can remove. The request to comes from the jenkins bot. And in that I am clueless...
any interest in a review (I'm trying to not just self merge all my own bot changes). This deleted hundreds and hundreds of comments.
Looks like reviewed it since your last message:

The contains instructions for downloading kubectl. The doesn't contain these instructions but it should if it's now the recommended way of running Kubernetes locally.
+1 Just ran into this.
cc
By the way, we encourage anyone to propose improvements/fixes to docs. You can do so pretty easily by clicking the pencil icon in the top right corner of every page of
kubectl download instructions to the guide in
Change:
} } <ins> // truncateMessage truncates a message if it hits the NoteLengthLimit. func truncateMessage(message string) string { max := validation.NoteLengthLimit if len(message) <= max { return message } suffix := " ..." return message[:max-len(suffix)] + suffix } </ins> func updatePod(client clientset.Interface, pod *v1.Pod, condition *v1.PodCondition, nominatedNode string) error { klog.V(3).InfoS("Updating pod condition", "pod", klog.KObj(pod), "conditionType", condition.Type, "conditionStatus", condition.Status, "conditionReason", condition.Reason) podCopy := pod.DeepCopy()

Discussion:
What happened: When a pod can't be scheduled and the cardinality of taints on nodes is high, the Note field in the event can become bigger than the 1024 allowed and the event isn't sent. The pod stays in a state of without en event which makes the User Experience very bad What you expected to happen: I would expect the Kube-scheduler to be able to send the event no matter how many different taints are on nodes How to reproduce it (as minimally and precisely as possible): add many different taints to nodes and then trying to schedule something which can't be successfully scheduled (higher CPU/memory than any node has) Anything else we need to know?: In this case the length of the message was 1334 characters. Environment: Kubernetes version (use ): 1.18.9 Cloud provider or hardware configuration: bare metal Possible solutions: make event size configurable, it's now hardcoded to 1024 characters make scheduler note aware of that limit and work around I, if length 1024 then truncate the string (so at least something is shown) produce N events splitting the text (preferred one): change event Note to be to something like: (the whole complete information would still be present in the pod status field. for debugging purposes)
/sig scheduling
/triage accepted /cc
I could provide the fix in case we define which solution is best
This is a consequence of I think we can just drop some reasons when we are building the status message if the message is too large. This comes from here /help
/remove-help /assign
how many different taints did you have? I think in all cases we should truncate the message as well:
Another remidiation is to supress outoutping nil fields (such as GenerateName:"", SelfLink:"", UID:"", ResourceVersion:"", etc.) in the EventRecorder side.
The size limit we're hitting is specifically on the field
Completely agreed
good issue~
/assign
/unassign
Change:
return !skipAttach, nil } <del> // TODO (#75352) add proper logic to determine device moutability by inspecting the spec. </del> <ins> // CanDeviceMount returns true if the spec supports device mount </ins> func (p *csiPlugin) CanDeviceMount(spec *volume.Spec) (bool, error) { <ins> driverMode, err := p.getDriverMode(spec) if err != nil { return false, err } if driverMode == ephemeralDriverMode { klog.V(5).Info(log("plugin.CanDeviceMount skipped ephemeral mode detected for spec %v", spec.Name())) return false, nil } </ins> return true, nil }

Discussion:
Inline CSI volumes that are embedded in Pod specs still trigger all volume operation stages (attach, device mount, mount). Similar to plugin.CanAttach, a new plugin-wide method should be able to turn device mount off when the source is ephemeral volume. References See volume mount operation : This issue will use code from
/sig storage /assign
This will use work from
Change:
fi CTLRMGR_LOG=${LOG_DIR}/kube-controller-manager.log <del> ${CONTROLPLANE_SUDO} "${GO_OUT}/hyperkube" controller-manager  </del> <ins> ${CONTROLPLANE_SUDO} "${GO_OUT}/hyperkube" kube-controller-manager  </ins> --v="${LOG_LEVEL}"  --vmodule="${LOG_SPEC}"  --service-account-private-key-file="${SERVICE_ACCOUNT_KEY}" 

Discussion:
Hyperkube supports a number of short aliases for commands, such as , , , , etc, rather than the longer , , , etc. There are comments indicating this is "unfortunate" and we still currently create these aliases in the hyperkube docker image: It'd be nice to simplify this, assuming we can find all uses of the short aliases and remove them. /kind cleanup Not sure which sig should own this, so tagging a few. /sig architecture cluster-lifecycle cli cc
interestingly, the command doesn't create the short aliases, though we also don't really use anywhere either.
I think we can just go ahead and start the deprecation cycle for this. WDYT? cc
cc as well
+1 to nuke it
/assign :wink: ok?
SGTM
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
/remove-lifecycle rotten
/help
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help 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
I would like to work on it!
It seems like this issue was already solved in ?
I don't think the hyperkube code was changed in that PR, only the image?
Yes, thanks for your comment, can i try to fix it ?
I made a PR here: . Review/feedback/suggestions appreciated! :)
/assign /unassign
GitHub didn't allow me to assign the following users: Rand01ph.

Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign /unassign 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-sig architecture cli /sig release Does anyone even still use hyperkube? Wouldn't they use kubeadm or k3s instead?
AFAIK, SAP (the company) still use hyperkube.
aks-engine deployer ( ) still uses hyperkube
Since this ticket is completed now. Can this todo be removed?
we are removing the whole thing :)
Change:
check := ImagePullCheck{ runtime:         containerRuntime, imageList:       []string{"img1", "img2", "img3"}, <del> imagePullPolicy: v1.PullIfNotPresent, </del> <ins> imagePullPolicy: "", // should be defaulted to v1.PullIfNotPresent </ins> } warnings, errors := check.Check() if len(warnings) != 0 {

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --https://k8s- kubeadm-init 06-22 https://k8s- all kubeadm jobs are failing against k/k master. is this failing after we merged?
cc /sig cluster-lifecycle /area kubeadm kinder cluster preparation constructs images locally by downloading tarballs and tagging them with: then running it would find the image locally and not pull it from GCR. does not contain pre-release images, so trying to pull these images would fail. i think the problem here is that we broke the default behavior with
ok, the problem is indeed here: empty string "" should be the same as PullIfNotPresent.
should be fixed by
/triage accepted
Change:
if ip := net.ParseIP(host); ip == nil || !ip.IsLoopback() || ip.To4() != nil { t.Fatalf("expected IPv6 host to be loopback, got %q", host) } if port != "443" { t.Fatalf("expected 443 as port, got %q", port) } } <ins> func isIPv6LoopbackSupported() (ipv6 bool, ipv6only bool, err error) { addrs, err := net.InterfaceAddrs() if err != nil { return false, false, err } ipv4 := false for _, address := range addrs { ipnet, ok := address.(*net.IPNet) if !ok || !ipnet.IP.IsLoopback() { continue } if ipnet.IP.To4() == nil { ipv6 = true continue } ipv4 = true } ipv6only = ipv6 && !ipv4 return ipv6, ipv6only, nil } </ins>

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: LoopbackHostPort code is calling the which depends on the machine on which this test is running. Especially in this particular testase it looks for the ipv6 ip address which does not exist because the machine is not configured for ipv6. Because of the LoopbackHostPort function bahaves based on the interfaces configured, test will fail if machine is not really configured with ipv6. Need to rewrite the testcase to handle such situation. What you expected to happen: Testcase should pass
/sig network
/cc
/triage unresolved I am a bot run by ‍
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
/remove-triage unresolved
Change:
return } <del> nodeAddresses, err := getNodeAddressesByProviderIDOrName(ctx, instances, node) </del> <ins> nodeAddresses, err := getNodeAddressesByProviderIDOrName(ctx, instances, node.Spec.ProviderID, node.Name) </ins> if err != nil { klog.Errorf("Error getting node addresses for node %q: %v", node.Name, err) return

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: introduces a regression that func is invoked on a Node obj without , hence it can fail fetching the node addresses when the is not set. What you expected to happen: I would expect cloud-controller-manager to be able to initialize new Node. How to reproduce it (as minimally and precisely as possible): the gcp legacy-cloud-controller v1.18.1 () that the node-controller cannot initialize a new Node. Logs of the cloud-controller-manager repeated multiple times: Ensure that the Node is with the taint. Ensure that the of the Node is not set. The cloud-controller-manager is not running on the host machine and that's why it cannot call the gce matadata. But it was never a hard requirement for cloud-controller-manager to run on the host machine. Anything else we need to know?: The legacy cloud-controller-manager v1.17.x is working perfectly fine. Environment: Kubernetes version (use ):v1.18.1 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /kind regression
/cc
can we open a new issue re:
Change:
"testing" "k8s.io/apimachinery/pkg/util/sets" <ins> "k8s.io/component-base/metrics/testutil" </ins> api "k8s.io/kubernetes/pkg/apis/core" )

Discussion:
<!-- Feature requests are unlikely to make progress as an issue. Instead, please suggest enhancements by engaging with SIGs on slack and mailing lists. A proposal that works through the design along with the implications of the change can be opened as a KEP: --Add metrics to apiserver tracking the service IP allocator - around how many IP addresses are used(allocated) vs available, and/or if there were any errors allocating service IPs to a service. We want to track if we are approaching the limit of the ServiceClusterIPRange, which is a fixed CIDR and difficult to change. Currently while we can approximate the usage looking at services in the cluster, it is not coming from the source allocator which is within the apiserver. Similar metrics are currently available for the node's ipam allocatior: /area apiserver /sig instrumentation /sig network
/triage accepted /assign I see something like this, gauges for and can you expand on this? a counter incremented each time an IP allocation fails?
that is one option. for contrast the nodeipam metric has an 'allocationtriesper_request' metric - i was imagining something similar to an 'attempts', but with a success:true/false tag/facet so we could compare how often allocations are attempted/how often they fail. I will defer to the experts here as I'm not sure what the status quo for reporting attempts/failures are. I'm not sure if there's any code paths that would cause allocation failures other than usage total (or available <= 0) - but having them separated out like that would be handy in that scenario. (maybe etcd internal allocation is corrupt? or context deadline exceeded)
Change:
return nil } <del> // TODO: extend for other providers if s.CloudProvider == "gce" || s.CloudProvider == "aws" { </del> <ins> if cloudprovider.IsCloudProvider(s.CloudProvider) { </ins> cloud, err := cloudprovider.InitCloudProvider(s.CloudProvider, s.CloudConfigFile) if err != nil { return fmt.Errorf("%q cloud provider could not be initialized: %v", s.CloudProvider, err)

Discussion:
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): cloud provider CloudProviderOptions DefaultExternalHost Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST in we have a DefaultExternalHost func that contains a TODO stating that we should extend it to other cloud providers, since it only support AWS and CGE for now, using the following condition :
/assign
/area apiserver
/kind enhancement
/sig api-machinery
Thanks, forgot the sig. I will submit PR on monday.