jiebi/CodeConvo huggingface dataset:
Change:
// Related issue #15262/PR #15263 to move apiserver to RFC339NANO is closed. func normalizeStatus(pod *v1.Pod, status *v1.PodStatus) *v1.PodStatus { bytesPerStatus := kubecontainer.MaxPodTerminationMessageLogLength <del> if containers := len(pod.Spec.Containers) + len(pod.Spec.InitContainers); containers > 0 { </del> <ins> if containers := len(pod.Spec.Containers) + len(pod.Spec.InitContainers) + len(pod.Spec.EphemeralContainers); containers > 0 { </ins> bytesPerStatus = bytesPerStatus / containers } normalizeTimeStamp := func(t *metav1.Time) {

Discussion:
is not normalized in in the status manager: This does not seem to cause any user facing problem because is sorted before passed to the status manager and timestamps are normalized at marshaling to create a patch: However, an unexpected behavior is caused internally because timestamps are not normalized. If the log verbosity is 3 or larger, the following messages are logged periodically in kubelet when an ephemeral container exists: This message is emitted here: After returns , is called. This does not look so harmful because gets eventually: API is called once unnecessarily in , though: It might be better to normalize ephemeral container statuses, at least timestamps, in the status manager to avoid this unexpected behavior. Set the log verbosity of kubelet to 3 or larger. Then, create an ephemeral container like . No response <details</details<detailsNone </details<details</details<details</details<details</details<details</details
/sig node
This is a bug. Can you submit a PR to fix it? If not, I'd be happy to work on it
If you are interested, please feel free to assign yourself.
thx
/assign
/triage accepted /priority important-longterm
Change:
cleanupPods(cs, t, pods) cleanupNodes(cs, t) <ins> waitForSchedulerCacheCleanup(context.scheduler, t) </ins> }) } }

Discussion:
While lookint into , I spent few minutes looking into this test: And there is a problem that is relatively easy to reproduce. The problem is that we are running its test cases one by one. But nothing in the meantime is ensuring that the current state that the test assumes is reflected in scheduler. In particular the problem that I observed couple time is that: we finished one test case we call cleanupNodes [but we don't ensure that scheduler actually cleaned up this node] we start the next test case we try to schedule a pod that has some toleration (but shouldn't fit on our node) by accident the toleration make it fit on to the previous node so scheduler schedules it on the node from previous test case
/assign
Change:
} } <del> // Install the kubernetes-specific postrouting rules. We use a whole chain for // this so that it is easier to flush and change, for example if the mark // value should ever change. // NB: THIS MUST MATCH the corresponding code in the kubelet writeLine(proxier.natRules, []string{ "-A", string(kubePostroutingChain), "-m", "mark", "!", "--mark", fmt.Sprintf("%s/%s", proxier.masqueradeMark, proxier.masqueradeMark), "-j", "RETURN", }...) // Clear the mark to avoid re-masquerading if the packet re-traverses the network stack. writeLine(proxier.natRules, []string{ "-A", string(kubePostroutingChain), // XOR proxier.masqueradeMark to unset it "-j", "MARK", "--xor-mark", proxier.masqueradeMark, }...) masqRule := []string{ "-A", string(kubePostroutingChain), "-m", "comment", "--comment", `"kubernetes service traffic requiring SNAT"`, "-j", "MASQUERADE", } if proxier.iptables.HasRandomFully() { masqRule = append(masqRule, "--random-fully") } writeLine(proxier.natRules, masqRule...) // Install the kubernetes-specific masquerade mark rule. We use a whole chain for // this so that it is easier to flush and change, for example if the mark // value should ever change. writeLine(proxier.natRules, []string{ "-A", string(KubeMarkMasqChain), "-j", "MARK", "--or-mark", proxier.masqueradeMark, }...) </del> } // getExistingChains get iptables-save output so we can check for existing chains and rules.

