jiebi/CodeConvo huggingface dataset:
Change:
// Metrics to track ephemeral container usage by this kubelet ManagedEphemeralContainersKey = "managed_ephemeral_containers" <ins> // Metrics to track the CPU manager behavior CPUManagerPinningRequestsTotalKey = "cpu_manager_pinning_requests_total" CPUManagerPinningErrorsTotalKey   = "cpu_manager_pinning_errors_total" </ins> // Values used in metric labels Container          = "container" InitContainer      = "init_container"

Discussion:
Add to enable observability of the cpumanager. This is required to but it's also useful in general. To the best of my knowledge, it's very hard to observe the behavior of cpumanager without peeking into the pod and/or use the podresources interface (kubelet = 1.24). But even for the latter, no well known components expose metrics consuming this information. I believe anyway kubelet some expose some basic metrics about cpumanager behaviour, while deferring more fine grained metrics to external components (NFD, node_exporter, is fine)
/sig node /assign
/triage accepted /priority important-soon (as this is important for graduation for CPU Manager to GA)
Change:
Selector  string Namespace string <del> Describer func(*meta.RESTMapping) (printers.Describer, error) Builder   *resource.Builder </del> <ins> Describer  func(*meta.RESTMapping) (printers.Describer, error) NewBuilder func() *resource.Builder </ins> BuilderArgs []string

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: I run and I got Running with shows What you expected to happen: How to reproduce it (as minimally and precisely as possible): With Kubernetes master branch and in different terminal on the same machine Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: VM via libvirtd OS (e.g. from /etc/os-release): Fedora 27 with golang-1.10.1-1.fc29.x86_64 from rawhide Kernel (e.g. ):Install tools: ?? Others:
/sig cli
/assign
/assign
Change:
and current_state['details']['mtu'] == mtu and desired_network in current_state['details']['networks'] and current_state['details']['up'] <del> and current_state['iptables_rule_exists']): </del> <ins> and current_state['iptables_rule_1_exists'] and current_state['iptables_rule_2_exists']): </ins> ret['result'] = True ret['comment'] = 'System already in the correct state' return ret

