jiebi/CodeConvo huggingface dataset:
Change:
--public-ip="": Name of a public IP address to set for the service. The service will be assigned this IP in addition to its generated service IP. --selector="": A label selector to use for this service. If empty (the default) infer the selector from the replication controller. --service-name="": The name for the newly created service. <del> -t, --template="": Template string or path to template file to use when -o=template or -o=templatefile. </del> <ins> -t, --template="": Template string or path to template file to use when -o=template or -o=templatefile.  The template format is golang templates [http://golang.org/pkg/text/template/#pkg-overview] </ins> Global Flags: --alsologtostderr=false: log to standard error as well as files

Discussion:
periodic-conformance-main-k8s-main Kubernetes e2e suite.SynchronizedBeforeSuite 07/17 23:52PDT We saw a similar issue in , which was fixed by upgrading the control plane OS from Ubuntu 18.04 to 22.04. /sig cluster-lifecycle
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 /cc
/sig node It seems to be related to SWAP.
There is a bug in containerd that is fixed in v1.6.14. The test here is using v1.6.8. Kubernetes v1.27 supported containerd versions: 1.7.0+, 1.6.15+
/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
Still failing after is merged. Have we tried bumping the control plane OS image to ubuntu 22.04, like ?
Nevermind, the latest testgrid job might have been triggered before the PR was merged. I am observing this and will close this once I see the job passes.
Containerd version is already v1.6.21 in 's log There maybe still other problems.
can fix a similar failure in .
/close The failure of the swap is fixed by . The current failure is a flake that is mentioned in
Closing this issue. <detailsIn response to : /close The current failure is a flake that is mentioned in 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:
klog.Errorf("Error preempting pod %v/%v: %v", victim.Namespace, victim.Name, err) return "", err } <ins> // If the victim is a WaitingPod, send a reject message to the PermitPlugin if waitingPod := fwk.GetWaitingPod(victim.UID); waitingPod != nil { waitingPod.Reject("preempted") } </ins> sched.config.Recorder.Eventf(victim, preemptor, v1.EventTypeNormal, "Preempted", "Preempting", "Preempted by %v/%v on node %v", preemptor.Namespace, preemptor.Name, nodeName) }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : When preempting a pod that is a that permit plugins are waiting for , we need send a message(actually send a ) to the , otherwise permit plugins might wait until time out, and do not know the pod has been preempted. Why is this needed: /sig scheduling /kind cleanup /assign
cc
Interesting interaction between the permit and preempt, I will take a look at the PR you sent, thanks!
Change:
cfg := credentialprovider.DockerConfig{} if a.config.UseManagedIdentityExtension { <del> if loginServer := parseACRLoginServerFromImage(image); loginServer == "" { </del> <ins> if loginServer := a.parseACRLoginServerFromImage(image); loginServer == "" { </ins> klog.V(4).Infof("image(%s) is not from ACR, skip MSI authentication", image) } else { if cred, err := getACRDockerEntryFromARMToken(a, loginServer); err == nil {

Discussion:
What happened: An aks-engine cluster with a user assigned managed service cluster identity fails to authenticate to azure container registries in private clouds when the proper (acrpull) azure role assignments are in place and when there are no image pull secrets. What you expected to happen: The cluster should be able to authenticate and pull from an ACR hosted in the same azure cloud without needing additional pull secrets when the cluster identity has the proper acrpull azure role assignment, no matter which azure cloud it is operating in. How to reproduce it (as minimally and precisely as possible): Assume you have a private azure cloud where every url ends with "". That would mean the ACR suffix would be . Let's pretend you have an ACR at and you try to deploy a pod in your cluster referencing the image . This will fail to pull when you have no image pull secrets. Anything else we need to know?: The problem stems from the following lines where expected ACR suffix domains are hardcoded: Environment: Kubernetes version (use ): 1.16.9 Cloud provider or hardware configuration: Azure private OS: ubuntu 16.0.4 Network plugin and version: Azure CNI
/sig provider-azure
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig provider-azure 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
/area provider/azure /sig cloud-provider
It looks like we may be able to obtain the acr suffix from the azure environment:
there is a security issue here: if we support self defined ACR domain, e.g. , then service principal secret could be sent to that remote server. The reason why we use hardcoded domains is that we could always make sure the following 4 domains are owned by Azure:
Change:
} if len(ui.Extra) > 0 { <del> for k, v := range ui.Extra { </del> <ins> sortedKeys := make([]string, 0, len(ui.Extra)) for k := range ui.Extra { sortedKeys = append(sortedKeys, k) } sort.Strings(sortedKeys) for _, k := range sortedKeys { v := ui.Extra[k] </ins> _, err := fmt.Fprintf(w, "Extra: %st%vn", k, v) if err != nil { return fmt.Errorf("cannot write an extra: %w", err)

Discussion:
Unit tests failed with , see TestWhoAmIRun/successtest None No response No response_ /sig cli
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 cli
I think it was caused by
When we loop the golang Map, it's unordered.
I can work on this one.
Thanks.
/priority critical-urgent this is impacting CI,
Change:
KubeletPodResources:            {Default: true, PreRelease: featuregate.Beta}, WindowsGMSA:                    {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.20 WindowsRunAsUserName:           {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.20 <del> ServiceLoadBalancerFinalizer:   {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, </del> LocalStorageCapacityIsolationFSQuotaMonitoring: {Default: false, PreRelease: featuregate.Alpha}, NonPreemptingPriority:                          {Default: true, PreRelease: featuregate.Beta}, VolumePVCDataSource:                            {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.20

Discussion:
When should it be removed? /sig network /kind cleanup
It was GAed in 1.17 and should have been removed in 1.18. I will send a PR to remove it retrospectively. /assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
I know a new-contributor looking for good-first-issues. Do you mind if I cc him on this issue since it seems pretty straightforward ?
That sounds perfect, thanks!
cc
I am still planning on working on this, I am just having some dev environment issues I am hoping to resolve in the next few days. I'll update again when I get them resolved.
Hey, just a quick update. I have been fairly busy and am going on vacation next week. I AM still planning on working on this, however since I am obviously very slow if someone comes along and wants to work on this feel free. Just please comment that you will work on it so I know :).
Change:
return nil, fmt.Errorf("failed to fetch the objectType: %v", err) } result := &unstructured.Unstructured{} <del> err = managedfields.ExtractInto(object, *objectType, fieldManager, result, subresource) </del> <ins> err = managedfields.ExtractInto(object, *objectType, fieldManager, result, subresource) //nolint:forbidigo </ins> if err != nil { return nil, fmt.Errorf("failed calling ExtractInto for unstructured: %v", err) }

Discussion:
Add a code static check for to report using server-side-apply extract With optimization of and , the will be removed in and , and maybe more of other components in the future, using Extract is problematic. It's safer to add this lint check.
/cc
/sig api-machinery
/sig scheduling /sig apps
/assign /triage accepted
Change:
pvNamePrefix := ns + "-" pvHostPathConfig := e2epv.PersistentVolumeConfig{ <del> NamePrefix: pvNamePrefix, Labels:     volLabel, </del> <ins> NamePrefix:       pvNamePrefix, Labels:           volLabel, StorageClassName: ns, </ins> PVSource: v1.PersistentVolumeSource{ CSI: &v1.CSIPersistentVolumeSource{ Driver:       csiDriver.Name,

Discussion:
master-informing: ! Last 2 runs failed consecutively, first failure: No response /sig storage
/cc
I will take a look this week.
/triage accepted
/assign
Change:
func TestConfigChange(t *testing.T) { setUp := func() (*os.File, string, error) { <del> tempDir := os.TempDir() file, err := ioutil.TempFile(tempDir, "kube-proxy-config-") </del> <ins> tempDir, err := ioutil.TempDir("", "kubeproxy-config-change") if err != nil { return nil, "", fmt.Errorf("Unable to create temporary directory: %v", err) } fullPath := filepath.Join(tempDir, "kube-proxy-config") file, err := os.Create(fullPath) </ins> if err != nil { return nil, "", fmt.Errorf("unexpected error when creating temp file: %v", err) }

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!--What happened: make test is failing due to build failure What you expected to happen: make test should be successful How to reproduce it (as minimally and precisely as possible): clone kubenetes git and run make test Anything else we need to know?: Environment: OS (e.g. from /etc/os-release):Kernel (e.g. ): GO Version: Other:
/sig testing
does help? are you out of space or have write permission problems in your /tmp directory?
this is happening in a clean environment and I hope got enough disk space! do you see golang/linker issues here?
All I see are missing files, not linker errors.
found the culprit, @ test is deleting the which is actually a - which is removing some of the files which are created by go compile process and failing because of this. Other places in kubernetes used and same logic needs to be used here as well.
good catch. yeah, each test should make its own tmp dir with . can you open a PR sweeping for that?
Just wanted to confirm I'm also experiencing the same build failure on HEAD ().
yes, will be out soon for review.
here is the PR to fix this issue -
Change:
By("verifying pod deletion was observed") deleted := false <del> timeout := false </del> var lastPod *v1.Pod <del> timer := time.After(30 * time.Second) for !deleted && !timeout { </del> <ins> timer := time.After(2 * time.Minute) for !deleted { </ins> select { case event, _ := <-w.ResultChan(): <del> if event.Type == watch.Deleted { </del> <ins> switch event.Type { case watch.Deleted: </ins> lastPod = event.Object.(*v1.Pod) deleted = true <ins> case watch.Error: framework.Logf("received a watch error: %v", event.Object) Fail("watch closed with error") </ins> } case <-timer: <del> timeout = true </del> <ins> Fail("timed out waiting for pod deletion") </ins> } } if !deleted {

Discussion:
https://k8s-
is looking into this.
Seems like a lot of flakes are caused by the watch issue: Maybe we should switch to polling in the test.
I'm taking this
Opened a fix that will at minimum give us more info, but also increases timeout
This is the last failure before my changed merged: https://k8s- Still waiting for a post.
Do you think is enough to address this issue? Or there are some other pending issues in watching code? Can we close this one?
We can close this, the issue is almost certainly the one fixed.
Change:
"testdevice": { {ID: "Dev1"}, {ID: "Dev2"}, <ins> {ID: "Dev3", Topology: &pluginapi.TopologyInfo{Nodes: []*pluginapi.NUMANode{}}}, {ID: "Dev4", Topology: &pluginapi.TopologyInfo{Nodes: nil}}, </ins> }, }, expectedHints: map[string][]topologymanager.TopologyHint{

Discussion:
A node with: fails a pod that uses device plugin resources (empty but non-nil ) : Our device plugin sends the following registration: So we send an empty which is interpreted as "no possible NUMA affinities": How is this different from value? I can workaround the problem by sending but it's not how this is supposed to work. Can the two if's combined or should we updated the documentation? My environment: a single-node k8s cluster w/ device plugin that does The node needs to run two kinds of pods: those that need/use topology single-numa-node and pods that just use a device plugin resources that does not provide topologyhints. <details</details<detailsN/A (kubeadm single node cluster) </details<details</details<detailskubeadm </details<detailscontainerd </details<detailsintel SGX device plugin v0.24 </details
/cc
It's possible that better documentation is needed, but we could also probably do more to handle this better in the device plugin. The implementation you pointed out above relies on depicting "don't care" and depicting "I tried but couldn't generate any hints that provide alignment". One could argue though that should have generated a set of hints and not a . I would need to look at the code again to know for sure if this makes sense or not though.
This interpretation makes sense but Right, if the hint provider fails to provide hints, I guess the pod should not be blamed (by not making it to run) for that. /sig node
/triage accepted /priority backlog
/cc
I can at least help with the documentation part if we decide that it alone needs changing.
I'm reviewing this area for other reasons, we should indeed calrify the hint API expectations. Up until now my rule of thumb was pretty much "what cpumanager does" which has room for improvement.
This could be isolated to only by returning when : when running is pointless, IMO
Submitted a
The corresponding documentation update:
Change:
<ins> // +build !providerless /* Copyright 2020 The Kubernetes Authors. 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. */ // The external controller manager is responsible for running controller loops that // are cloud provider dependent. It uses the API to listen to new events on resources. package main import ( // NOTE: Importing all in-tree cloud-providers is not required when // implementing an out-of-tree cloud-provider. _ "k8s.io/legacy-cloud-providers/aws" _ "k8s.io/legacy-cloud-providers/azure" _ "k8s.io/legacy-cloud-providers/gce" _ "k8s.io/legacy-cloud-providers/openstack" _ "k8s.io/legacy-cloud-providers/vsphere" ) </ins>

Discussion:
make verify WHAT=typecheck-providerless outputs /cc /milestone v1.19
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
see example successful run:
For reference -
fix in
screaming
Change:
glog.Errorf("iscsi: failed to attach disk:Error: %s (%v)", string(out), err) return err } <del> exist = waitForPathToExist(devicePath, 10, b.iface) </del> <ins> exist = waitForPathToExist(devicePath, 10, iscsiTransport) </ins> if !exist { return errors.New("Could not attach disk: Timeout after 10s") }

Discussion:
open-iscsi software initiators are currently broken for non- interfaces due to the fact that the devicePath (in ) is assumed to use the prefixing scheme for all interfaces not named . This causes waitForPathToExist to timeout after 10 seconds since the device path that it is waiting for is not the - prefixed path that is created, resulting in host logging such as: or K8S event logs such as: open-iscsi support for hardware transports was in the following commit: In this commit, software iSCSI support was assumed to be done through only the use of the default interface. According to the documentation at (Section 5.1.1) both software and offload/hardware interfaces are intended to be configured using named interface specifications and is only a backwards-compatibility vehicle. Configuration of cannot be done via the use of as this approach is specifically forbidden in the documentation: Leaving this here to help others associate various failure modes with this issue and possible resolution: In my case I am just learning and this is my first iSCSI deployment. My initial error was that I was receiving an message at discovery-time even though I had used to define a name. This approach failed because I didn't realize that iscsid needed to be bounced before it would pick up changes to that file. I had defined a custom specification and was using that to accomplish the task of setting my initiator name. I was able to unwind this mess and return to the use of once I read the code and understood what it was attempting to do.
i'm marking this as a feature request against the iscsi volume driver. RFE: support iscsi interfaces named something besides 'default'.
In theory the fix should be easy, just move the path check from iface name to transport_name. I will take a look asap, unfortunately I am travelling till monday
Sorry about the previous comment, I was logged in to the wrong account. In theory the fix should be easy, just move the path check from iface name to transport_name. I will take a look asap, unfortunately I am travelling till monday. can you share your iface file ? It will help me validate
I no longer have the file precisely as it was. However, I did have some version of what I had used committed into my VCS. While not 100% sure this is what I was using while encountering the failure it does looks to be about what I'd expect:
Change:
w.Write(LEVEL_0, "Selector:t%sn", selector) printLabelsMultiline(w, "Labels", ps.Labels) printAnnotationsMultiline(w, "Annotations", ps.Annotations) <del> w.Write(LEVEL_0, "Replicas:t%d desired | %d totaln", ps.Spec.Replicas, ps.Status.Replicas) </del> <ins> w.Write(LEVEL_0, "Replicas:t%d desired | %d totaln", *ps.Spec.Replicas, ps.Status.Replicas) </ins> w.Write(LEVEL_0, "Update Strategy:t%sn", ps.Spec.UpdateStrategy.Type) if ps.Spec.UpdateStrategy.RollingUpdate != nil { ru := ps.Spec.UpdateStrategy.RollingUpdate

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!--/kind bug /sig cli /area kubectl What happened: What you expected to happen: Should only be one desired replica How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Right here Environment: Kubernetes version (use ):
Change:
}, fakeCloud: &fake_cloud.FakeCloud{ Machines: []string{"node0"}, <ins> ExtID: map[string]string{ "node0": "ext-node0", "node1": "ext-node1", }, </ins> }, matchRE:              ".*", expectedRequestCount: 2, // List + Delete <del> expectedCreated:      []string{}, </del> <ins> expectedNameCreated:  []string{}, expectedExtIDCreated: []string{}, </ins> expectedDeleted:      []string{"node1"}, }, {

Discussion:
I see the following in the kube-controller-manager log: - This is happening to me on HEAD and is the reason why pod status is always showing unknown even when they are scheduled and running.
This is with the vagrant cloud provider. It looks like the delta between the new and old minion is the Node.Spec.ExternalID is being set on the incoming minion but is not set in the originally created minion.
I am not sure how this is not affecting other cloud providers. It looks to me that NodeController populated the node ExternalID here: It looks like the Kubelet provided value is missing the ExternalID
Actually, I am now confused on what the NodeController may or may not be doing here that is causing the status to not get updated.
It looks like the client is passing an ExternalID on the incoming request, but the original value that is in etcd does not have an ExternalID set. Not sure what changed that would have caused this issue to appear.
I think this causes problems: The memory is re-used in a for-loop by Go so referring to a pointer value in a map here will cause problems I think.
Ok, the referenced line is the problem. Sending a PR.
Well, I go back on that now. A simple way to reproduce this is to delete all the minions in your cluster, and verify the node controller is able to add them back. For me, this is causing the node controller to add them back in an unknown status, and then all updates to the node fail. The update fails because the node controller is not setting an ExternalID on the original object.
I am looking into this now. cc/ too
Related issue opened while debugging this:
Debugged through here: I can via manual fmt see that the object has an ExternalID set prior to the call Create. When I look at etcd, I end up with this persisted: Note: it is missing an ExternalID somehow ;-)
Ok, I think I see the issue Nodes returned from here: Do not have an ExternalID Which can make Nodes created from here: End up without an External ID. Having two different nodeClient.Create() paths in this code is confusing. Also we are doing bad things in maps holding pointers to memory allocated in for-loop. We need to fix that ;-)
Yeah, this is bug we should fix. Thanks for looking into this.

If you already have a potential fix, please feel free to grab the issue from me.
I think I have a PR that should fix. Testing that now. Will cc you on the PR.
Thanks for fixing - it did end up affecting AWS as well (AWS isn't in a fully working state just yet, particularly with node discovery).