Discussion:
Which jobs are failing: pull-kubernetes-e2e-gci-gce-ipvs Which test(s) are failing: Not all of these fail on every run: [sig-network] Networking Granular Checks: Services should function for endpoint-Service: http [sig-network] Services should allow pods to hairpin back to themselves through services [sig-storage] Flexvolumes should be mountable when non-attachable [sig-network] Networking Granular Checks: Services should function for endpoint-Service: udp [sig-network] Services should have session affinity timeout work for service with type clusterIP [LinuxOnly] [Conformance] [sig-network] Services should allow pods to hairpin back to themselves through services Since when has it been failing: Looking through job history, it looks like the last time any runs passed was on May 2. Testgrid link: N/A since testgrid filtered tests based on [sig-network] Anything else we need to know: This was discovered by in , it also appears to be affecting other PRs. /cc /sig network
This seems related to , but if I'm interpreting test results correctly pull-kubernetes-e2e-gci-gce-ipvs never stopped failing.
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign I'll try to fix those cases
May I ask why do you think this is related to ? Seems like first two flexvolumes related cases failed, then after some commit, service related cases start failing.
let me handle the services tests, I think I know the problem, will try to submit a fix today. Do you know what happen with the storage ones?
/assign I just submitted a PR to fix the failing tests
Thanks, seems like all cases fixed.
Change:
expectAssumedClaims = append(expectAssumedClaims, expected.assumedClaim) } actualAssumedClaims := tc.listAssumedClaims() <del> assert.Equal(t, expectAssumedClaims, actualAssumedClaims, "assumed claims") </del> <ins> if diff := cmp.Diff(expectAssumedClaims, actualAssumedClaims, cmpopts.IgnoreFields(metav1.ObjectMeta{}, "UID", "ResourceVersion")); diff != "" { t.Errorf("Assumed claims are different (- expected, + actual):n%s", diff) } </ins> var expectInFlightClaims []metav1.Object if expected.inFlightClaim != nil { expectInFlightClaims = append(expectInFlightClaims, expected.inFlightClaim) } actualInFlightClaims := tc.listInFlightClaims() <del> assert.Equal(t, expectInFlightClaims, actualInFlightClaims, "in-flight claims") } // setGVK is implemented by metav1.TypeMeta and thus all API objects, in // contrast to metav1.Type, which is not (?!) implemented. type setGVK interface { SetGroupVersionKind(gvk schema.GroupVersionKind) } // stripObjects removes certain fields (Kind, APIVersion, etc.) which are not // important and might not be set. func stripObjects(objects []metav1.Object) { for _, obj := range objects { obj.SetResourceVersion("") obj.SetUID("") if objType, ok := obj.(setGVK); ok { objType.SetGroupVersionKind(schema.GroupVersionKind{}) } </del> <ins> if diff := cmp.Diff(expectInFlightClaims, actualInFlightClaims, cmpopts.IgnoreFields(metav1.ObjectMeta{}, "UID", "ResourceVersion")); diff != "" { t.Errorf("In-flight claims are different (- expected, + actual):n%s", diff) </ins> } }

Discussion:
pull-kubernetes-unit dynamicresources unknown multiple failures in tests as seen in n/a /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
probably cc
/assign
DeepCopy missing here:
Change:
return p } <ins> // Terminating sets the inner pod's deletionTimestamp to current timestamp. func (p *PodWrapper) Terminating() *PodWrapper { now := metav1.Now() p.DeletionTimestamp = &now return p } </ins> // ZeroTerminationGracePeriod sets the TerminationGracePeriodSeconds of the inner pod to zero. func (p *PodWrapper) ZeroTerminationGracePeriod() *PodWrapper { p.Spec.TerminationGracePeriodSeconds = &zero