Discussion:
Spin up a cluster. Create a container on each of two machines. Try to ping each other's IPs. No love. It seems we need an extra iptables rule. For example, for a minion with the 10.244.2.0/24 subnet assigned, we need: iptables -t nat -A POSTROUTING -s 10.244.2.0/24 ! -d 10.244.2.0/24 -j MASQUERADE
Hrm, I can't repro this. I tried: ping 10.244.2.1 from a different kubernetes VM and it worked. (or do you mean from inside a container?)
From within a container to another container
repro'ed it for me, too.
Is this just ping? Or is this any network traffic? , Tim Hockin wrote:
Any traffic - the kernel is not masquerading it because our iptables magic doesn't match packets coming from inside a container on a veth. I saw this while trying to do another round of perf tests.
Change:
ignorable         bool gotBind           bool isPrioritizer     bool <ins> errBind           bool </ins> } func (f *fakeExtender) Name() string {

Discussion:
I use extenders to add webhook for default-scheduler: And set to ignore scheuler error when scheduler extender is not working. But I got an error: . I suppose work fine in predicate path, but not work fine in bind path. The Ignorable logic in kube-scheduler: 637: and, 905: the is not judge in . Schedule should not error when set . extenders to kube-scheduler config(which has filterVerb and bindVerb and ignorable flag), example: and add config flag in kube-scheduler pod start up command. a scheduler-extender() and then stop it. a pod and you will see the schedule error. No response <details</details<detailsLocal environment </details<details</details<details</details<details</details<details</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 scheduling
/cc
/assign
Maybe this is not a bug but as designed, because bind is more critical than filter, what would you do in bind? I have no history context, cc
Hi, Kerthcet, in my scene, I use extender to bind IP(from my own network system) to my pod's annotaion. I'm aware of the critical of binding path, but, what If the extender is broken, how to skip it and continue? The scheduler extender design has supported ignorable, but only work for filter path make no sense for extender both has filter and bind. Maybe we can add an option to allow user to chose what can be ignored. Thanks for your reply anyway~
Reiterating the mentions to trigger a notification: <detailsIn response to : Maybe this is not a bug but as designed, because bind is more critical than filter, what would you do in bind? I have no history context, cc I'm aware of the critical of binding path, but, what If the extender is broken, how to skip it and continue?

The scheduler extender design has supported ignorable, but only work for filter path make no scence for extender both has filter and bind. Maybe we can add an option to allow user to chose what can be ignored. thanks for your reply anyway~ 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
So even the extender bind failed, will not impact your pod scheduling, right?
Yup
Right, if the field is there, we should support it. It's up to the cluster administrator to judge whether it makes sense to ignore a failed extender during bind.
Change:
options := []string{"bind"} <del> if *volumeSource.ReadOnly { </del> <ins> if volumeSource.ReadOnly != nil && *volumeSource.ReadOnly { </ins> options = append(options, "ro") }

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?: What happened: I'm running a Redis pod with a PV provisioned as an Azure Managed Disk. It's got an exec readiness probe that calls in the container. At some point it receives a SIGTERM. The kubelet then tries to sync the pod and restart the container, but it panics in (looking over the code, that's the only place where the error from is ignored) As a result, the pod hangs in a state, since the readiness probe cannot be ran in a non existing container. What you expected to happen: The container would successfully restart. How to reproduce it (as minimally and precisely as possible): It's the 2nd time it happens but I haven't yet figured out the conditions to reproduce. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration**: Azure w/ Managed Disks OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools: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
Hi could you also share the storageclass, pvc & pod yaml files? I would like to repro, thx
I may insert a nil check statment in this func: But I need to reproduce this bug anyway, so that I could find the root cause of this issue, thx.
Yes, an error check is what I'm hoping for :) I've used the chart. The PV/PVC were created manually, they're set to an empty storage class. I should mention that I've also noticed other pods being terminated/recreated at the time this one failed, however I didn't trace the cause of this yet.
thanks for the reporting, I may have found the root cause, just need a few more debuging time, thx.
GitHub didn't allow me to assign the following users: xiazhang. Note that only can be assigned. <detailsIn response to : /assign xiazhang 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
/assign andyzhangx
- Thanks for the fix!
Change:
mockClient := fake.NewSimpleClientset(testInput.testNamespace) if containsVersion(versions, "extensions/v1beta1") { resources := []unversioned.APIResource{} <del> for _, resource := range []string{"daemonsets", "deployments", "jobs", "horizontalpodautoscalers", "ingresses"} { </del> <ins> for _, resource := range []string{"daemonsets", "deployments", "replicasets", "jobs", "horizontalpodautoscalers", "ingresses"} { </ins> resources = append(resources, unversioned.APIResource{Name: resource}) } mockClient.Resources = map[string]*unversioned.APIResourceList{

Discussion:
The delete command for a replicaset hangs forever. This then manifests as phantom RSs when I delete and recreate a namespace.
- delete is the gift that keeps on giving
cc
Had you already deleted the corresponding Deployment?
I am still seeing this problem. Deployments and replica sets are sticking.
From what I can tell, calling DELETE_COLLECTION on Deployments is returning: And since the controller assumes not found errors are equivalent to already deleted, it thinks the content is deleted. When I manually inspect, I still see the deployment and replica set laying around... //cc
holding on this while i debug some more...
This was a false alarm, apologies.
Change:
"//pkg/util/metrics:go_default_library", "//vendor/github.com/golang/glog:go_default_library", "//vendor/k8s.io/apimachinery/pkg/api/errors:go_default_library", <del> "//vendor/k8s.io/apimachinery/pkg/labels:go_default_library", </del> "//vendor/k8s.io/apimachinery/pkg/util/runtime:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/wait:go_default_library", "//vendor/k8s.io/client-go/kubernetes/typed/core/v1:go_default_library",

Discussion:
For reasons that are not entirely clear to me, and as spotted by in , there are two functions for selecting nodes in includeNodeFromNodeList & getNodeConditionPredicate. I think includeNodeFromNodeList should use the logic in getNodeConditionPredicate
/sig network
Change:
"github.com/emicklei/go-restful/swagger" "k8s.io/kubernetes/pkg/api" <del> "k8s.io/kubernetes/pkg/api/latest" </del> "k8s.io/kubernetes/pkg/api/unversioned" "k8s.io/kubernetes/pkg/version" )

Discussion:
It would be nice if let me explain experimental resources to aid users ability to experiment.
It's possible this works today, but it was non-obvious how to use. Attempts:
cc
cc
No, this isn't supported, since current implementation only use v1 Client but not experimental Client.
do we need to fix this for 1.1?
How difficult do you think it would be to fix?
It has dependency on ServerAPIVersions(), for which we plan to make a clean-up PR. I guess it needs 3-4 days to get two PRs merged.
With , this can be fixed now. What's the expected behavior of ? I assume in case of , it should search hpa in both v1 and extensions/v1bata1, and determines hpa as a resource in the extensions group? BTW, the use of "api-version" flag is problematic It adds extra meaning to the generic "api-version" flag.
Change:
<ins> apiVersion: storage.k8s.io/v1beta1 kind: StorageClass metadata: name: default annotations: storageclass.beta.kubernetes.io/is-default-class: "true" labels: kubernetes.io/cluster-service: "true" provisioner: kubernetes.io/vsphere-volume parameters: diskformat: thin </ins>

Discussion:
We'd like to deprecate alpha provisioning in 1.6. In order to make current deployments working after upgrade to 1.6 we need to deploy a default StorageClass as part of installation/upgrade on vSphere so it will automatically provision volumes for PVCs marked with annotation - the annotation will be ignored and default storage class must provision the volume instead. On GCE and AWS, we use addon manager to install the default storage class, see Note that some extra code was needed in AWS and GCE installers to actually put the storage class into addons directory during installation, e.g. Please make sure that: A default StorageClass is deployed during "default" installation. It would be nice if admin could turn this off during installation (e.g. as on GCE) If any additional manual steps are needed to deploy the default storage class make sure they're documented in appropriate installation guide.
cc
thanks will look into this. CC
Documentation update for cloud provider
Change:
} return pathRecorderMux } <ins> // WithPlugin creates an Option based on plugin name and factory. func WithPlugin(name string, factory framework.PluginFactory) Option { return func(registry framework.Registry) error { return registry.Register(name, factory) } } </ins>

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : As the is now implementable, it will be easier to add out of tree scheduler. And we are trying to use it to implement our plugins. The issue tracks following problems: Implement interface same as Custom Scheduler Plugins (out of tree)  to support out of tree scheduler Add support for scheduler to load and register user’s out of tree scheduling plugins that could be configured by admins. We could use to implement it, however it has some drawbacks as pointed out, e.g. We need find other ways, e.g. . /sig scheduling /assign
I did some investigation. It seems that is a better choice for the second part of this issue. I am making a prototype for it. Need I send a proposal at first? /cc
Just wrote a small proposal for it
Change:
func (proxier *Proxier) addServiceOnUnusedPort(service string) (string, error) { unusedPortLock.Lock() defer unusedPortLock.Unlock() <del> l, err := net.Listen("tcp", ":0") </del> <ins> l, err := net.Listen("tcp", net.JoinHostPort(proxier.address, "0")) </ins> if err != nil { return "", err }

Discussion:
kube-proxy listens on all ports, but should be configurable. create a flag to specify which interface to listen on. Thanks for finding this bug.
For context, some providers apparently do external IPs by having a whole interface that gets 1:1 NAT without any firewalling. We do not want service ports on those interfaces. , Brian Ketelsen wrote:
Change:
dest.Components.Schemas = map[string]*spec.Schema{} } if _, exists := dest.Components.Schemas[k]; exists { <del> klog.Warningf("Should not happen: OpenAPI V3 merge schema conflict on %s", k) </del> <ins> if strings.HasPrefix(k, metadataGV) || strings.HasPrefix(k, autoscalingGV) { continue } return fmt.Errorf("OpenAPI V3 merge schema conflict on %s", k) </ins> } dest.Components.Schemas[k] = v }

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:
defer framework.RemoveLabelOffNode(cs, nodeName, k) // make the nodes have balanced cpu,mem usage ratio <del> createBalancedPodForNodes(f, cs, ns, nodeList.Items, podRequestedResource, 0.6) </del> <ins> err := createBalancedPodForNodes(f, cs, ns, nodeList.Items, podRequestedResource, 0.6) framework.ExpectNoError(err) </ins> By("Trying to relaunch the pod, now with labels.") labelPodName := "pod-with-node-affinity" pod := createPausePod(f, pausePodConfig{

Discussion:
Chronically failing test. Perhaps covers deprecated behavior? /sig scalability /assign
shows up in
/sig scheduling is one of scheduling e2e test.
/assign I'll check this one.
According to the log, the balanced pods were not created by scheduler, the cpu/mem usage was unchanged.
This test failing every other run. Fix or disable? Blocking 1.7?
similar to , move to 1.8, but I'll still working on that.
Change:
PodWorkerStartLatencyKey      = "pod_worker_start_latency_microseconds" PLEGRelistLatencyKey          = "pleg_relist_latency_microseconds" PLEGRelistIntervalKey         = "pleg_relist_interval_microseconds" <ins> EvictionStatsAgeKey           = "eviction_stats_age_microseconds" </ins> // Metrics keys of remote runtime operations RuntimeOperationsKey        = "runtime_operations" RuntimeOperationsLatencyKey = "runtime_operations_latency_microseconds"

Discussion:
We should keep track of how stale stats used for evictions are. This will help track improvements in eviction latency, and help uncover regressions. cc If someone could assign this to me, I would appreciate that.
closing via
Change:
"//staging/src/k8s.io/api/core/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/labels:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime:go_default_library", <del> "//vendor/k8s.io/klog:go_default_library", </del> ], )

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Logging getting points for ALL priorities set in the default scheduler policy Why is this needed: We have Kubernetes v1.14 with a problem of planning pods for three nodes. The problem is that the scheduler unevenly distributes the pods across the nodes. For example, the CPU on two nodes Node02 and Node03 are 50% loaded, while the CPU on the third Node01 is not loaded at all. While that the pods continue to be planned on Node02 and Node03, but they are not planned on Node01 at all. Scheduler logs (maximum logging level) with uniform planning: and uneven planning: As you can see, the sum of points for the priorities BalancedResourceAllocation, LeastResourceAllocation, SelectorSpreadPriority, TaintTolerationPriority is the same in both cases, but the final result is different. There is no way to understand for what specific policy priorities Node01 did not get 3 points, for to be on a par with the others, because the set of points of some priorities is not logged.
/sig scheduling
I think maybe we missed some logs which can reflect the situation of giving the score. WDYT? If you confirmed, I want to handle this issue.
Thank you for the answer! Here is the full scheduling log (logging level 10): maybe I’m really missing something, but I don’t see information about other priorities here.
Missing scores may be due to some priority functions are using non-map-reduce style, so they didn't hit the printing logic. We can add a logging function there to help you better debugging it. However, the code gets refactored in recent releases, and 1.14 is out of our supporting cycles (only 1.15, ,1.16, 1.17). Can you upgrade to a newer version, or I can provide a code snippet for you to compile on your local 1.14 branch?
Thank you, but I already solved my problem by creating an additional scheduler with a custom scheduling policies for my cronjob. However, it would be cool if you the logging function in the supported versions :)
SG. I created to address this.
I'm running v1.23.8, and I've tried and I'm still not seeing any of the scoring output you in Am I doing something wrong?

