jiebi/CodeConvo huggingface dataset:
Change:
return } <del> podChanged := podAddressChanged(oldPod, newPod) </del> <ins> podChangedFlag := podChanged(oldPod, newPod) </ins> // Check if the pod labels have changed, indicating a possibe // change in the service membership

Discussion:
This test has started failing on our e2e test suite, erroring out with "Failed to get endpoints..." https://k8s- https://k8s- Example failures https://k8s- https://k8s- cc cc
This may be related to our recently-merged endpoints change in . I'll look into it.
I verified that the flakiness introduced was a result of . A fix in should be merging soon. /assign
GitHub didn't allow me to assign the following users: joelsmith. Note that only can be assigned. <detailsIn response to : I verified that the flakiness introduced was a result of . A fix in should be merging soon. /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
// underlying storage will be destroyed on this servers shutdown. func (s *GenericAPIServer) InstallAPIGroups(apiGroupInfos ...*APIGroupInfo) error { for _, apiGroupInfo := range apiGroupInfos { <ins> if len(apiGroupInfo.PrioritizedVersions) == 0 { return fmt.Errorf("no version priority set for %#v", *apiGroupInfo) } </ins> // Do not register empty group or empty version.  Doing so claims /apis/ for the wrong entity to be returned. // Catching these here places the error  much closer to its origin if len(apiGroupInfo.PrioritizedVersions[0].Group) == 0 {