Discussion:
How to reproduce it (as minimally and precisely as possible): pre-requisites: a multi-az cluster, a deployment with 1 pod in each az. a with and . the node(s) in 1 az. the deployment's pod(s) from the cordoned az. What happened: A new pod was created and scheduled in a form that What you expected to happen: I expected that a new pod will be created and be "stuck" in status as it shouldn't have nowhere be scheduled. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS OS (e.g: ):Kernel (e.g. ): 4.19.84-coreos Others: I created a with how I reproduce the bug
/sig scheduling
cc/
Thanks for raising this issue. I feel like it's a general timing issue - when you delete a Pod, that Pod may still exist for a very short time (in graceful deletion period), and at the same time, the controller backfills a Pod for it. So when scheduling tries to schedule the backfill Pod, it may read the cluster as: [1, 1, 1(deleting)]. To confirm this, can you try deleting the Pod using , and see if the problem goes away?
Yes sure I will try that. It sounds reasonable, thats why in the first demonstration I deleted all the pods and waited for all of them to completely disappear. Nevertheless, this is still something that I believe needs to be fixed. The pod's evaluation should take in consideration pods that are in status and don't count them as pods.
I do believe we exclude the Pods. (if not, it should be a serious regression). What concerns me is that at that moment, scheduler may treats that (deleting) Pod as running in its cache. I will try to debug into this.
Yep, this time the new pod was in status until I uncordoned the relevant nodes.
Change:
newSCSICreated = true } <del> disk := vmDevices.CreateDisk(diskController, ds.Reference(), vmDiskPath) </del> <ins> disk := vmDevices.CreateDisk(scsiController, ds.Reference(), vmDiskPath) unitNumber, err := getNextUnitNumber(vmDevices, scsiController) if err != nil { glog.Errorf("cannot attach disk to VM, limit reached - %v.", err) return "", "", err } *disk.UnitNumber = unitNumber </ins> backing := disk.Backing.(*types.VirtualDiskFlatVer2BackingInfo) backing.DiskMode = string(types.VirtualDiskModeIndependent_persistent)

Discussion:
vSphere cloud provider volume plugin attach disk limits the number of volumes because of two issues: new SCSI controller is only created when one does not exist. A new controller should be when required and limit not reached. disk will fail when attaching disk to slot 7 on controller. Slot 7 on SCSI controller is reserved and therefore should be skipped. This issue has been brought up in Govmomi library .
Change:
# $4: The kube-env metadata. function create-node-template { detect-project <ins> # First, ensure the template doesn't exist. # TODO(mbforbes): To make this really robust, we need to parse the output and #                 add retries. Just relying on a non-zero exit code doesn't #                 distinguish an ephemeral failed call from a "not-exists". if gcloud compute instance-templates describe "$1"; then echo "Instance template ${1} already exists; continuing." >&2 return fi </ins> local attempt=0 while true; do if ! gcloud compute instance-templates create "$1" 

Discussion:
See issue as the roll-up for node upgrades. tl;dr: Update MIG template, then call a MIG rollingupdate. More details: When upgrading nodes, an in-place upgrade must worry about leftover state on the boot disk, VM configuration like IP tables, and the idempotency of salt. Getting a fresh VM instead would remove these concerns and provide a clean state for a new node. Furthermore, a versioned node spec () includes the tuple of (kubelet, kube-proxy, docker, kernel/OS). In the general case, changing docker or the kernel/OS means we have to stop the running pods. Once know we have to stop the pods, the simplest upgrade mechanism is to totally down the node and provision a new one. Provisioning a new node is also a great backup to have for node repairs. To be clear, though, this issue is entirely separate from node repairs; once we have the capability to grow the cluster by adding new nodes, this mechanism, and other repair mechanisms, will build on top of that capability. This was blocked by: nodes joining a running cluster (template-only metadata) References: The most relevant discussion regarding the worries of complications with state while doing in-place upgrades is .
FWIW, I think we need this as a fallback to repair completely borked nodes? That is, it may not be necessary for upgrades per se, but could end up being independently useful.
Thanks for the comment, I updated the description to be clear about what this issue is addressing. Having the ability to add new nodes to a cluster will both enable this upgrade path as well as give us a great "hammer" to use for repairs.
Working on this now.
Change:
// according to whatever system is managing the endpoint. A nil value // indicates an unknown state. In most cases consumers should interpret this // unknown state as ready. For compatibility reasons, ready should never be <del> // "true" for terminating endpoints. </del> <ins> // "true" for terminating endpoints, except when the normal readiness // behavior is being explicitly overridden, for example when the associated // Service has set the publishNotReadyAddresses flag. </ins> // +optional optional bool ready = 1;