Shouldn't this be available in v1.23?
is it possible there is only 1 node candidate after filtering? In that case, the scoring logic will be bypassed as it's meaningless to score for 1 node. If it's not the case, could you check the beginning of the scheduler log, to ensure is configured properly?
Change:
genericfeatures.ValidatingAdmissionPolicy: {Default: false, PreRelease: featuregate.Beta}, <del> genericfeatures.CustomResourceValidationExpressions: {Default: true, PreRelease: featuregate.Beta}, </del> <ins> genericfeatures.CustomResourceValidationExpressions: {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.31 </ins> genericfeatures.OpenAPIEnums: {Default: true, PreRelease: featuregate.Beta},

Discussion:
This is the tracking issue of promoting CRD validation rules to GA: Listed the blocking issues/features below: [x] [x] [x] [x] Issues be aware of but should not be a GA blocker [ ] [ ] [ ] [ ] [ ] /sig api-machinery /triage accepted
/assign
/cc
Change:
continue } // A write lock is acquired to make sure the cleanUp routine doesn't delete any VM's created by ongoing PVC requests. <del> defer cleanUpDummyVMLock.Lock() err = diskmanagers.CleanUpDummyVMs(ctx, vmFolder, dc) if err != nil { glog.V(4).Infof("Unable to clean up dummy VM's in the kubernetes cluster: %q. err: %+v", vs.cfg.Workspace.Folder, err) </del> <ins> cleanUpDummyVMs := func() { cleanUpDummyVMLock.Lock() defer cleanUpDummyVMLock.Unlock() err = diskmanagers.CleanUpDummyVMs(ctx, vmFolder, dc) if err != nil { glog.V(4).Infof("Unable to clean up dummy VM's in the kubernetes cluster: %q. err: %+v", vs.cfg.Workspace.Folder, err) } </ins> } <ins> cleanUpDummyVMs() </ins> } }

