jiebi/CodeConvo huggingface dataset:
Change:
package builder import ( <del> "k8s.io/klog/v2" </del> <ins> "fmt" "strings" </ins> "k8s.io/kube-openapi/pkg/aggregator" "k8s.io/kube-openapi/pkg/spec3" "k8s.io/kube-openapi/pkg/validation/spec" ) <ins> const metadataGV = "io.k8s.apimachinery.pkg.apis.meta.v1" const autoscalingGV = "io.k8s.api.autoscaling.v1" </ins> // MergeSpecs aggregates all OpenAPI specs, reusing the metadata of the first, static spec as the basis. // The static spec has the highest priority, and its paths and definitions won't get overlapped by // user-defined CRDs. None of the input is mutated, but input and output share data structures.

Discussion:
Related to Seeing the following errors in kube-apiserver logs when CRDs are applied: No errors in logs Apply any CRD manifest No response <details</details<details</details<details</details<detailsRancher RKE2 </details<detailscontainerd 1.6.4 </details<detailscanal </details
/sig api-machinery
/assign
Did this cause any specific trouble to your cluster I'm curious what the impact/severity of this is.
Everything seems to work fine, but there's a bunch of log spew every time a CRD manifest is loaded. In K3s we mix all the control-plane component logs together in a single pair of stdout/stderr streams so it's quite noisy, compared to previous releases. The fact that these come out at WARN level with a scary prefix makes them look pretty serious, and I expect we will get a fair bit of users asking about it once we release.
/triage accepted
Change:
} tests := []struct { <del> description   string node          *corev1.Node expected      *corev1.Node pods          []corev1.Pod rcs           []corev1.ReplicationController replicaSets   []appsv1.ReplicaSet args          []string expectWarning string expectFatal   bool expectDelete  bool </del> <ins> description                string node                       *corev1.Node expected                   *corev1.Node pods                       []corev1.Pod rcs                        []corev1.ReplicationController replicaSets                []appsv1.ReplicaSet args                       []string failUponEvictionOrDeletion bool expectWarning              string expectFatal                bool expectDelete               bool </ins> }{ { description:  "RC-managed pod",

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: kubectl drain crashed with panic when apiserver connection disappeared while there were pods that couldn't be evicted/deleted (sorry, the problem is a bit hard to reproduce and the log was lost) What you expected to happen: kubectl drain should exit with a proper error message How to reproduce it (as minimally and precisely as possible): Try kubectl drain multiple times, interrupting the connection during eviction/deletion Anything else we need to know?: The here can be in case if returns an error, and will panic upon accessing : This causes the c Environment: Kubernetes version (use ): The problem is present as of but is also present in earlier versions (I have a fix for this bug)
/priority important-longterm /sig cli
Change:
} return nil, fmt.Errorf("multiple volume plugins matched: %s", strings.Join(matchedPluginNames, ",")) } <ins> // Issue warning if the matched provider is deprecated if detail, ok := deprecatedVolumeProviders[matches[0].GetPluginName()]; ok { klog.Warningf("WARNING: %s built-in volume provider is now deprecated. %s", matches[0].GetPluginName(), detail) } </ins> return matches[0], nil }

Discussion:
The plugin and/or the code behind the plugin does not seem to be maintained, is it time to deprecate it?
/sig storage
cc ?
/area code-organization
LGTM
Change:
//Test Case 1: Check if anotations are copied properly from deployment to RS t.Run("SetNewReplicaSetAnnotations", func(t *testing.T) { <del> //Try to set the increment revision from 1 through 20 for i := 0; i < 20; i++ { </del> <ins> //Try to set the increment revision from 11 through 20 for i := 10; i < 20; i++ { </ins> nextRevision := fmt.Sprintf("%d", i+1) <del> SetNewReplicaSetAnnotations(&tDeployment, &tRS, nextRevision, true) </del> <ins> SetNewReplicaSetAnnotations(&tDeployment, &tRS, nextRevision, true, 5) </ins> //Now the ReplicaSets Revision Annotation should be i+1 <ins> if i >= 12 { expectedHistoryAnnotation := fmt.Sprintf("%d,%d", i-1, i) if tRS.Annotations[RevisionHistoryAnnotation] != expectedHistoryAnnotation { t.Errorf("Revision History Expected=%s Obtained=%s", expectedHistoryAnnotation, tRS.Annotations[RevisionHistoryAnnotation]) } } </ins> if tRS.Annotations[RevisionAnnotation] != nextRevision { t.Errorf("Revision Expected=%s Obtained=%s", nextRevision, tRS.Annotations[RevisionAnnotation]) }