Discussion:
The EndpointSlice API says and it works as expected in normal circumstances I delete the pod and the endpoints conditions are the expected However, if during this time I set we run into an incoherence with the API doc, but it seems that we already documented this edge case in the code I think that at this point is just to amend this information to the API, no? /kind bug /kind documentation
/sig network /assign
I would like to work on this. I just want a bit more clarification on what needs to be done!
I proposed a solution, that is clarify it in the doc ... once we reach an agreement in this issue we implement it ...
+1 to docs. I'd make it a little more vague, like: """ when the normal readiness behavior is being explicitly overridden, for example when the associated Service has set the publishNotReadyAddresses flag. """
so, the thing is to update the docs here with Tim's suggestion and here and do to update the generated code and submit a PR
/assign
I am not able to run command in windows, I am checking it. This error message is coming: *
/triage accepted
Is there a PR for this? Happy to review
I will raise the PR if my above problem gets solved. I am trying to make an update but the error mentioned above is coming.
What platform are you on? If the Makefile were really broken EVERYTHING would be failing.
he's on windows ... you will need a linux/macos. see
Let me know if you want someone to take it over.
I think in that case, you can assign this to someone else.
Change:
// The password of the client certificate for an AAD application with RBAC access to talk to Azure RM APIs AADClientCertPassword string `json:"aadClientCertPassword" yaml:"aadClientCertPassword"` // Use managed service identity for the virtual machine to access Azure ARM APIs <del> UseManagedIdentityExtension bool `json:"useManagedIdentityExtension"` </del> <ins> UseManagedIdentityExtension bool `json:"useManagedIdentityExtension" yaml:"useManagedIdentityExtension"` </ins> // The ID of the Azure Subscription that the cluster is deployed in SubscriptionID string `json:"subscriptionId" yaml:"subscriptionId"` }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: kubelet fails to start on a standard VM with MSI enabled with . Provider config: Logs: What you expected to happen: kubelet starts finds a token via MSI and starts. How to reproduce it (as minimally and precisely as possible): Create Azure VM with MSI enabled. Start kubelet with and . Anything else we need to know?: It was working in 1.9. Environment: Kubernetes version (use ): v1.10.0-beta.1 Cloud provider or hardware configuration: Azure OS (e.g. from /etc/os-release): Container Linux 1576.5.0 Kernel (e.g. ): 4.14.11-coreos Install tools: Custom () Others:
/sig azure
there should be one log in kubelet if according to following code, while your logs don't have such log, could you confirm you are using the provided in your kubelet?
you can look at the log output. There are lines:
Seems it's a bug within azure cloud provider. Let me check what's wrong.
Added to v1.10 milestone since it is a critical bug fix. cc
/status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
I saw your PR. Thanks! However I'm uncertain how this was working in 1.9?
The description is not clear. It is broken in 1.10 because of a refactor: Config.UseManagedIdentityExtension overrides auth.AzureAuthConfig.UseManagedIdentityExtension. There is no such problem on old releases.
Change:
"os" "runtime" <del> pkg_runtime "k8s.io/kubernetes/pkg/runtime" </del> <ins> kruntime "k8s.io/kubernetes/pkg/runtime" </ins> "github.com/golang/glog" flag "github.com/spf13/pflag"

Discussion:
Forked from pointed out that all package names should be lower case, no under_scores or mixedCaps. The same rule applies to renaming imported packages. () generated a list of mixedCaps package names in our codebase: I will upload a PR later to rename kubeletTypes to kubetypes, and the rest is up for grabs.
sorry i have not saw this issue as i open a similar one(), do you mind i participate in this issue? i would happy to do some work for this. best regards.
of course, fixes are welcome. Thanks for picking up on this! We'll try to expedite the review and merge process of such PRs to avoid a lot of churns, but chances are that some rebases are needed :)
ok, i will send some fix sonner, and tag you for review. thanks again.
Not done:
Change:
In order to access your nginx landing page, you also have to make sure that traffic from external IPs is allowed. Do this by opening a [firewall to allow traffic on port 80](services-firewalls.md). <ins> If you're running on AWS, Kubernetes creates an ELB for you.  ELBs use host names, not IPs, so you will have to do `kubectl describe svc my-nginx` and look for the `LoadBalancer Ingress` host name.  Traffic from external IPs is allowed automatically. </ins> ## Killing the application To kill the application and delete its containers and public IP address, do:

Discussion:
GCP uses IP addresses, which is shown on an extra line. AWS does not give an IP address. We should show it. GCP: AWS: I'd like to try to do this work.
cc
AWS uses hostnames for load balancers which is why they aren't showing up. The hostname is also pretty long, and I know we've had problems with the width of the kubectl output before. That said, I seem to recall a "--wide" option, and I think you can maybe choose which columns appear? I think it is a useful suggestion, and I think your biggest battle will be to keep the number of columns such that it doesn't normally wrap. Just so you know, I normally do to see the AWS ELB hostname.
Duping this into , we also have an lgtm'd pr out
Change:
"context" "fmt" "sort" <ins> "strings" </ins> "sync/atomic" "time"

Discussion:
[It] [sig-storage] CSI Mock selinux on mount metrics SELinuxMount metrics [LinuxOnly][Feature:SELinux][Feature:SELinuxMountReadWriteOncePod][Serial] warning is not bumped on two Pods with the same context on RWO volume [sig-storage] [It] [sig-storage] CSI Mock selinux on mount metrics SELinuxMount metrics [LinuxOnly][Feature:SELinux][Feature:SELinuxMountReadWriteOncePod][Serial] warning is bumped on two Pods with a different context on RWO volume [sig-storage] Sample failure: October 25, 2023 It fails since The PR a label to some SELinux metric and the tests do not count with that. No response /sig storage
/assign /triage accepted
Change:
metricsBindAddress: "2.3.4.5:23456", }, { <ins> // Test for 'bindAddress: "::"' (IPv6 all-zeros) in kube-proxy // config file. The user will need to put quotes around '::' since // 'bindAddress: ::' is invalid yaml syntax. name:               "iptables mode, IPv6 "::" bind address", mode:               "iptables", bindAddress:        ""::"", clusterCIDR:        "fd00:1::0/64", healthzBindAddress: "[fd00:1::5]:12345", metricsBindAddress: "[fd00:2::5]:23456", }, { // Test for 'bindAddress: "[::]"' (IPv6 all-zeros in brackets) // in kube-proxy config file. The user will need to use // surrounding quotes here since 'bindAddress: [::]' is invalid // yaml syntax. name:               "iptables mode, IPv6 "[::]" bind address", mode:               "iptables", bindAddress:        ""[::]"", clusterCIDR:        "fd00:1::0/64", healthzBindAddress: "[fd00:1::5]:12345", metricsBindAddress: "[fd00:2::5]:23456", }, { // Test for 'bindAddress: ::0' (another form of IPv6 all-zeros). // No surrounding quotes are required around '::0'. name:               "iptables mode, IPv6 ::0 bind address", mode:               "iptables", bindAddress:        "::0", clusterCIDR:        "fd00:1::0/64", healthzBindAddress: "[fd00:1::5]:12345", metricsBindAddress: "[fd00:2::5]:23456", }, { </ins> name:               "ipvs mode, IPv6 config", mode:               "ipvs", bindAddress:        "2001:db8::1",

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: Upon code inspection, found that kube-proxy server takes into consideration a bind address of 0.0.0.0 (IPv4), but does not check for a bind address of :: (all-zeros IPv6) when calculating its node IP. What you expected to happen: IPv6 address "::" should be taken into consideration when calculating node IP. How to reproduce it (as minimally and precisely as possible): Code inspection. Anything else we need to know?: Environment: Kubernetes version (use ): Latest master Cloud provider or hardware configuration**: VirtualBox cluster, Ubuntu 16.04.1 host, CentOS 7 guests OS (e.g. from /etc/os-release): CentOS 7 Kernel (e.g. ): 3.10.0-514.26.2.el7.x8664 SMP Tue Jul 4 15:04:05 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/area ipv6 /sig network