Discussion:
I met a panic in apiserver package when I create an aggregated API. not panic Do not call No response <details</details<details</details<details</details<details</details<details</details<details</details
Reference PR to fix:
/sig api-machinery
/cc /triage accepted
Change:
lateBinding:    test.lateBinding, enableTopology: test.topology, <del> // Not strictly necessary, but without it, the external-attacher takes two minutes to detach // the volume?! Looks like a bug. </del> <ins> // Not strictly necessary, but runs a bit faster this way // and for a while there also was a problem with a two minuted delay // due to a bug (https://github.com/kubernetes-csi/csi-test/pull/250). </ins> disableAttach:  true, registerDriver: true, }

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: Which test(s) are flaking: CSI mock volume storage capacity exhausted, late binding, with topology Testgrid link: Reason for failure: Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated
/assign
According to , there really are extra calls to and that shouldn't be there: The current theory is that this might be related to kubelet assuming that a CSI driver does real mounts, something that the mock driver (and potentially other) CSI drivers don't do. A fix for that is pending in That this test runs into this randomly is caused by the test doing more strict checking of CSI calls than other tests. The flaky test failures could be avoided by relaxing that checking, but that won't fix the underlying issue.
I'm not sure I would pin it on the mount check yet. The broader question is why is MountVolume() getting called twice after the first one returns success.
is it due that, the timeout of CSI transaction or call is very low where CSI driver takes more time than this timeout?
Change:
RegisterFakeList("namespaces", &cluster2Client.Fake, &api_v1.NamespaceList{Items: []api_v1.Namespace{}}) cluster2CreateChan := RegisterFakeCopyOnCreate("namespaces", &cluster2Client.Fake, cluster2Watch) <ins> RegisterFakeList("replicasets", &fakeClient.Fake, &extensionsv1.ReplicaSetList{Items: []extensionsv1.ReplicaSet{ { ObjectMeta: api_v1.ObjectMeta{ Name:      "test-rs", Namespace: ns1.Namespace, }}}}) RegisterFakeList("secrets", &fakeClient.Fake, &api_v1.SecretList{Items: []api_v1.Secret{ { ObjectMeta: api_v1.ObjectMeta{ Name:      "test-secret", Namespace: ns1.Namespace, }}}}) RegisterFakeList("services", &fakeClient.Fake, &api_v1.ServiceList{Items: []api_v1.Service{ { ObjectMeta: api_v1.ObjectMeta{ Name:      "test-service", Namespace: ns1.Namespace, }}}}) nsDeleteChan := RegisterDelete(&fakeClient.Fake, "namespaces") rsDeleteChan := RegisterDeleteCollection(&fakeClient.Fake, "replicasets") serviceDeleteChan := RegisterDeleteCollection(&fakeClient.Fake, "services") secretDeleteChan := RegisterDeleteCollection(&fakeClient.Fake, "secrets") </ins> namespaceController := NewNamespaceController(fakeClient) informer := ToFederatedInformerForTestOnly(namespaceController.namespaceFederatedInformer) informer.SetClientFactory(func(cluster *federation_api.Cluster) (kube_release_1_4.Interface, error) {

Discussion:
In PR the specific resource types are handled explicitly. Need to delete them in more generic way, in a similar way that namespace controller does.
- switching this to 1.6 as it's too late for 1.5. ok? (please switch it right back if you disagree)
did fix this?
Please close or move to next-candidate with work remaining to be done.
Yes fixed by
Change:
Filter: &schedulerapi.PluginSet{ Enabled: []schedulerapi.Plugin{ {Name: nodeunschedulable.Name}, <del> {Name: noderesources.FitName}, </del> {Name: nodename.Name}, <del> {Name: nodeports.Name}, </del> <ins> {Name: tainttoleration.Name}, </ins> {Name: nodeaffinity.Name}, <ins> {Name: nodeports.Name}, {Name: noderesources.FitName}, </ins> {Name: volumerestrictions.Name}, <del> {Name: tainttoleration.Name}, </del> {Name: nodevolumelimits.EBSName}, {Name: nodevolumelimits.GCEPDName}, {Name: nodevolumelimits.CSIName},

Discussion:
Inspired from Our default Filter plugins have the following order: IIUC, this order was chosen to have the fastest Filters or the most probability of reporting Unschedulable first. Arguably, some are pretty much equivalent and could be reordered. The major problem with this order is that plugin is almost at the beginning. This plugin only reports . A Node that fails this plugin will be evaluated during preemption. But perhaps this Node doesn't satisfy other UnschedulabeAndUnresolvable requirements (taints, node selectors, nodeaffinity). Theoretically, having those Filters run first could improve preemption latency. The only open question is whether or not the ordering we have today is an API guarantee. I believe it's not (at least in component config), because the only way to change the ordering of Plugins is disabling all of them first. Decided order: /sig scheduling
for comment
and :)
Even we changed the order of plugins, the framework.RunFilterPlugins still exits early when returned by plugin. So should we change the current behavior to run the filter plugins until there is one plugin returned ?
That is correct, and that's what it should be.
No, that's what the original conversation suggested and it's likely not ideal in the average case.
+1 to reordering. Taints, affinity, node name can all be executed before checking for resource fit. No, it is not.
+1. Lightweight plugins that may return status can be moved ahead of other plugins that only return status.
FYI: from who also had this concern: So how about , is it also a good candidate to be moved ahead of ? NodeAffinity and NodeSelector both incorporated in , I'm pretty sure NodeSelector logic is simply, but not 100% sure NodeAffinity logic falls into the category of "lightweight".
Let me propose an order, for extra clarity:
internally composes and invokes , which IMO is a bit more expensive than . should be cheaper than . So my 2 cents is:
Both proposals are fine by me.
/triage accepted /help /good-first-issue
/assign
I want to help here :)
/remove-help
Change:
valueFrom: fieldRef: fieldPath: metadata.namespace <del> image: gcr.io/google_containers/cassandra:v4 </del> <ins> image: gcr.io/google_containers/cassandra:v5 </ins> name: cassandra ports: - containerPort: 9042

Discussion:
The namespace seems to be hard coded :
cc:
Thanks. We can improve it after v1 release.
Change:
"//cmd/kubeadm/app/util/staticpod:go_default_library", "//pkg/kubeapiserver/authorizer/modes:go_default_library", "//pkg/master/reconcilers:go_default_library", <ins> "//pkg/util/pointer:go_default_library", </ins> "//pkg/util/version:go_default_library", "//vendor/k8s.io/api/core/v1:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/sets:go_default_library",

Discussion:
Dear All: I'm not sure if I'm right. When i use whith .I found controller-manager logs Someone can help me? Thanks a lot.
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
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
Please give more information about your set up cc
Sorry for report later. My openstack didn't support metadata service,but support config-drive service. More info:
Thanks Based on this, I think it's an openstack cloudprovider problem more than a kubeadm problem...
Thank you for help me. I will change the label.
/area cloudprovider
/remove-kind support
Should be fixed with you can specify a search order for metadata and config drive /close
Specifying a search order doesn't really solve the problem, especially if the metadata api isn't available which is what ZhenyangZhao said . I'm getting the same issue and since the config drive is my only option at the moment.
Like for this to be /open
can you please provide logs/versions for your problem in your environment? Thanks, Dims
Let me know if you need anything else Kubernetes version: 1.8.4 Docker version: 17.09.0-ce Linux: CentOS 7.4 Looking at the docker container log for the api-server (I don't have problems with the controller-manager):
and share the following:
Hi! Thank you for filing this issue. We appreciate your interest in Kubernetes and kubeadm. In order to make the kubernetes/kubernetes issue tracker more usable, we're routing issues to different repositories with different focuses. I think this issue belongs in the kubeadm repository. Please move this issue to the in order for the kubeadm team to be able to track this efficiently. If you disagree with my assessment of moving this issue, please speak up and/or reopen the issue. Finally, please try to reproduce the bug with the latest Kubernetes version, it might as well already have been fixed :) Thank you and have a good day!
Change:
// the underlying connection (like WebSocket or HTTP2 clients). Pure HTTP clients should use // the higher level TransportFor or RESTClientFor methods. func HTTPWrappersForConfig(config *Config, rt http.RoundTripper) (http.RoundTripper, error) { <del> cfg, err := config.transportConfig() </del> <ins> cfg, err := config.TransportConfig() </ins> if err != nil { return nil, err } return transport.HTTPWrappersForConfig(cfg, rt) } <del> // transportConfig converts a client config to an appropriate transport config. func (c *Config) transportConfig() (*transport.Config, error) { </del> <ins> // TransportConfig converts a client config to an appropriate transport config. func (c *Config) TransportConfig() (*transport.Config, error) { </ins> wt := c.WrapTransport if c.AuthProvider != nil { provider, err := GetAuthProvider(c.Host, c.AuthProvider, c.AuthConfigPersister)

Discussion:
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
We understand the problem here - I'm working on the fix.
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
Change:
"v1.PodAffinityTerm": { "id": "v1.PodAffinityTerm", "description": "Defines a set of pods (namely those matching the labelSelector relative to the given namespace(s)) that this pod should be co-located (affinity) or not co-located (anti-affinity) with, where co-located is defined as running on a node whose value of the label with key u003ctopologyKeyu003e matches that of any node on which a pod of the set of pods is running", <ins> "required": [ "topologyKey" ], </ins> "properties": { "labelSelector": { "$ref": "v1.LabelSelector",

Discussion:
The field is marked as optional: The comment also describes a use case for empty topologykey: But the validation rule says it's required:
cc
cc could you take a look? Thank you. The validation rule is by
the release note of should go into the "action-required" section of the , but it's currently in "Other notable changes".
/assign
It seems that we should also update the external api type comments. Right?
I will look into it today.
If you didn't work on this, I am pleasure to send PR to fix this. :)
yeah sure. thanks.
Change:
"fmt" "io" "io/ioutil" <ins> "os" </ins> "strings" "github.com/golang/glog"

Discussion:
Kubernetes version v1.3.0 Kubelet concatenates host and cluster domain entries for my pod, resulting in an invalid config (too many entries with duplicates). The max is only 6 search domains. Any more and DNS resolution breaks when trying to leverage search domains. The example below has only cluster DNS entries, but illustrates the issue: Host search nameserver 10.233.0.2 nameserver 10.90.0.1 options timeout:2 options attempts:2 Container kubectl run -i --tty busybox --image=busybox -- sh (skip waiting text) / # cat search nameserver 10.233.0.2 options attempts:2 options ndots:5 I should be enable cluster DNS config in my host DNS settings and still have functional pod DNS. Kubelet should be intelligent enough to filter out duplicate search domain entries (or drop search domains beyond the 6th entry)
I think some sane checks needs to be too. libc limits search field to 6 records and 255(?) characters. This limitation should be checked before creation.
Hey guys, I'm working on it.
Dup of
Change:
if err != nil { return err } <del> return pprof.StartCPUProfile(f) </del> <ins> err = pprof.StartCPUProfile(f) if err != nil { return err } </ins> // Block and mutex profiles need a call to Set{Block,Mutex}ProfileRate to // output anything. We choose to sample all events. case "block": runtime.SetBlockProfileRate(1) <del> return nil </del> case "mutex": runtime.SetMutexProfileFraction(1) <del> return nil </del> default: // Check the profile name is valid. if profile := pprof.Lookup(profileName); profile == nil {

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: While investigating I've found that kubectl doesn't handle sigterm with profiling. This way, when profiling a long run command (as wait, drain, etc) and interrupting the command in the middle (ctrl-c, as an example) the profile file is not available. What you expected to happen: Profiling file exists if the command exists correctly or if the command is interrupted with ctrl-c How to reproduce it (as minimally and precisely as possible): Execute a long run command (as kubectl drain, kubectl wait) with --profile=cpu and then interrupt the command before it finishes the execution Anything else we need to know?: Because kubectl deals with errors with an util (cmdutil.CheckErr) that in some specific time exists with os.Exit(1), it's not possible yet to also profile programs that exits. Environment: Kubernetes version (use ): kubectl compiled from upstream Cloud provider or hardware configuration: OS (e.g: ): Ubuntu 20.04
/sig cli /assign
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
Change:
"k8s.io/kubernetes/pkg/kubelet/token" kubetypes "k8s.io/kubernetes/pkg/kubelet/types" "k8s.io/kubernetes/pkg/kubelet/userns" <ins> "k8s.io/kubernetes/pkg/kubelet/userns/inuserns" </ins> "k8s.io/kubernetes/pkg/kubelet/util" "k8s.io/kubernetes/pkg/kubelet/util/manager" "k8s.io/kubernetes/pkg/kubelet/util/queue"

Discussion:
is no longer compilable on macOS in the master branch. It was compilable with Kubernetes v1.29.0 and v1.30.0-alpha.0. It should be compilable. No response <detailsmaster () (This is just the latest commit, not the commit that introduced the regression) </details<detailsN/A </details<detailsmacOS 14.2.1 (Intel) </details<detailsN/A </details<detailsN/A </details<detailsN/A </details
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 testing
Regression in:
Change:
}, }, }, <ins> { accept: runtime.ContentTypeJSON + ";as=Table;v=v1alpha1;g=meta.k8s.io", params: url.Values{"includeObject": []string{"Metadata"}}, expected: &metav1alpha1.Table{ TypeMeta: metav1.TypeMeta{Kind: "Table", APIVersion: "meta.k8s.io/v1alpha1"}, ColumnDefinitions: []metav1alpha1.TableColumnDefinition{ {Name: "Name", Type: "string", Description: metaDoc["name"]}, {Name: "Created At", Type: "date", Description: metaDoc["creationTimestamp"]}, }, Rows: []metav1alpha1.TableRow{ {Cells: []interface{}{"foo1", now.Time.UTC().Format(time.RFC3339)}, Object: runtime.RawExtension{Raw: encodedBody}}, }, }, }, </ins> } for i, test := range tests { u, err := url.Parse(server.URL + "/" + prefix + "/" + testGroupVersion.Group + "/" + testGroupVersion.Version + "/namespaces/default/simple/id")

Discussion:
Making an API request for table output and specifying the parameter causes a server error in parameter conversion, and an inaccurate error message in response: server log: E0804 09:41:14. ] apiserver received an error that is not an metav1.Status: converting (url.Values).[]string to (v1alpha1.TableOptions).v1alpha1.IncludeObjectPolicy: couldn't copy '[]string' into 'v1alpha1.IncludeObjectPolicy'; didn't understand types
Ugh, typed strings.
Change:
"github.com/Azure/azure-sdk-for-go/services/network/mgmt/2017-09-01/network" "github.com/Azure/go-autorest/autorest" "github.com/golang/glog" "k8s.io/apimachinery/pkg/types" cloudprovider "k8s.io/cloud-provider" )

Discussion:
<!-- 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?: /kind bug What happened: When creating a Kubernetes 1.12.1 cluster in Azure with Availability Set backed masters and VMSS backed agents, the cloud-controller-manager is unable to parse the ProviderID returned by the Azure SDK. What you expected to happen: The providerID should be split and the cloud-controller-manager should be able to find a kubelet node IP from the cloud provider How to reproduce it (as minimally and precisely as possible): Stand up a master node in Azure within an availability set with the kubelet configured with Run the configured for Azure Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Azure OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig azure
When switching over to vmType the following was encountered;
The fix in resolved the issue that was seen in this issue, closing
Change:
# Automatically detect swift url if it wasn't specified if [[ -z $SWIFT_SERVER_URL ]]; then <del> SWIFT_SERVER_URL=$(openstack catalog show object-store --format value | egrep -o "publicURL: (.+)$" | cut -d" " -f2) </del> <ins> local rgx="" if [ "$OS_IDENTITY_API_VERSION" = "3" ]; then rgx="public: (.+)$" else rgx="publicURL: (.+)$" fi SWIFT_SERVER_URL=$(openstack catalog show object-store --format value | egrep -o "$rgx" | cut -d" " -f2) </ins> fi local swift_repo_url="${SWIFT_SERVER_URL}/kubernetes"

Discussion:
Kubernetes version (use ): Environment: Cloud provider or hardware configuration: Internal OpenStack cloud OS (e.g. from /etc/os-release): OS X 10.10.5 Kernel (e.g. ): Darwin Sean-Collins- 14.5.0 Darwin Kernel Version 14.5.0: Sun Sep 25 22:07:15 PDT 2016; root:xnu-2782.50.9~1/RELEASEX8664 x86_64 Install tools: Others: What happened: kube- failed to create the heat stack KubernetesStack, and exited What you expected to happen: Create the stack KubernetesStack and continue onward How to reproduce it (as minimally and precisely as possible): See above console output Anything else do we need to know:
My suspicion is that the behavior of and the command has changed recently when
Nope, it actually looks like it's the (kubernetes)scollins ~/src/k8s/kubernetes ±swiftuploadcache » openstack catalog show object-store +-----------+
--------+ +-----------+
--------+ +-----------+
--------+ (kubernetes)scollins ~/src/k8s/kubernetes ±swiftuploadcache » openstack catalog show object-store --format value cut -d" " -f2 (kubernetes)scollins ~/src/k8s/kubernetes ±swiftuploadcache »
I'll need to check to see if the change from to is a server side change from OpenStack Keystone, or a change in , or is something that is deployed incorrectly in this environment
So, at least according to the , endpoints have an - which can be , , or - never
Yeah, so is from the
Change:
"//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/types:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", <ins> "//staging/src/k8s.io/client-go/kubernetes/fake:go_default_library", </ins> "//staging/src/k8s.io/cloud-provider/volume:go_default_library", "//vendor/github.com/aws/aws-sdk-go/aws:go_default_library", "//vendor/github.com/aws/aws-sdk-go/service/ec2:go_default_library",

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: We have pretty large clusters in aws and in production, we found an inefficiency in provisioning dynamic EBS volumes, where aws-ebs volume provisioner tries to look for available zone from aws directly. With scale, this can trigger massive from ec2, and affect cluster stability. This is also related to What you expected to happen: To simply get zones with available instances, we can get information from API server for efficiency. There might be a delay between node gets shutting down and such change is reflected in api server, but in case node is not ready or gets terminated, there will be higher level reconciliation triggered so we are safe. How to reproduce it (as minimally and precisely as possible): We only expect this to be hit when the cluster is huge (or aws account is huge) so not easy to reproduce. /assign /sig aws /sig cloud-provider
/assign