Discussion:
What happened: We created a Deployment and continuously updated an annotation on it periodically for a week. Eventually, we noticed errors in the controller-manager logs due to the annotation growing too large. Example annotations: controller-manager error: What you expected to happen: that do not change the revision number should not be to the revision history. revision history should be capped at a fixed number of elements, it should not be possible to have unbounded growth for Deployments that are frequently updated. How to reproduce it (as minimally and precisely as possible): a Deployment modify an annotation on it and note that the annotation gets the same number appended every time. Environment: Kubernetes version (use ):
/sig scalability Not 100% sure where this one fits, I couldn't determine which group owns the Deployment/ReplicaSet controllers, but this is a scalability problem
/sig apps
Agree with these, and if the limit is hit, the beginning of the history can be removed.
/assign
Change:
func (os *OpenStack) GetDevicePathBySerialID(volumeID string) string { // Build a list of candidate device paths. // Certain Nova drivers will set the disk serial ID, including the Cinder volume id. <ins> // Newer OpenStacks may not truncate the volumeID to 20 chars. </ins> candidateDeviceNodes := []string{ // KVM fmt.Sprintf("virtio-%s", volumeID[:20]), <ins> fmt.Sprintf("virtio-%s", volumeID), </ins> // KVM virtio-scsi fmt.Sprintf("scsi-0QEMU_QEMU_HARDDISK_%s", volumeID[:20]), <ins> fmt.Sprintf("scsi-0QEMU_QEMU_HARDDISK_%s", volumeID), </ins> // ESXi fmt.Sprintf("wwn-0x%s", strings.Replace(volumeID, "-", "", -1)), }

Discussion:
What happened: OpenStack Train with StorageClass the volume attachment succeeds to the node but the kubelet fails to find the attached volume. When a pod attempts to use the volume it becomes stuck in state . Investigation in OpenStack shows the volume is attached to the node. Further, we confirmed the volume is attached to the node, appears as and with a symbolic links as and . Further investigation has determined that the underlying issue is that the volume detection truncates the volume ID at 20 characters while the OpenStack volume ID is 36 characters. Comparing to running on OpenStack 13, we find the symbolic link at is truncated at 20 characters and everything works, but in OpenStack Train this symbolic link is not truncated. We tracked this back through the configuration in : And then used to confirm on OpenStack 13 this value is truncated: But on OpenStack Train it is not:
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 storage /assign
Change:
if err != nil { return err } <ins> if volume.Status == VolumeAvailableStatus { // "available" is fine since that means the volume is detached from instance already. glog.V(2).Infof("volume: %s has been detached from compute: %s ", volume.ID, instanceID) return nil } </ins> if volume.Status != VolumeInUseStatus { errmsg := fmt.Sprintf("can not detach volume %s, its status is %s.", volume.Name, volume.Status) glog.Errorf(errmsg)

Discussion:
When detaching disk, if the volume status is already available, detach should return true instead of error.
/sig openstack
Related to
Change:
}, } lockPath14x, lockPath16x := getLockPaths() <ins> // the lockPath14x is a UNIX socket which is cleaned up automatically on close, but the // lockPath16x is a plain file which is not cleaned up. defer os.Remove(lockPath16x) </ins> runner := newInternal(&fexec, ProtocolIPv4, lockPath14x, lockPath16x) err := runner.RestoreAll([]byte{}, NoFlushTables, RestoreCounters)

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: files like: are being created, I think from the "unit" tests. What you expected to happen: running tests should not leave files in tree, especially not tracked by git! How to reproduce it (as minimally and precisely as possible): ? I think? Anything else we need to know?: spotted in a PR commit Environment: Kubernetes version (use ): 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 network /assign
I'm also finding an file while working on this locally??? /triage accepted
I suspect , which introduced these lockfile paths and removed deferred removal
is a simple approach to mitigate, but it doesn't solve cluttering the source tree with leaked files. I'm not sure we actually want to take that approach.
Change:
// mapper. func (e ShortcutExpander) VersionAndKindForResource(resource string) (defaultVersion, kind string, err error) { resource = expandResourceShortcut(resource) <del> return e.RESTMapper.VersionAndKindForResource(resource) </del> <ins> defaultVersion, kind, err = e.RESTMapper.VersionAndKindForResource(resource) // TODO: remove this once v1beta1 and v1beta2 are deprecated if err == nil && kind == "Minion" { err = fmt.Errorf("Alias minion(s) is deprecated. Use node(s) instead") } return defaultVersion, kind, err </ins> } // expandResourceShortcut will return the expanded version of resource