Discussion:
/kind bug /sig release call will never be execute.
/assign
Maybe just cleanUpDummyVMLock.Lock() is you want? The is in infinite loop, and will never execute. I hope to get your reply to help fix it.
yes we need to correct this as below in the routine.
Change:
}, { <del> name: "spec:v6 ip:v6 dualstack:on", </del> <ins> name: "spec:v6 ip:v6 dualstack:on isIPv6Primary:false", isIPv6Primary:          false, </ins> specExpctPrimary:       false, clusterIPExpectPrimary: false, enableDualStack:        true,

Discussion:
What happened: When K8s is started in dual-stack mode with IPv6 as the "main" (or base) family services specified with ipFamily:IPv4 still get a ipv6 ; The is expicitly set to "10.0.0.0" using . What you expected to happen: Services with ipFamily:IPv4 shall get ipv4 ClusterIP addresses. How to reproduce it (as minimally and precisely as possible): Setup a K8s cluster in dual-stack mode with family IPv6 as base Define a service with ipFamily: IPv4 To make K8s think IPv6 is the main family the cue is to define ipv6 addresses to K8s binaries. Below are my settings as an example. I do not use but install "from scratch"; Master processes; is accessed with ipv4 which does not affect the K8s family. Worker processes; Anything else we need to know?: There are other problems with dual-stack/ipv6-base but may be caused by this one. For example does not work and some processes does not become "ready". Ipv6 traffic to ipv6 services and DNS works; Environment: Kubernetes version (use ):Cloud provider or hardware configuration: - OS (e.g: ): BusyBox based own setup. Kernel (e.g. ):Install tools: "from scratch" Network plugin and version (if this is a network-related bug): Others:
/sig network /cc
The problem seem to be; The problem occurs when an ipv6 range is specified first, even in an ipv4-based dual-stack cluster. But the ipv6 range must be specified first otherwise the "kubernetes" service gets an ipv4 address but an ipv6 backend; ~Perhaps the way to fix this problem is to make sure the service address is from the right family and require that the order to is "ipv4,ipv6".~ Bad idea!
There seem to be a option; But I can't see it in the help printout. I will try to use it...
:disappointed:
Here it where the kubernetes service address is set;
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