Discussion:
kubectl 0.17.0: curl http://localhost:8080/api/v1beta3/minions { "kind": "Status", "apiVersion": "v1beta3", "metadata": {}, "status": "Failure", "message": "the server could not find the requested resource", "reason": "NotFound", "details": {}, "code": 404 } master3 core # /opt/bin/kubectl get mi master3 core # kubectl 0.16.0: uses: http://localhost:8080/api/v1beta1/minions master3 core # ./kubectl get mi NAME LABELS STATUS 192.168.10.70 <noneReady 192.168.10.71 <noneReady in the same time curl http://localhost:8080/api/v1beta3/nodes works well.
Shall we just remove "minion" from kubectl now and throw an error?
remove "minions"?
Yes, that should be part of . cc
Presumably works?
Assigning who's working on
Ref
Could you please take a look at this?

I know that you can get nodes / a node, but the help doesn't say you can or provide examples: To resolve this issue: the help for this command to include nodes (and any other resources we're missing). we generate the help text in a way that ensures this (and probably the many others that are drifting) don't get out of date? Or at least give us a heuristic as to whether this might be true, even if we have to fix it manually?
Can this be closed?
I'll close this one with ; we want to get rid of the minions (mi) resource name, since it doesn't work for v1beta3.
Change:
// TODO (vladimirvivien) would be nice to name socket with a .sock extension // for consistency. csiAddrTemplate = "/var/lib/kubelet/plugins/%v/csi.sock" <del> csiTimeout      = 15 * time.Second </del> <ins> csiTimeout      = 2 * time.Minute </ins> volNameSep      = "^" volDataFileName = "vol_data.json" fsTypeBlockName = "block"

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: attach/WaitForAttach timeout value is too small in CSI driver, it's all 15s which is really too small: Compared to built-in driver timeout, it's really too small: is , total is 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 ): 1.13 - 1.15 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 storage /assign
Change:
} // NewNetLinkHandle will create an EmptyHandle <del> func NewNetLinkHandle() NetLinkHandle { </del> <ins> func NewNetLinkHandle(ipv6 bool) NetLinkHandle { </ins> return &emptyHandle{} }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /area ipv6 /area ipvs /sig network What happened: In an ipv6-only cluster with proxy-mode=ipvs the entries for NodePort in ipvs are created for ipv4 addresses. The target's (if there are any) consists of ipv6 addresses (wrongly) interpreted as ipv4; Attempts to use the NodePort with ipv6 addresses are black-holed. What you expected to happen: Ipv6 addresses to the nodes should be used for NotePort and the LB-targets shall be the ipv6 address of the pods. Traffic to NodePorts shall be distributed among the (ipv6) endpoints. How to reproduce it (as minimally and precisely as possible): Setup an ipv6-only cluster Create a service with type with endpoints Try to connect to the NodePort Do Anything else we need to know?: The nodes have both ipv4 and ipv6 addresses and it is possible that if the nodes only had ipv6 addresses it would work (I havn't tested). But even in an ipv6-only k8s cluster the nodes almost always need ipv4 addresses for other purposes. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Kvm VMs on Ubuntu 18.04.01 LTS OS (e.g. from /etc/os-release): Own BusyBox based system Kernel (e.g. ):Install tools: None Others:
The NodeIPs() function seem to return only ipv4 addresses.
I can't see why (yet) since is used in the GetLocalAddresses function
/cc Please give a hint before I dive into the netlink code.
This issue is used as an example here;
The functions filters on Src != nil . But ipv6 addresses seems to have Src == nil always. As it is this function will never return any ipv6 addresses.
Change:
} }, }, <ins> { name: "caKeyPresent-false for v1.11.3", cfg: &kubeadmapi.InitConfiguration{ APIEndpoint: kubeadmapi.APIEndpoint{AdvertiseAddress: "1.2.3.4"}, ClusterConfiguration: kubeadmapi.ClusterConfiguration{ KubernetesVersion: "v1.11.3", Networking:        kubeadmapi.Networking{ServiceSubnet: "10.96.0.0/12", DNSDomain: "cluster.local"}, }, }, caKeyPresent: false, expectedArgFunc: func(tmpdir string) []string { return []string{ "kube-controller-manager", "--address=127.0.0.1", "--leader-elect=true", "--kubeconfig=" + kubeadmconstants.KubernetesDir + "/controller-manager.conf", "--root-ca-file=" + tmpdir + "/ca.crt", "--service-account-private-key-file=" + tmpdir + "/sa.key", "--cluster-signing-cert-file=", "--cluster-signing-key-file=", "--use-service-account-credentials=true", "--controllers=*,bootstrapsigner,tokencleaner", } }, }, { name: "caKeyPresent true for v1.11.3", cfg: &kubeadmapi.InitConfiguration{ APIEndpoint: kubeadmapi.APIEndpoint{AdvertiseAddress: "1.2.3.4"}, ClusterConfiguration: kubeadmapi.ClusterConfiguration{ KubernetesVersion: "v1.11.3", Networking:        kubeadmapi.Networking{ServiceSubnet: "10.96.0.0/12", DNSDomain: "cluster.local"}, }, }, caKeyPresent: true, expectedArgFunc: func(tmpdir string) []string { return []string{ "kube-controller-manager", "--address=127.0.0.1", "--leader-elect=true", "--kubeconfig=" + kubeadmconstants.KubernetesDir + "/controller-manager.conf", "--root-ca-file=" + tmpdir + "/ca.crt", "--service-account-private-key-file=" + tmpdir + "/sa.key", "--cluster-signing-cert-file=" + tmpdir + "/ca.crt", "--cluster-signing-key-file=" + tmpdir + "/ca.key", "--use-service-account-credentials=true", "--controllers=*,bootstrapsigner,tokencleaner", } }, }, </ins> } for _, test := range tests {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When I use kubeadm to create an old version k8s cluster, the controller manager pod can not work well. The command like this : "kubeadm init --kubernetes-version=v1.11.2" The error of kube controller manager pod like this : What you expected to happen: The controller manager pod can work well. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.12.0 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): CentOS 7 Kernel (e.g. ): Install tools: kubeadm 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
/remove-sig contributor-experience /area kubeadm
Please, use when filing kubeadm issues. /sig cluster-lifecycle
OK, thank you for reminding me.
Change:
fakeClient := fake.NewSimpleClientset(objs...) informerFactory := informers.NewSharedInformerFactory(fakeClient, 0) eventBroadcaster := events.NewBroadcaster(&events.EventSinkImpl{Interface: fakeClient.EventsV1()}) <ins> defer eventBroadcaster.Shutdown() </ins> eventRecorder := eventBroadcaster.NewRecorder(scheme.Scheme, fakePermit) outOfTreeRegistry := frameworkruntime.Registry{ fakePermit: newFakePermitPlugin(eventRecorder), } <del> _, ctx := ktesting.NewTestContext(t) ctx, cancel := context.WithCancel(ctx) defer cancel() </del> <ins> tCtx := utiltesting.Init(t) </ins> scheduler, err := New( <del> ctx, </del> <ins> tCtx, </ins> fakeClient, informerFactory, nil,

Discussion:
/kind failing-test /kind flake First seen in an unrelated PR, but also occurs in periodic jobs. /sig scheduling
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
/assign This feature is reverted once, and I fixed the flake, I'm cherry-pick that back again.
Change:
"k8s.io/kubernetes/pkg/api/meta" "k8s.io/kubernetes/pkg/kubectl" <ins> "k8s.io/kubernetes/pkg/kubectl/resource" </ins> "k8s.io/kubernetes/pkg/runtime/schema" "github.com/spf13/cobra"

Discussion:
What happened: What you expected to happen: yaml output How to reproduce it (as minimally and precisely as possible): Anything else do we need to know: Related PR
Change:
tcpCloseWaitTimeout: 10s tcpEstablishedTimeout: 20s featureGates: "all" <del> healthzBindAddress: 1.2.3.4:12345 </del> <ins> healthzBindAddress: "%s" </ins> hostnameOverride: "foo" iptables: masqueradeAll: true

Discussion:
Is this a request for help? No. What keywords did you search in Kubernetes issues before filing this one? is:issue is:open ipv6 Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST Kubernetes version (use ): N/A, these are unit test changes in latest master Environment: Cloud provider or hardware configuration: Kubernetes container dev env on Ubuntu 16.04.1 OS (e.g. from /etc/os-release): Ubuntu 16.04.1 Kernel (e.g. ): 4.4.0-78-generic -Ubuntu x8664 GNU/Linux Install tools: Others: What happened: Upon inspection, no IPv6 test cases found in kubernetes/cmd/kube- What you expected to happen: Expect to see some IPv6 test cases exercised for kube-proxy server code (kubernetes/cmd/kube-). Also need some code coverage for negative conditions in How to reproduce it (as minimally and precisely as possible): Run unit tests in kubernetes/cmd/kube- Anything else we need to know:
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig networking
/area ipv6
/sig network
Change:
<ins> #!/bin/bash # Copyright 2014 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. # Cleans up resources from the example, assumed to be run from Kubernetes repo root export OPENSHIFT_EXAMPLE=$(pwd)/examples/openshift-origin export OPENSHIFT_CONFIG=${OPENSHIFT_EXAMPLE}/config rm -fr ${OPENSHIFT_CONFIG} cluster/kubectl.sh delete secrets openshift-config cluster/kubectl.sh stop rc openshift cluster/kubectl.sh delete rc openshift cluster/kubectl.sh delete services openshift </ins>

Discussion:
This PR was prematurely merged: Need to update the PR based on the actual steps that were needed to get what was demonstrated at the public Kubernetes meet-up last week.
Any chance you can get rid of the hostPort from the example?
- depending on the Kubernetes provider, yes. For Vagrant based provider, I think I still need the hostPort because I do not have routes. For the GCE provider, I should be able to get rid of it because I have routes. In both providers, there were a number of setup steps that did not make the merged PR. For those that are tracking this issue (which I know folks have pinged me on separately) needs to be configured to allow privelaged containers needs to be configured to allow pushing to an insecure registry (this is point in time) Ideally, I could use a ReplicationController in the example to load balance OpenShift, but until we can provide a pattern to run etcd as a pod, I am unable to do this and need to use the embedded etcd we end up running.
Note: I will resolve this issue in 2 phases. Vagrant (which was demonstrated) to document using GCE (which has some additional steps on firewall rules)
Turns out OpenShift Origin is too secure now ;-) This is blocked until OpenShift Origin allows you to mint certs on the client, and then supply the certs on startup as a secret to the pod. This feature is coming soon. /cc
I now have all the required pieces to get this to work. I hope to get a PR submitted to fix this issue by end of this week.