Question:
<!-- 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: The kubelet metrics related to , except for one, are missing from the kubelet metric endpoint. This applies to these metrics: What you expected to happen: I expect that the metrics mentioned above should be found in the endpoint on the kubelet. How to reproduce it (as minimally and precisely as possible): Run kubelet with a valid , and (defaults to true). or run the node e2e tests: Anything else we need to know?: All e2e tests related to DynamicKubeletConfig fails in master (and in v1.16): This bug/error was introduced in Environment: Kubernetes version (use ): && Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig node /cc logicalhan tallclair mtaufen
/cc
/assign WIP proof of concept solution to fix (make it a bit easier to understand the problem) here:
/assign
edit: I misunderstood the issue. discussed with offline, and he has an idea to restore previous behavior
That sounds perfect! He answered in the PR, so hopefully we can get this working again. I have wrapped my head around this issue for quite a few hours now, so I understand that it is kinda hard to understand by just reading this issue. Here is some more background info that hopefully makes sense.
/priority important-soon /milestone v1.17
Looks like the CI jobs are cleaning up now! ! Finally down to single digit number test failures, and away from the 30+ :smile:

} } <del> // If the kubelet config controller is available, and dynamic config is enabled, start the config and status sync loops if utilfeature.DefaultFeatureGate.Enabled(features.DynamicKubeletConfig) && len(s.DynamicConfigDir.Value()) > 0 && kubeDeps.KubeletConfigController != nil && !standaloneMode && !s.RunOnce { if err := kubeDeps.KubeletConfigController.StartSync(kubeDeps.KubeClient, kubeDeps.EventClient, string(nodeName)); err != nil { return err } } </del> if kubeDeps.Auth == nil { auth, err := BuildAuth(nodeName, kubeDeps.KubeClient, s.KubeletConfiguration) if err != nil {


Question:
<!-- 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: The kubelet metrics related to , except for one, are missing from the kubelet metric endpoint. This applies to these metrics: What you expected to happen: I expect that the metrics mentioned above should be found in the endpoint on the kubelet. How to reproduce it (as minimally and precisely as possible): Run kubelet with a valid , and (defaults to true). or run the node e2e tests: Anything else we need to know?: All e2e tests related to DynamicKubeletConfig fails in master (and in v1.16): This bug/error was introduced in Environment: Kubernetes version (use ): && Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig node /cc logicalhan tallclair mtaufen
/cc
/assign WIP proof of concept solution to fix (make it a bit easier to understand the problem) here:
/assign
edit: I misunderstood the issue. discussed with offline, and he has an idea to restore previous behavior
That sounds perfect! He answered in the PR, so hopefully we can get this working again. I have wrapped my head around this issue for quite a few hours now, so I understand that it is kinda hard to understand by just reading this issue. Here is some more background info that hopefully makes sense.
/priority important-soon /milestone v1.17
Looks like the CI jobs are cleaning up now! ! Finally down to single digit number test failures, and away from the 30+ :smile:

return err } <ins> // If the kubelet config controller is available, and dynamic config is enabled, start the config and status sync loops if utilfeature.DefaultFeatureGate.Enabled(features.DynamicKubeletConfig) && len(s.DynamicConfigDir.Value()) > 0 && kubeDeps.KubeletConfigController != nil && !standaloneMode && !s.RunOnce { if err := kubeDeps.KubeletConfigController.StartSync(kubeDeps.KubeClient, kubeDeps.EventClient, string(nodeName)); err != nil { return err } } </ins> if s.HealthzPort > 0 { mux := http.NewServeMux() healthz.InstallHandler(mux)


Question:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Change scheduler metric from Gauge to Histogram Why is this needed: is recorded for each preemption attempt. A histogram is better. /sig scheduling /help /good-first-issue
/help /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help /good-first-issue 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
I can work on this issue.
/assign
I could work on this as well if doesn't have time to work on this.
I am working on it, I will create the initial PR in less than a week. Sorry for the delay.

StabilityLevel: metrics.ALPHA, }, ) <del> PreemptionVictims = metrics.NewGauge( &metrics.GaugeOpts{ Subsystem:      SchedulerSubsystem, Name:           "pod_preemption_victims", Help:           "Number of selected preemption victims", </del> <ins> PreemptionVictims = metrics.NewHistogram( &metrics.HistogramOpts{ Subsystem: SchedulerSubsystem, Name:      "pod_preemption_victims", Help:      "Number of selected preemption victims", // we think #victims>50 is pretty rare, therefore [50, +Inf) is considered a single bucket. Buckets:        metrics.LinearBuckets(5, 5, 10), </ins> StabilityLevel: metrics.ALPHA, }) PreemptionAttempts = metrics.NewCounter(


Question:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Change scheduler metric from Gauge to Histogram Why is this needed: is recorded for each preemption attempt. A histogram is better. /sig scheduling /help /good-first-issue
/help /good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /help /good-first-issue 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
I can work on this issue.
/assign
I could work on this as well if doesn't have time to work on this.
I am working on it, I will create the initial PR in less than a week. Sorry for the delay.

sched.Recorder.Eventf(victim, preemptor, v1.EventTypeNormal, "Preempted", "Preempting", "Preempted by %v/%v on node %v", preemptor.Namespace, preemptor.Name, nodeName) } <del> metrics.PreemptionVictims.Set(float64(len(victims))) </del> <ins> metrics.PreemptionVictims.Observe(float64(len(victims))) </ins> } // Clearing nominated pods should happen outside of "if node != nil". Node could // be nil when a pod with nominated node name is eligible to preempt again,


Question:
Currently custom predicate and priorities can be created through the . The problem is that a custom predicate/priority, like ServiceAffinity, can be multiple times in the Policy with different names, possibly with different arguments. This semantic (i.e., specifying multiple instances of the same custom predicate with different arguments) is only useful if different s were specified because in all cases of custom predicates/priorities the arguments are merge-able (for example, from multiple CheckServiceAffinity custom predicates can be merged into one set). In the world of framework plugins, we don't currently have a way to maintain those semantics. to run. The question here: do we really want to maintain the old semantics of custom predicates and priorities? in other words, do we need to change the ComponentConfig API to somehow allow specifying multiple instances of the same Plugin with different arguments/weights, or should we consider that this is not supported? I always lean towards simplifying things, so my suggestion is to not support that, but I would like to know if there are actual deployments that rely on this. /sig scheduling /cc
/cc
We discussed this in the sig meeting, and put the issue for discussion on the scheduler and kubernetes-dev mailing list, I believe this behavior is not intentional, and so we should add logic to fail the scheduler configuration when a policy includes more than one custom predicate/priority of the same type. /assign
/assign
any progress on this one?
I haven't made any progress on this yet, but it's on my priority now
In migrating custom predicates to filter plugins , I am gonna ignore the custom predicate name and use the default name.

func ValidatePolicy(policy schedulerapi.Policy) error { var validationErrors []error <ins> priorities := make(map[string]schedulerapi.PriorityPolicy, len(policy.Priorities)) </ins> for _, priority := range policy.Priorities { if priority.Weight <= 0 || priority.Weight >= framework.MaxWeight { validationErrors = append(validationErrors, fmt.Errorf("Priority %s should have a positive weight applied to it or it has overflown", priority.Name)) } <ins> validationErrors = append(validationErrors, validatePriorityRedeclared(priorities, priority)) } predicates := make(map[string]schedulerapi.PredicatePolicy, len(policy.Predicates)) for _, predicate := range policy.Predicates { validationErrors = append(validationErrors, validatePredicateRedeclared(predicates, predicate)) </ins> } binders := 0


Question:
Currently custom predicate and priorities can be created through the . The problem is that a custom predicate/priority, like ServiceAffinity, can be multiple times in the Policy with different names, possibly with different arguments. This semantic (i.e., specifying multiple instances of the same custom predicate with different arguments) is only useful if different s were specified because in all cases of custom predicates/priorities the arguments are merge-able (for example, from multiple CheckServiceAffinity custom predicates can be merged into one set). In the world of framework plugins, we don't currently have a way to maintain those semantics. to run. The question here: do we really want to maintain the old semantics of custom predicates and priorities? in other words, do we need to change the ComponentConfig API to somehow allow specifying multiple instances of the same Plugin with different arguments/weights, or should we consider that this is not supported? I always lean towards simplifying things, so my suggestion is to not support that, but I would like to know if there are actual deployments that rely on this. /sig scheduling /cc
/cc
We discussed this in the sig meeting, and put the issue for discussion on the scheduler and kubernetes-dev mailing list, I believe this behavior is not intentional, and so we should add logic to fail the scheduler configuration when a policy includes more than one custom predicate/priority of the same type. /assign
/assign
any progress on this one?
I haven't made any progress on this yet, but it's on my priority now
In migrating custom predicates to filter plugins , I am gonna ignore the custom predicate name and use the default name.

return utilerrors.NewAggregate(validationErrors) } <ins> // validatePriorityRedeclared checks if any custom priorities have been declared multiple times in the policy config // by examining the specified priority arguments func validatePriorityRedeclared(priorities map[string]schedulerapi.PriorityPolicy, priority schedulerapi.PriorityPolicy) error { var priorityType string if priority.Argument != nil { if priority.Argument.LabelPreference != nil { priorityType = "LabelPreference" } else if priority.Argument.RequestedToCapacityRatioArguments != nil { priorityType = "RequestedToCapacityRatioArguments" } else if priority.Argument.ServiceAntiAffinity != nil { priorityType = "ServiceAntiAffinity" } else { return fmt.Errorf("No priority arguments set for priority %s", priority.Name) } if existing, alreadyDeclared := priorities[priorityType]; alreadyDeclared { return fmt.Errorf("Priority '%s' redeclares custom priority '%s', from:'%s'", priority.Name, priorityType, existing.Name) } priorities[priorityType] = priority } return nil } // validatePredicateRedeclared checks if any custom predicates have been declared multiple times in the policy config // by examining the specified predicate arguments func validatePredicateRedeclared(predicates map[string]schedulerapi.PredicatePolicy, predicate schedulerapi.PredicatePolicy) error { var predicateType string if predicate.Argument != nil { if predicate.Argument.LabelsPresence != nil { predicateType = "LabelsPresence" } else if predicate.Argument.ServiceAffinity != nil { predicateType = "ServiceAffinity" } else { return fmt.Errorf("No priority arguments set for priority %s", predicate.Name) } if existing, alreadyDeclared := predicates[predicateType]; alreadyDeclared { return fmt.Errorf("Predicate '%s' redeclares custom predicate '%s', from:'%s'", predicate.Name, predicateType, existing.Name) } predicates[predicateType] = predicate } return nil } </ins> // validateExtendedResourceName checks whether the specified name is a valid // extended resource name. func validateExtendedResourceName(name v1.ResourceName) []error {


Question:
Currently custom predicate and priorities can be created through the . The problem is that a custom predicate/priority, like ServiceAffinity, can be multiple times in the Policy with different names, possibly with different arguments. This semantic (i.e., specifying multiple instances of the same custom predicate with different arguments) is only useful if different s were specified because in all cases of custom predicates/priorities the arguments are merge-able (for example, from multiple CheckServiceAffinity custom predicates can be merged into one set). In the world of framework plugins, we don't currently have a way to maintain those semantics. to run. The question here: do we really want to maintain the old semantics of custom predicates and priorities? in other words, do we need to change the ComponentConfig API to somehow allow specifying multiple instances of the same Plugin with different arguments/weights, or should we consider that this is not supported? I always lean towards simplifying things, so my suggestion is to not support that, but I would like to know if there are actual deployments that rely on this. /sig scheduling /cc
/cc
We discussed this in the sig meeting, and put the issue for discussion on the scheduler and kubernetes-dev mailing list, I believe this behavior is not intentional, and so we should add logic to fail the scheduler configuration when a policy includes more than one custom predicate/priority of the same type. /assign
/assign
any progress on this one?
I haven't made any progress on this yet, but it's on my priority now
In migrating custom predicates to filter plugins , I am gonna ignore the custom predicate name and use the default name.

}}, expected: errors.New("kubernetes.io/foo is an invalid extended resource name"), }, <ins> { name: "invalid redeclared custom predicate", policy: api.Policy{ Predicates: []api.PredicatePolicy{ {Name: "customPredicate1", Argument: &api.PredicateArgument{ServiceAffinity: &api.ServiceAffinity{Labels: []string{"label1"}}}}, {Name: "customPredicate2", Argument: &api.PredicateArgument{ServiceAffinity: &api.ServiceAffinity{Labels: []string{"label2"}}}}, }, }, expected: errors.New("Predicate 'customPredicate2' redeclares custom predicate 'ServiceAffinity', from:'customPredicate1'"), }, { name: "invalid redeclared custom priority", policy: api.Policy{ Priorities: []api.PriorityPolicy{ {Name: "customPriority1", Weight: 1, Argument: &api.PriorityArgument{ServiceAntiAffinity: &api.ServiceAntiAffinity{Label: "label1"}}}, {Name: "customPriority2", Weight: 1, Argument: &api.PriorityArgument{ServiceAntiAffinity: &api.ServiceAntiAffinity{Label: "label2"}}}, }, }, expected: errors.New("Priority 'customPriority2' redeclares custom priority 'ServiceAntiAffinity', from:'customPriority1'"), }, </ins> } for _, test := range tests {


Question:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: cloud-provider-openstack jobs Which test(s) are failing: hack/local-up- itself fails. Since when has it been failing: Recent change , checks for node ready by doing a grep of KUBELETHOST. But when HOSTNAMEOVERRIDE is set , its unable to find the ip and exits. Testgrid link: Reason for failure: Anything else we need to know:
Repalce KUBELETHOST with HOSTNAMEOVERRIDE shoud fix this issue, I have created a pull request
Thanks. But what if HOSTNAME_OVERRIDE is not set , then again it would fail? I guess its optional parameter
cc
If not set, the default value is 127.0.0.1, won't fail
Hi ramineni, nodpad is correct. HOSTNAME_OVERRIDE do have default value which is 127.0.0.1.
Thanks. Then grep HOSTNAME_OVERRIDE is ideal solution. That would work for me. Hopefully PR gets merged soon

function wait_node_ready(){ # check the nodes information after kubelet daemon start local nodes_stats="${KUBECTL} --kubeconfig '${CERT_DIR}/admin.kubeconfig' get nodes" <del> local node_name=$KUBELET_HOST </del> <ins> local node_name=$HOSTNAME_OVERRIDE </ins> local system_node_wait_time=30 local interval_time=2 kube::util::wait_for_success "$system_node_wait_time" "$interval_time" "$nodes_stats | grep $node_name"


Question:
What would you like to be : A unit test that verifies the evaluation order of the nodes in the scheduler. Why is this needed: The scheduler evaluates the nodes in a specific order until it finds a pre-defined minimum number of feasible nodes. To give all nodes a fair chance of being evaluated, in each scheduling cycle, the scheduler starts evaluating from where it left off in the previous cycle. This is captured by the parameter in  We need to add a unit test that captures regressions related to this behavior to avoid bugs like /sig scheduling /priority important-soon /help
/assign
/remove-help

disablePreemption        bool percentageOfNodesToScore int32 enableNonPreempting      bool <del> lastProcessedNodeIndex   int </del> <ins> nextStartNodeIndex       int </ins> } // snapshot snapshots scheduler cache and node infos for all fit and priority


Question:
What would you like to be : A unit test that verifies the evaluation order of the nodes in the scheduler. Why is this needed: The scheduler evaluates the nodes in a specific order until it finds a pre-defined minimum number of feasible nodes. To give all nodes a fair chance of being evaluated, in each scheduling cycle, the scheduler starts evaluating from where it left off in the previous cycle. This is captured by the parameter in  We need to add a unit test that captures regressions related to this behavior to avoid bugs like /sig scheduling /priority important-soon /help
/assign
/remove-help

checkNode := func(i int) { // We check the nodes starting from where we left off in the previous scheduling cycle, // this is to make sure all nodes have the same chance of being examined across pods. <del> nodeInfo := g.nodeInfoSnapshot.NodeInfoList[(g.lastProcessedNodeIndex+i)%allNodes] </del> <ins> nodeInfo := g.nodeInfoSnapshot.NodeInfoList[(g.nextStartNodeIndex+i)%allNodes] </ins> fits, failedPredicates, status, err := g.podFitsOnNode( ctx, state,


Question:
What would you like to be : A unit test that verifies the evaluation order of the nodes in the scheduler. Why is this needed: The scheduler evaluates the nodes in a specific order until it finds a pre-defined minimum number of feasible nodes. To give all nodes a fair chance of being evaluated, in each scheduling cycle, the scheduler starts evaluating from where it left off in the previous cycle. This is captured by the parameter in  We need to add a unit test that captures regressions related to this behavior to avoid bugs like /sig scheduling /priority important-soon /help
/assign
/remove-help

// are found. workqueue.ParallelizeUntil(ctx, 16, allNodes, checkNode) processedNodes := int(filteredLen) + len(filteredNodesStatuses) + len(failedPredicateMap) <del> g.lastProcessedNodeIndex = (g.lastProcessedNodeIndex + processedNodes) % allNodes </del> <ins> g.nextStartNodeIndex = (g.nextStartNodeIndex + processedNodes) % allNodes </ins> filtered = filtered[:filteredLen] if err := errCh.ReceiveError(); err != nil {


Question:
What would you like to be : A unit test that verifies the evaluation order of the nodes in the scheduler. Why is this needed: The scheduler evaluates the nodes in a specific order until it finds a pre-defined minimum number of feasible nodes. To give all nodes a fair chance of being evaluated, in each scheduling cycle, the scheduler starts evaluating from where it left off in the previous cycle. This is captured by the parameter in  We need to add a unit test that captures regressions related to this behavior to avoid bugs like /sig scheduling /priority important-soon /help
/assign
/remove-help

} } } <ins> func TestFairEvaluationForNodes(t *testing.T) { defer algorithmpredicates.SetPredicatesOrderingDuringTest(order)() predicates := map[string]algorithmpredicates.FitPredicate{"true": truePredicate} numAllNodes := 500 nodeNames := make([]string, 0, numAllNodes) for i := 0; i < numAllNodes; i++ { nodeNames = append(nodeNames, strconv.Itoa(i)) } nodes := makeNodeList(nodeNames) g := makeScheduler(predicates, nodes) // To make numAllNodes % nodesToFind != 0 g.percentageOfNodesToScore = 30 nodesToFind := int(g.numFeasibleNodesToFind(int32(numAllNodes))) // Iterating over all nodes more than twice for i := 0; i < 2*(numAllNodes/nodesToFind+1); i++ { nodesThatFit, _, _, err := g.findNodesThatFit(context.Background(), framework.NewCycleState(), &v1.Pod{}) if err != nil { t.Errorf("unexpected error: %v", err) } if len(nodesThatFit) != nodesToFind { t.Errorf("got %d nodes filtered, want %d", len(nodesThatFit), nodesToFind) } if g.nextStartNodeIndex != (i+1)*nodesToFind%numAllNodes { t.Errorf("got %d lastProcessedNodeIndex, want %d", g.nextStartNodeIndex, (i+1)*nodesToFind%numAllNodes) } } } </ins>


Question:
<!-- 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: EndpointSlice for masters was not created after enabling EndpointSlice on a pre-existing cluster. Only those EndpointSlices managed by kube-controller-manager were created. What you expected to happen: EndpointSlice for masters should be created after enabling EndpointSlice on a pre-existing cluster, the same as the EndpointSlices managed by kube-controller-manager. How to reproduce it (as minimally and precisely as possible): kubeadm to create a cluster: the EndpointSlice feature by editing the kube-apiserver, kube-controller-manager, kube-proxy manifest kube-apiserver and kube-controller-manager is restarted, the EndpointSlice in namespace will be missing. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools:Network plugin and version (if this is a network-related bug): Others:
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
/remove-triage unresolved /assign

"//pkg/api/v1/endpoints:go_default_library", "//staging/src/k8s.io/api/core/v1:go_default_library", "//staging/src/k8s.io/api/discovery/v1alpha1:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/api/equality:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/api/errors:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/runtime:go_default_library",


Question:
<!-- 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: EndpointSlice for masters was not created after enabling EndpointSlice on a pre-existing cluster. Only those EndpointSlices managed by kube-controller-manager were created. What you expected to happen: EndpointSlice for masters should be created after enabling EndpointSlice on a pre-existing cluster, the same as the EndpointSlices managed by kube-controller-manager. How to reproduce it (as minimally and precisely as possible): kubeadm to create a cluster: the EndpointSlice feature by editing the kube-apiserver, kube-controller-manager, kube-proxy manifest kube-apiserver and kube-controller-manager is restarted, the EndpointSlice in namespace will be missing. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools:Network plugin and version (if this is a network-related bug): Others:
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
/remove-triage unresolved /assign

import ( corev1 "k8s.io/api/core/v1" discovery "k8s.io/api/discovery/v1alpha1" <ins> apiequality "k8s.io/apimachinery/pkg/api/equality" </ins> "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" corev1client "k8s.io/client-go/kubernetes/typed/core/v1"


Question:
<!-- 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: EndpointSlice for masters was not created after enabling EndpointSlice on a pre-existing cluster. Only those EndpointSlices managed by kube-controller-manager were created. What you expected to happen: EndpointSlice for masters should be created after enabling EndpointSlice on a pre-existing cluster, the same as the EndpointSlices managed by kube-controller-manager. How to reproduce it (as minimally and precisely as possible): kubeadm to create a cluster: the EndpointSlice feature by editing the kube-apiserver, kube-controller-manager, kube-proxy manifest kube-apiserver and kube-controller-manager is restarted, the EndpointSlice in namespace will be missing. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools:Network plugin and version (if this is a network-related bug): Others:
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
/remove-triage unresolved /assign

// returned. func (adapter *EndpointsAdapter) Create(namespace string, endpoints *corev1.Endpoints) (*corev1.Endpoints, error) { endpoints, err := adapter.endpointClient.Endpoints(namespace).Create(endpoints) <del> if err == nil && adapter.endpointSliceClient != nil { _, err = adapter.ensureEndpointSliceFromEndpoints(namespace, endpoints) </del> <ins> if err == nil { err = adapter.EnsureEndpointSliceFromEndpoints(namespace, endpoints) </ins> } return endpoints, err }


Question:
<!-- 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: EndpointSlice for masters was not created after enabling EndpointSlice on a pre-existing cluster. Only those EndpointSlices managed by kube-controller-manager were created. What you expected to happen: EndpointSlice for masters should be created after enabling EndpointSlice on a pre-existing cluster, the same as the EndpointSlices managed by kube-controller-manager. How to reproduce it (as minimally and precisely as possible): kubeadm to create a cluster: the EndpointSlice feature by editing the kube-apiserver, kube-controller-manager, kube-proxy manifest kube-apiserver and kube-controller-manager is restarted, the EndpointSlice in namespace will be missing. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools:Network plugin and version (if this is a network-related bug): Others:
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
/remove-triage unresolved /assign

// updated. The updated Endpoints object or an error will be returned. func (adapter *EndpointsAdapter) Update(namespace string, endpoints *corev1.Endpoints) (*corev1.Endpoints, error) { endpoints, err := adapter.endpointClient.Endpoints(namespace).Update(endpoints) <del> if err == nil && adapter.endpointSliceClient != nil { _, err = adapter.ensureEndpointSliceFromEndpoints(namespace, endpoints) </del> <ins> if err == nil { err = adapter.EnsureEndpointSliceFromEndpoints(namespace, endpoints) </ins> } return endpoints, err } <del> // ensureEndpointSliceFromEndpoints accepts a namespace and Endpoints resource // and creates or updates a corresponding EndpointSlice. The EndpointSlice // and/or an error will be returned. func (adapter *EndpointsAdapter) ensureEndpointSliceFromEndpoints(namespace string, endpoints *corev1.Endpoints) (*discovery.EndpointSlice, error) { </del> <ins> // EnsureEndpointSliceFromEndpoints accepts a namespace and Endpoints resource // and creates or updates a corresponding EndpointSlice if an endpointSliceClient // exists. An error will be returned if it fails to sync the EndpointSlice. func (adapter *EndpointsAdapter) EnsureEndpointSliceFromEndpoints(namespace string, endpoints *corev1.Endpoints) error { if adapter.endpointSliceClient == nil { return nil } </ins> endpointSlice := endpointSliceFromEndpoints(endpoints) <del> _, err := adapter.endpointSliceClient.EndpointSlices(namespace).Get(endpointSlice.Name, metav1.GetOptions{}) </del> <ins> currentEndpointSlice, err := adapter.endpointSliceClient.EndpointSlices(namespace).Get(endpointSlice.Name, metav1.GetOptions{}) </ins> if err != nil { if errors.IsNotFound(err) { <del> return adapter.endpointSliceClient.EndpointSlices(namespace).Create(endpointSlice) </del> <ins> if _, err = adapter.endpointSliceClient.EndpointSlices(namespace).Create(endpointSlice); errors.IsAlreadyExists(err) { err = nil } </ins> } <del> return nil, err </del> <ins> return err } if apiequality.Semantic.DeepEqual(currentEndpointSlice.Endpoints, endpointSlice.Endpoints) && apiequality.Semantic.DeepEqual(currentEndpointSlice.Ports, endpointSlice.Ports) && apiequality.Semantic.DeepEqual(currentEndpointSlice.Labels, endpointSlice.Labels) { return nil </ins> } <del> return adapter.endpointSliceClient.EndpointSlices(namespace).Update(endpointSlice) </del> <ins> _, err = adapter.endpointSliceClient.EndpointSlices(namespace).Update(endpointSlice) return err </ins> } // endpointSliceFromEndpoints generates an EndpointSlice from an Endpoints


Question:
<!-- 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: EndpointSlice for masters was not created after enabling EndpointSlice on a pre-existing cluster. Only those EndpointSlices managed by kube-controller-manager were created. What you expected to happen: EndpointSlice for masters should be created after enabling EndpointSlice on a pre-existing cluster, the same as the EndpointSlices managed by kube-controller-manager. How to reproduce it (as minimally and precisely as possible): kubeadm to create a cluster: the EndpointSlice feature by editing the kube-apiserver, kube-controller-manager, kube-proxy manifest kube-apiserver and kube-controller-manager is restarted, the EndpointSlice in namespace will be missing. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools:Network plugin and version (if this is a network-related bug): Others:
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
/remove-triage unresolved /assign

Subsets:    []corev1.EndpointSubset{subset}, }, epSlice } <ins> func TestEndpointsAdapterEnsureEndpointSliceFromEndpoints(t *testing.T) { endpoints1, epSlice1 := generateEndpointsAndSlice("foo", "testing", []int{80, 443}, []string{"10.1.2.3", "10.1.2.4"}) endpoints2, epSlice2 := generateEndpointsAndSlice("foo", "testing", []int{80, 443}, []string{"10.1.2.3", "10.1.2.4", "10.1.2.5"}) testCases := map[string]struct { endpointSlicesEnabled bool expectedError         error expectedEndpointSlice *discovery.EndpointSlice endpointSlices        []*discovery.EndpointSlice namespaceParam        string endpointsParam        *corev1.Endpoints }{ "existing-endpointslice-no-change": { endpointSlicesEnabled: true, expectedError:         nil, expectedEndpointSlice: epSlice1, endpointSlices:        []*discovery.EndpointSlice{epSlice1}, namespaceParam:        "testing", endpointsParam:        endpoints1, }, "existing-endpointslice-change": { endpointSlicesEnabled: true, expectedError:         nil, expectedEndpointSlice: epSlice2, endpointSlices:        []*discovery.EndpointSlice{epSlice1}, namespaceParam:        "testing", endpointsParam:        endpoints2, }, "missing-endpointslice": { endpointSlicesEnabled: true, expectedError:         nil, expectedEndpointSlice: epSlice1, endpointSlices:        []*discovery.EndpointSlice{}, namespaceParam:        "testing", endpointsParam:        endpoints1, }, "endpointslices-disabled": { endpointSlicesEnabled: false, expectedError:         nil, expectedEndpointSlice: nil, endpointSlices:        []*discovery.EndpointSlice{}, namespaceParam:        "testing", endpointsParam:        endpoints1, }, } for name, testCase := range testCases { t.Run(name, func(t *testing.T) { client := fake.NewSimpleClientset() epAdapter := EndpointsAdapter{endpointClient: client.CoreV1()} if testCase.endpointSlicesEnabled { epAdapter.endpointSliceClient = client.DiscoveryV1alpha1() } for _, endpointSlice := range testCase.endpointSlices { _, err := client.DiscoveryV1alpha1().EndpointSlices(endpointSlice.Namespace).Create(endpointSlice) if err != nil { t.Fatalf("Error creating EndpointSlice: %v", err) } } err := epAdapter.EnsureEndpointSliceFromEndpoints(testCase.namespaceParam, testCase.endpointsParam) if !apiequality.Semantic.DeepEqual(testCase.expectedError, err) { t.Errorf("Expected error: %v, got: %v", testCase.expectedError, err) } endpointSlice, err := client.DiscoveryV1alpha1().EndpointSlices(testCase.namespaceParam).Get(testCase.endpointsParam.Name, metav1.GetOptions{}) if err != nil && !errors.IsNotFound(err) { t.Fatalf("Error getting Endpoint Slice: %v", err) } if !apiequality.Semantic.DeepEqual(endpointSlice, testCase.expectedEndpointSlice) { t.Errorf("Expected Endpoint Slice: %v, got: %v", testCase.expectedEndpointSlice, endpointSlice) } }) } } </ins>


Question:
<!-- 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: EndpointSlice for masters was not created after enabling EndpointSlice on a pre-existing cluster. Only those EndpointSlices managed by kube-controller-manager were created. What you expected to happen: EndpointSlice for masters should be created after enabling EndpointSlice on a pre-existing cluster, the same as the EndpointSlices managed by kube-controller-manager. How to reproduce it (as minimally and precisely as possible): kubeadm to create a cluster: the EndpointSlice feature by editing the kube-apiserver, kube-controller-manager, kube-proxy manifest kube-apiserver and kube-controller-manager is restarted, the EndpointSlice in namespace will be missing. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools:Network plugin and version (if this is a network-related bug): Others:
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
/remove-triage unresolved /assign

// Next, we compare the current list of endpoints with the list of master IP keys formatCorrect, ipCorrect, portsCorrect := checkEndpointSubsetFormatWithLease(e, masterIPs, endpointPorts, reconcilePorts) if formatCorrect && ipCorrect && portsCorrect { <del> return nil </del> <ins> return r.epAdapter.EnsureEndpointSliceFromEndpoints(corev1.NamespaceDefault, e) </ins> } if !formatCorrect {


Question:
<!-- 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: EndpointSlice for masters was not created after enabling EndpointSlice on a pre-existing cluster. Only those EndpointSlices managed by kube-controller-manager were created. What you expected to happen: EndpointSlice for masters should be created after enabling EndpointSlice on a pre-existing cluster, the same as the EndpointSlices managed by kube-controller-manager. How to reproduce it (as minimally and precisely as possible): kubeadm to create a cluster: the EndpointSlice feature by editing the kube-apiserver, kube-controller-manager, kube-proxy manifest kube-apiserver and kube-controller-manager is restarted, the EndpointSlice in namespace will be missing. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools:Network plugin and version (if this is a network-related bug): Others:
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry.
/remove-triage unresolved /assign

return err } if ipCorrect && portsCorrect { <del> return nil </del> <ins> return r.epAdapter.EnsureEndpointSliceFromEndpoints(metav1.NamespaceDefault, e) </ins> } if !ipCorrect { // We *always* add our own IP address.


Question:
What happened: Housekeeping sync loop finds an orphaned pod and tries to clean it up. The kubepod slice, as seen below, is not removed by with no indication as to why. This leads to the docker scope timing out and entering a failed state. The returned error(s) from runc are swallowed making debugging difficult. What you expected to happen: As per other areas of the sync loop, useful errors are logged at debug level due to the async calls. How to reproduce it (as minimally and precisely as possible): N/A Anything else we need to know?: N/A Environment: Kubernetes version (use ): master
/sig node
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Have you seen the comment above pcm.Destroy() call ? Did you have a chance to look at kubelet log to see if the above was true ?
/remove-lifecycle stale
This would give us some clue about the error:
yes, definitely looked! In this specific situation, the pods are never retried. What we see happen with these pods: ADD -RECONCILE -Started Volumes -Created slice -No sandbox for pod -Started libcontainer -ContainerStarted -ContainerStarted -RECONSILE -ContainerDied -RECONCILE -Unmounts -Killing unwanted pod -Orphaned removing pod cgroups -container kill failed because of 'container not found' or 'no such process' -cleanup: failed to unmount secrets -ContainerDied -Container garbage collection succeeded -SyncLoop (SYNC): 141 pods (including this one) -stopping timed out. Killing. -Stopped libcontainer -Removed slice -DELETE -REMOVE -err: pod not found Destroy all cgroups of the pod that should not be running, by first killing all the attached processes to these cgroups. We ignore errors thrown by the method, as the housekeeping loop would again try to delete these unwanted pod cgroups Despite running, the slice is not removed and we do not log or indicate why. Subsequently, the pod is NOT determined to be either an active pod or for some reason not in the cgroup list that is passed into kl.cleanupOrphanedPodCgroups(cgroupPods, activePods) during housekeeping loops. A more detailed look, which I believe is accurate ;): housekeepingCh -HandlePodCleanups -cgroupPods=UID+CGroupName=GetAllPodsFromCgroups -allPods=GetPodsAndMirrorPods -activePods=filterOutTerminatedPods -cleanupOrphanedPodCgroups I do not think desiredPods and runningPods are relevant here.. So either: a) the pod is not found and to allPods (seems unlikely) but we can't know for sure.. b) the pod is incorrectly determined to be active via activePods which again we can not determine.. Any pod that is not Failed, Succeeded or has a DeletionTimestamp set and a status of Terminated or Waiting - anything else returns false and is deemed active c) the pod cgroup is not found in m.subsystems.MountPoints and to cgroupPods - unlikely, but could be a bug but the root of this issue is the fact that all of the scopes and slices exist and keep building up until things start failing... GetAllPodsFromCgroups could use some logging... Maybe a V 5 log that prints out foundPods at the end... From there, they're passed into the cleanup: kl.cleanupOrphanedPodCgroups(cgroupPods, activePods) 1) All activePod UIDs are put into a podSet 2) A range loop of uid and cgroup name from cgroupPods looks to see if the uid from cgroupPods also exists in the podSet (active pods) 3) If the uid from cgroupPods exists in the podSet we skip out of the loop 4) If it doesn't, the pod is orphaned (not active w/ cgroups on the filesystem) and we call pcm.Destroy(val) on the cgroup name. Doesn't make sense why pcm.Destroy(val) ignores errors... it would be helpful! tryKillingCgroupProcesses logs any error and also returns the an error which is always swallowed.. we don't see any issues here More problematic, the call to cgroupManager.Destroy only returns an error which would be swallowed... Could probably use a similar level 3 log here like what you have for tryKillingCgroupProcesses because as you can see, were totally blind here...
your change is of a similar nature to what I proposed in my PR for this issue, just a level higher. I think there are a few areas noted above the could help further debug this.. Still haven't been able to get my PR merged with additional logging.
The following code was relatively new (compared to when you logged this issue):
Indeed... I looked into it a while ago and those changes are new via: - Could definitely make a different if the issue is related to pod getting filtered out from activePods when they have not been fully cleaned up yet on the subsequent housekeeping syncloop runs.
I think is promising, but I still think it makes sense to add some logging here. Do you want want to proceed with my open PR, your suggestion in or both?
You can proceed with your PR.

func (m *podContainerManagerImpl) Destroy(podCgroup CgroupName) error { // Try killing all the processes attached to the pod cgroup if err := m.tryKillingCgroupProcesses(podCgroup); err != nil { <del> klog.V(3).Infof("failed to kill all the processes attached to the %v cgroups", podCgroup) </del> <ins> klog.Warningf("failed to kill all the processes attached to the %v cgroups", podCgroup) </ins> return fmt.Errorf("failed to kill all the processes attached to the %v cgroups : %v", podCgroup, err) }


Question:
What happened: Housekeeping sync loop finds an orphaned pod and tries to clean it up. The kubepod slice, as seen below, is not removed by with no indication as to why. This leads to the docker scope timing out and entering a failed state. The returned error(s) from runc are swallowed making debugging difficult. What you expected to happen: As per other areas of the sync loop, useful errors are logged at debug level due to the async calls. How to reproduce it (as minimally and precisely as possible): N/A Anything else we need to know?: N/A Environment: Kubernetes version (use ): master
/sig node
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Have you seen the comment above pcm.Destroy() call ? Did you have a chance to look at kubelet log to see if the above was true ?
/remove-lifecycle stale
This would give us some clue about the error:
yes, definitely looked! In this specific situation, the pods are never retried. What we see happen with these pods: ADD -RECONCILE -Started Volumes -Created slice -No sandbox for pod -Started libcontainer -ContainerStarted -ContainerStarted -RECONSILE -ContainerDied -RECONCILE -Unmounts -Killing unwanted pod -Orphaned removing pod cgroups -container kill failed because of 'container not found' or 'no such process' -cleanup: failed to unmount secrets -ContainerDied -Container garbage collection succeeded -SyncLoop (SYNC): 141 pods (including this one) -stopping timed out. Killing. -Stopped libcontainer -Removed slice -DELETE -REMOVE -err: pod not found Destroy all cgroups of the pod that should not be running, by first killing all the attached processes to these cgroups. We ignore errors thrown by the method, as the housekeeping loop would again try to delete these unwanted pod cgroups Despite running, the slice is not removed and we do not log or indicate why. Subsequently, the pod is NOT determined to be either an active pod or for some reason not in the cgroup list that is passed into kl.cleanupOrphanedPodCgroups(cgroupPods, activePods) during housekeeping loops. A more detailed look, which I believe is accurate ;): housekeepingCh -HandlePodCleanups -cgroupPods=UID+CGroupName=GetAllPodsFromCgroups -allPods=GetPodsAndMirrorPods -activePods=filterOutTerminatedPods -cleanupOrphanedPodCgroups I do not think desiredPods and runningPods are relevant here.. So either: a) the pod is not found and to allPods (seems unlikely) but we can't know for sure.. b) the pod is incorrectly determined to be active via activePods which again we can not determine.. Any pod that is not Failed, Succeeded or has a DeletionTimestamp set and a status of Terminated or Waiting - anything else returns false and is deemed active c) the pod cgroup is not found in m.subsystems.MountPoints and to cgroupPods - unlikely, but could be a bug but the root of this issue is the fact that all of the scopes and slices exist and keep building up until things start failing... GetAllPodsFromCgroups could use some logging... Maybe a V 5 log that prints out foundPods at the end... From there, they're passed into the cleanup: kl.cleanupOrphanedPodCgroups(cgroupPods, activePods) 1) All activePod UIDs are put into a podSet 2) A range loop of uid and cgroup name from cgroupPods looks to see if the uid from cgroupPods also exists in the podSet (active pods) 3) If the uid from cgroupPods exists in the podSet we skip out of the loop 4) If it doesn't, the pod is orphaned (not active w/ cgroups on the filesystem) and we call pcm.Destroy(val) on the cgroup name. Doesn't make sense why pcm.Destroy(val) ignores errors... it would be helpful! tryKillingCgroupProcesses logs any error and also returns the an error which is always swallowed.. we don't see any issues here More problematic, the call to cgroupManager.Destroy only returns an error which would be swallowed... Could probably use a similar level 3 log here like what you have for tryKillingCgroupProcesses because as you can see, were totally blind here...
your change is of a similar nature to what I proposed in my PR for this issue, just a level higher. I think there are a few areas noted above the could help further debug this.. Still haven't been able to get my PR merged with additional logging.
The following code was relatively new (compared to when you logged this issue):
Indeed... I looked into it a while ago and those changes are new via: - Could definitely make a different if the issue is related to pod getting filtered out from activePods when they have not been fully cleaned up yet on the subsequent housekeeping syncloop runs.
I think is promising, but I still think it makes sense to add some logging here. Do you want want to proceed with my open PR, your suggestion in or both?
You can proceed with your PR.

ResourceParameters: &ResourceConfig{}, } if err := m.cgroupManager.Destroy(containerConfig); err != nil { <ins> klog.Warningf("failed to delete cgroup paths for %v : %v", podCgroup, err) </ins> return fmt.Errorf("failed to delete cgroup paths for %v : %v", podCgroup, err) } return nil


Question:
<!-- 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: It returns an error when I create a pod of yaml file over 1M. I checked the codes and found that the coded wrong. It should be “json.Unmarshal(p.patchBytes, &v)”, not “json.Unmarshal(p.patchBytes, v)” in the 344 and 368 line. What you expected to happen: It can be parsed correctly. How to reproduce it (as minimally and precisely as possible): Look at the code and you'll see or you can test it. Anything else we need to know?: no. Environment: Kubernetes version (use ): Community latest code Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/kind bug
/sig api-machinery
/assign

// TODO(liggitt): drop this once golang json parser limits stack depth (https://github.com/golang/go/issues/31789) if len(p.patchBytes) > 1024*1024 { v := []interface{}{} <del> if err := json.Unmarshal(p.patchBytes, v); err != nil { </del> <ins> if err := json.Unmarshal(p.patchBytes, &v); err != nil { </ins> return nil, errors.NewBadRequest(fmt.Sprintf("error decoding patch: %v", err)) } }


Question:
<!-- 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: It returns an error when I create a pod of yaml file over 1M. I checked the codes and found that the coded wrong. It should be “json.Unmarshal(p.patchBytes, &v)”, not “json.Unmarshal(p.patchBytes, v)” in the 344 and 368 line. What you expected to happen: It can be parsed correctly. How to reproduce it (as minimally and precisely as possible): Look at the code and you'll see or you can test it. Anything else we need to know?: no. Environment: Kubernetes version (use ): Community latest code Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/kind bug
/sig api-machinery
/assign

// TODO(liggitt): drop this once golang json parser limits stack depth (https://github.com/golang/go/issues/31789) if len(p.patchBytes) > 1024*1024 { v := map[string]interface{}{} <del> if err := json.Unmarshal(p.patchBytes, v); err != nil { </del> <ins> if err := json.Unmarshal(p.patchBytes, &v); err != nil { </ins> return nil, errors.NewBadRequest(fmt.Sprintf("error decoding patch: %v", err)) } }


Question:
<!-- 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: It returns an error when I create a pod of yaml file over 1M. I checked the codes and found that the coded wrong. It should be “json.Unmarshal(p.patchBytes, &v)”, not “json.Unmarshal(p.patchBytes, v)” in the 344 and 368 line. What you expected to happen: It can be parsed correctly. How to reproduce it (as minimally and precisely as possible): Look at the code and you'll see or you can test it. Anything else we need to know?: no. Environment: Kubernetes version (use ): Community latest code Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/kind bug
/sig api-machinery
/assign

t.Errorf("expected success or bad request err, got %v", err) } }) <ins> t.Run("JSONPatchType should handle a valid patch just under the max limit", func(t *testing.T) { patchBody := []byte(`[{"op":"add","path":"/foo","value":0` + strings.Repeat(" ", 3*1024*1024-100) + `}]`) err = rest.Patch(types.JSONPatchType).AbsPath(fmt.Sprintf("/api/v1/namespaces/default/secrets/test")). Body(patchBody).Do().Error() if err != nil { t.Errorf("unexpected error: %v", err) } }) </ins> t.Run("MergePatchType should handle a patch just under the max limit", func(t *testing.T) { patchBody := []byte(`{"value":` + strings.Repeat("[", 3*1024*1024/2-100) + strings.Repeat("]", 3*1024*1024/2-100) + `}`) err = rest.Patch(types.MergePatchType).AbsPath(fmt.Sprintf("/api/v1/namespaces/default/secrets/test")).


Question:
<!-- 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: It returns an error when I create a pod of yaml file over 1M. I checked the codes and found that the coded wrong. It should be “json.Unmarshal(p.patchBytes, &v)”, not “json.Unmarshal(p.patchBytes, v)” in the 344 and 368 line. What you expected to happen: It can be parsed correctly. How to reproduce it (as minimally and precisely as possible): Look at the code and you'll see or you can test it. Anything else we need to know?: no. Environment: Kubernetes version (use ): Community latest code Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/kind bug
/sig api-machinery
/assign

t.Errorf("expected success or bad request err, got %v", err) } }) <ins> t.Run("MergePatchType should handle a valid patch just under the max limit", func(t *testing.T) { patchBody := []byte(`{"value":0` + strings.Repeat(" ", 3*1024*1024-100) + `}`) err = rest.Patch(types.MergePatchType).AbsPath(fmt.Sprintf("/api/v1/namespaces/default/secrets/test")). Body(patchBody).Do().Error() if err != nil { t.Errorf("unexpected error: %v", err) } }) </ins> t.Run("StrategicMergePatchType should handle a patch just under the max limit", func(t *testing.T) { patchBody := []byte(`{"value":` + strings.Repeat("[", 3*1024*1024/2-100) + strings.Repeat("]", 3*1024*1024/2-100) + `}`) err = rest.Patch(types.StrategicMergePatchType).AbsPath(fmt.Sprintf("/api/v1/namespaces/default/secrets/test")).


Question:
<!-- 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: It returns an error when I create a pod of yaml file over 1M. I checked the codes and found that the coded wrong. It should be “json.Unmarshal(p.patchBytes, &v)”, not “json.Unmarshal(p.patchBytes, v)” in the 344 and 368 line. What you expected to happen: It can be parsed correctly. How to reproduce it (as minimally and precisely as possible): Look at the code and you'll see or you can test it. Anything else we need to know?: no. Environment: Kubernetes version (use ): Community latest code Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/kind bug
/sig api-machinery
/assign

t.Errorf("expected success or bad request err, got %v", err) } }) <ins> t.Run("StrategicMergePatchType should handle a valid patch just under the max limit", func(t *testing.T) { patchBody := []byte(`{"value":0` + strings.Repeat(" ", 3*1024*1024-100) + `}`) err = rest.Patch(types.StrategicMergePatchType).AbsPath(fmt.Sprintf("/api/v1/namespaces/default/secrets/test")). Body(patchBody).Do().Error() if err != nil { t.Errorf("unexpected error: %v", err) } }) </ins> t.Run("ApplyPatchType should handle a patch just under the max limit", func(t *testing.T) { patchBody := []byte(`{"value":` + strings.Repeat("[", 3*1024*1024/2-100) + strings.Repeat("]", 3*1024*1024/2-100) + `}`) err = rest.Patch(types.ApplyPatchType).Param("fieldManager", "test").AbsPath(fmt.Sprintf("/api/v1/namespaces/default/secrets/test")).


Question:
<!-- 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: It returns an error when I create a pod of yaml file over 1M. I checked the codes and found that the coded wrong. It should be “json.Unmarshal(p.patchBytes, &v)”, not “json.Unmarshal(p.patchBytes, v)” in the 344 and 368 line. What you expected to happen: It can be parsed correctly. How to reproduce it (as minimally and precisely as possible): Look at the code and you'll see or you can test it. Anything else we need to know?: no. Environment: Kubernetes version (use ): Community latest code Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/kind bug
/sig api-machinery
/assign

t.Errorf("expected success or bad request err, got %#v", err) } }) <ins> t.Run("ApplyPatchType should handle a valid patch just under the max limit", func(t *testing.T) { patchBody := []byte(`{"apiVersion":"v1","kind":"Secret"` + strings.Repeat(" ", 3*1024*1024-100) + `}`) err = rest.Patch(types.ApplyPatchType).Param("fieldManager", "test").AbsPath(fmt.Sprintf("/api/v1/namespaces/default/secrets/test")). Body(patchBody).Do().Error() if err != nil { t.Errorf("unexpected error: %v", err) } }) </ins> t.Run("Delete should limit the request body size", func(t *testing.T) { err = c.Delete().AbsPath(fmt.Sprintf("/api/v1/namespaces/default/secrets/test")). Body(hugeData).Do().Error()


Question:
What happened: While testing out the flag, I created a manifest with the following contents: I ran , and the resources appeared on my minikube cluster: Then, I removed the deployment from the manifest: And re-ran the same command, . To my surprise, however, the deployment wasn't removed; the only output from kubectl was . What you expected to happen: I expected the pruner to find the deployment with the matching label, , and prune it. How to reproduce it (as minimally and precisely as possible): I believe my example above is minimal and easily reproducible. Anything else we need to know?: This small change to the code for resolves the issue: Environment: Kubernetes version (use ): v1.16.3 Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
/sig cli
/assign cc

} } <ins> // Enforce CLI specified namespace on server request. if o.EnforceNamespace { o.VisitedNamespaces.Insert(o.Namespace) } </ins> // Generates the objects using the resource builder if they have not // already been stored by calling "SetObjects()" in the pre-processor. infos, err := o.GetObjects()


Question:
What happened: While testing out the flag, I created a manifest with the following contents: I ran , and the resources appeared on my minikube cluster: Then, I removed the deployment from the manifest: And re-ran the same command, . To my surprise, however, the deployment wasn't removed; the only output from kubectl was . What you expected to happen: I expected the pruner to find the deployment with the matching label, , and prune it. How to reproduce it (as minimally and precisely as possible): I believe my example above is minimal and easily reproducible. Anything else we need to know?: This small change to the code for resolves the issue: Environment: Kubernetes version (use ): v1.16.3 Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
/sig cli
/assign cc

} if errors.IsConflict(err) { err = fmt.Errorf(`%v Please review the fields above--they currently have other managers. Here are the ways you can resolve this warning: * If you intend to manage all of these fields, please re-run the apply


Question:
What happened: While testing out the flag, I created a manifest with the following contents: I ran , and the resources appeared on my minikube cluster: Then, I removed the deployment from the manifest: And re-ran the same command, . To my surprise, however, the deployment wasn't removed; the only output from kubectl was . What you expected to happen: I expected the pruner to find the deployment with the matching label, , and prune it. How to reproduce it (as minimally and precisely as possible): I believe my example above is minimal and easily reproducible. Anything else we need to know?: This small change to the code for resolves the issue: Environment: Kubernetes version (use ): v1.16.3 Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
/sig cli
/assign cc

* You may co-own fields by updating your manifest to match the existing value; in this case, you'll become the manager if the other manager(s) stop managing the field (remove it from their configuration). See http://k8s.io/docs/reference/using-api/api-concepts/#conflicts`, err) } return err


Question:
What happened: While testing out the flag, I created a manifest with the following contents: I ran , and the resources appeared on my minikube cluster: Then, I removed the deployment from the manifest: And re-ran the same command, . To my surprise, however, the deployment wasn't removed; the only output from kubectl was . What you expected to happen: I expected the pruner to find the deployment with the matching label, , and prune it. How to reproduce it (as minimally and precisely as possible): I believe my example above is minimal and easily reproducible. Anything else we need to know?: This small change to the code for resolves the issue: Environment: Kubernetes version (use ): v1.16.3 Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
/sig cli
/assign cc

} } <ins> func TestApplyPruneObjects(t *testing.T) { cmdtesting.InitTestErrorHandler(t) nameRC, currentRC := readAndAnnotateReplicationController(t, filenameRC) pathRC := "/namespaces/test/replicationcontrollers/" + nameRC for _, fn := range testingOpenAPISchemaFns { t.Run("test apply returns correct output", func(t *testing.T) { tf := cmdtesting.NewTestFactory().WithNamespace("test") defer tf.Cleanup() tf.UnstructuredClient = &fake.RESTClient{ NegotiatedSerializer: resource.UnstructuredPlusDefaultContentConfig().NegotiatedSerializer, Client: fake.CreateHTTPClient(func(req *http.Request) (*http.Response, error) { switch p, m := req.URL.Path, req.Method; { case p == pathRC && m == "GET": bodyRC := ioutil.NopCloser(bytes.NewReader(currentRC)) return &http.Response{StatusCode: http.StatusOK, Header: cmdtesting.DefaultHeader(), Body: bodyRC}, nil case p == pathRC && m == "PATCH": validatePatchApplication(t, req) bodyRC := ioutil.NopCloser(bytes.NewReader(currentRC)) return &http.Response{StatusCode: http.StatusOK, Header: cmdtesting.DefaultHeader(), Body: bodyRC}, nil default: t.Fatalf("unexpected request: %#vn%#v", req.URL, req) return nil, nil } }), } tf.OpenAPISchemaFunc = fn tf.ClientConfigVal = cmdtesting.DefaultClientConfig() ioStreams, _, buf, errBuf := genericclioptions.NewTestIOStreams() cmd := NewCmdApply("kubectl", tf, ioStreams) cmd.Flags().Set("filename", filenameRC) cmd.Flags().Set("prune", "true") cmd.Flags().Set("namespace", "test") cmd.Flags().Set("output", "yaml") cmd.Flags().Set("all", "true") cmd.Run(cmd, []string{}) if !strings.Contains(buf.String(), "test-rc") { t.Fatalf("unexpected output: %snexpected to contain: %s", buf.String(), "test-rc") } if errBuf.String() != "" { t.Fatalf("unexpected error output: %s", errBuf.String()) } }) } } </ins> func TestApplyObjectOutput(t *testing.T) { cmdtesting.InitTestErrorHandler(t) nameRC, currentRC := readAndAnnotateReplicationController(t, filenameRC)


Question:
<!-- 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: When trying to use the webhookConversionServer, im getting . I was able to figure out that the unicode character displayed maps to port 443. see code What you expected to happen: If the service reference doesnt define 443, it should show an error that the service doesnt have the port number (whatever the number may be). How to reproduce it (as minimally and precisely as possible): your service (missing the default port 443) your CRD (one version no conversion webhook) your resource at this old version crd with new version and conversion webhook, and use new version for storage. to get the resource yaml, and see error Anything else we need to know?: current implementation will convert port number into a unicode character. ie. im seeing where . Must use instead of to maintain decimal. Environment: Kubernetes version (use ): v1.15.4+IKS Cloud provider or hardware configuration: IBM IKS OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig api-machinery
Are you planning to send out a PR ?
i was going to.. but didnt know which repo was relevant and didnt feel like reading through all contibution gorp.
Created a PR to fix the message output.

return &svcPort, nil } } <del> return nil, errors.NewServiceUnavailable(fmt.Sprintf("no service port %q found for service %q", port, svc.Name)) </del> <ins> return nil, errors.NewServiceUnavailable(fmt.Sprintf("no service port %d found for service %q", port, svc.Name)) </ins> } // ResourceLocation returns a URL to which one can send traffic for the specified service.


Question:
<!-- 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: Azure cloud provider is sending unexpected LoadBalancer update requests even if the LoadBalancer rules are already identical. The reason is GetIdleTimeout() returns nil when the annotation is not set While find rule doens't check whether it is nil or not. What you expected to happen: Azure cloud provider shouldn't send unexpected LoadBalancer updates. It is easily to get throttled if there're too many services running on the cluster. How to reproduce it (as minimally and precisely as possible): kubectl annotate service nginx testlabel=value Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /area provider/azure /assign
/sig cloud-provider

reflect.DeepEqual(s.EnableTCPReset, t.EnableTCPReset) && reflect.DeepEqual(s.DisableOutboundSnat, t.DisableOutboundSnat) <del> if wantLB { </del> <ins> if wantLB && s.IdleTimeoutInMinutes != nil && t.IdleTimeoutInMinutes != nil { </ins> return properties && reflect.DeepEqual(s.IdleTimeoutInMinutes, t.IdleTimeoutInMinutes) } return properties


Question:
<!-- 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: Azure cloud provider is sending unexpected LoadBalancer update requests even if the LoadBalancer rules are already identical. The reason is GetIdleTimeout() returns nil when the annotation is not set While find rule doens't check whether it is nil or not. What you expected to happen: Azure cloud provider shouldn't send unexpected LoadBalancer updates. It is easily to get throttled if there're too many services running on the cluster. How to reproduce it (as minimally and precisely as possible): kubectl annotate service nginx testlabel=value Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /kind bug /area provider/azure /assign
/sig cloud-provider

expected: false, }, { <ins> msg: "rule names match while idletimeout unmatch should return false", existingRule: []network.LoadBalancingRule{ { Name: to.StringPtr("httpRule"), LoadBalancingRulePropertiesFormat: &network.LoadBalancingRulePropertiesFormat{ IdleTimeoutInMinutes: to.Int32Ptr(1), }, }, }, curRule: network.LoadBalancingRule{ Name: to.StringPtr("httpRule"), LoadBalancingRulePropertiesFormat: &network.LoadBalancingRulePropertiesFormat{ IdleTimeoutInMinutes: to.Int32Ptr(2), }, }, expected: false, }, { msg: "rule names match while idletimeout nil should return true", existingRule: []network.LoadBalancingRule{ { Name:                              to.StringPtr("httpRule"), LoadBalancingRulePropertiesFormat: &network.LoadBalancingRulePropertiesFormat{}, }, }, curRule: network.LoadBalancingRule{ Name: to.StringPtr("httpRule"), LoadBalancingRulePropertiesFormat: &network.LoadBalancingRulePropertiesFormat{ IdleTimeoutInMinutes: to.Int32Ptr(2), }, }, expected: true, }, { </ins> msg: "rule names match while LoadDistribution unmatch should return false", existingRule: []network.LoadBalancingRule{ {


Question:
If you give a prerelease version to , it'll match both and . Based on this logic: We'll end up trying to pull binaries for this prerelease from the CI bucket () rather than the release bucket (). These pre-release versions are usually* pushed to the release bucket as part of the release process (e.g. ), and so should probably prefer these over the CI versions (which may or may not exist, depending on whether a commit was pushed to the release branch between when the tag was created and the build occurred). More explicitly, the current logic is: the release bucket by default. a version matches the CI regex, use the CI bucket. , if a version matches the release regex, we're good - continue to use the default (release bucket). , bail out - invalid version. The correct logic would probably be something like the release bucket by default. a version matches the release version regex, continue to use the release bucket. , if a version doesn't match the release version regex, but it matches the CI regex, use the CI bucket. it matches neither, bail out. Important note: due to our hotfix for , there is a somewhat fake prerelease tag () which doesn't have any bits in the release bucket, and we expect others soon. We should not fix this bug in until the latest pointers in the CI bucket do not point to valid release/prerelease versions.
/sig testing /sig release I guess?
/area release-eng /priority critical-urgent /assign /milestone v1.18
Hello With code freeze approaching for 1.18 (5 March), can you please check if the current issue is still intended for milestone 1.18?
-- I'm pretty sure I can get to this before the cycle is out.
if our current approach for tagging release branch pre-releases doesn't trigger this, this seems like it is not critical for the milestone, is that correct?
-- Good point! /milestone v1.19 /remove-priority critical-urgent /priority important-soon
Given the priority dip on this one, I think it's fine for someone in Releng other than Tim or I to pick this up. /unassign -- This is a good one to work on. /help
I can look that, after the release 1.18, if is that fine then can we have a short discussion about this one? /remove-help /assign
-- SGTM

# Translate a published version <bucket>/<version> (e.g. "release/stable") to version number. set_binary_version "${release}" if [[ -z "${KUBERNETES_SKIP_RELEASE_VALIDATION-}" ]]; then <del> if [[ ${KUBE_VERSION} =~ ${KUBE_CI_VERSION_REGEX} ]]; then </del> <ins> if [[ ${KUBE_VERSION} =~ ${KUBE_RELEASE_VERSION_REGEX} ]]; then # Use KUBERNETES_RELEASE_URL for Releases and Pre-Releases # ie. 1.18.0 or 1.19.0-beta.0 KUBERNETES_RELEASE_URL="${KUBERNETES_RELEASE_URL}" elif [[ ${KUBE_VERSION} =~ ${KUBE_CI_VERSION_REGEX} ]]; then </ins> # Override KUBERNETES_RELEASE_URL to point to the CI bucket; # this will be used by get-kube-binaries.sh. <ins> # ie. v1.19.0-beta.0.318+b618411f1edb98 </ins> KUBERNETES_RELEASE_URL="${KUBERNETES_CI_RELEASE_URL}" <del> elif ! [[ ${KUBE_VERSION} =~ ${KUBE_RELEASE_VERSION_REGEX} ]]; then </del> <ins> else </ins> echo "Version doesn't match regexp" >&2 exit 1 fi


Question:
What would you like to be : There are many useful scripts in "". For example, I often use and for creating simple k8s cluster quickly. However, there are only few explanation or nothing how to use it. I think it becomes more useful and helpful if some instruction or guidance is explained in each script. Why is this needed: It aims and expects to increase new k8s developers by describing how to use each script. My proposal Add the following description under the copyright for each script file. Overview of the script Simple usage Supplementary explanation(This is option) Other concern I would like to know the purpose of use about hack directory. (e.g. Where to put tools for developers(therefore there is no guidance?).)
I don't know who is in charge of each scripts of hack, but if he agrees the idea of this feature request , I am going to do this task myself!!
/sig testing
I believe there is a script generating swagger/openapi specfilters under hack, but I am still struggling with it. It could be of great help if there is some how-to doc for each scripts.
this basis, why not create a file under the hack folder, because a lot of kk CIs are derived from multiple script commands under the hack. There are already 268+ files under the hack file. For contributors unfamiliar with these, these comments and instructions are helpful to them, and it is also helpful for new contributors to handle pr ci error reports.
/cc What do you think
I think it's good idea to create (It may be easy to understand if the script's explanation is described by category or use in ) Apart from that, it is helpful that the script file itself has a brief description.
When we create , it may tough work if creating it including all scripts explanation at one time. (There are many scripts and I understand only some scripts now.) Regarding , current my idea is to add a description to each script little by little and update the at the same time. This means that will be completed little by little in conjunction with adding the description of each script. In the future, if someone create new script in hack, he also may have to add description of his script into
Self-documenting commands sound useful. A high level overview also sounds useful.
/cc /cc Regarding adding help information, I suggest that we can submit pr in one or several files as a unit, so that we can track and statistics. For the documentation, I think it should be concise and not too long. How about this advice? We can claim tasks through , the pr title yes , i agree with you. [x] kubernetes/hack/benchmark- [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] kubernetes/hack/boilerplate/BUILD [ ] kubernetes/hack/boilerplate/test/BUILD [ ] [ ] [ ] [ ] [ ] kubernetes/hack/BUILD [x] kubernetes/hack/build- [x] kubernetes/hack/build- [x] [ ] kubernetes/hack/conformance/BUILD [ ] [x] kubernetes/hack/dev-build-and- [x] kubernetes/hack/dev-build-and- [x] kubernetes/hack/dev-push- [ ] kubernetes/hack/e2e-internal/BUILD [ ] kubernetes/hack/e2e-internal/e2e-cluster- [ ] kubernetes/hack/e2e-internal/e2e- [ ] kubernetes/hack/e2e-internal/e2e-grow- [ ] kubernetes/hack/e2e-internal/e2e-shrink- [ ] kubernetes/hack/e2e-internal/e2e- [ ] kubernetes/hack/e2e-internal/e2e- [x] kubernetes/hack/e2e-node- [ ] kubernetes/hack/generate- [x] kubernetes/hack/generate- [ ] kubernetes/hack/gen-swagger-doc/gen-swagger- [x] kubernetes/hack/get- [x] kubernetes/hack/ginkgo- [x] kubernetes/hack/grab- [x] kubernetes/hack/install- [ ] kubernetes/hack/jenkins/benchmark- [ ] kubernetes/hack/jenkins/OWNERS [ ] [ ] kubernetes/hack/jenkins/test- [ ] kubernetes/hack/jenkins/verify- [ ] kubernetes/hack/lib/BUILD [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [ ] [x] kubernetes/hack/lint- [x] kubernetes/hack/list-feature- [x] kubernetes/hack/local-up- [ ] kubernetes/hack/make-rules/BUILD [ ] kubernetes/hack/make- [ ] kubernetes/hack/make- [ ] kubernetes/hack/make- [ ] kubernetes/hack/make- [ ] kubernetes/hack/make-rules/helpers/go2make/BUILD [ ] kubernetes/hack/make- [ ] kubernetes/hack/make- [ ] kubernetes/hack/make- [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with- [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with- [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/skipme/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/skipme/subsubdir/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/skipme/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/subdir/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/testdata/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/testdata/subsubdir/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/testdata/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/underscore/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/underscore/subsubdir/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/underscore/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-with-gofiles/README [ ] kubernetes/hack/make-rules/helpers/go2make/testdata/dir-without-gofiles/README [ ] kubernetes/hack/make-rules/Makefile.manifest [ ] kubernetes/hack/make-rules/make- [ ] kubernetes/hack/make-rules/test- [ ] kubernetes/hack/make-rules/test-e2e- [ ] kubernetes/hack/make-rules/test-e2e- [x] kubernetes/hack/make-rules/test- [ ] kubernetes/hack/make- [ ] kubernetes/hack/make- [ ] kubernetes/hack/make- [ ] kubernetes/hack/make- [ ] kubernetes/hack/OWNERS [x] kubernetes/hack/pin- [x] kubernetes/hack/print-workspace- [x] kubernetes/hack/run-in- [ ] kubernetes/hack/testdata/auth- [x] [x] [x] kubernetes/hack/testdata/CRD/foo-- [x] kubernetes/hack/testdata/CRD/foo-deleted- [x] kubernetes/hack/testdata/CRD/foo-updated- [x] [x] kubernetes/hack/testdata/CRD/multi-crd-list-- [x] kubernetes/hack/testdata/CRD/multi-crd-list-deleted- [x] kubernetes/hack/testdata/CRD/multi-crd-list-updated- [x] kubernetes/hack/testdata/CRD/multi-crd- [x] [x] [x] kubernetes/hack/testdata/deployment-label- [x] kubernetes/hack/testdata/deployment-label- [x] kubernetes/hack/testdata/deployment-label- [x] kubernetes/hack/testdata/deployment-multicontainer- [x] kubernetes/hack/testdata/deployment- [x] kubernetes/hack/testdata/deployment- [x] kubernetes/hack/testdata/deployment- [x] kubernetes/hack/testdata/deployment-with- [x] [x] [x] [x] [x] [x] kubernetes/hack/testdata/filter/pod-apply- [x] kubernetes/hack/testdata/filter/pod-dont- [x] kubernetes/hack/testdata/frontend- [x] kubernetes/hack/testdata/frontend- [x] kubernetes/hack/testdata/invalid-rc-with-empty- [x] kubernetes/hack/testdata/kubernetes- [x] [x] [x] [x] [x] [ ] kubernetes/hack/testdata/multi-resource- [ ] kubernetes/hack/testdata/multi-resource-json- [ ] kubernetes/hack/testdata/multi-resource- [ ] kubernetes/hack/testdata/multi-resource-list- [ ] kubernetes/hack/testdata/multi-resource- [ ] kubernetes/hack/testdata/multi-resource-rclist- [ ] kubernetes/hack/testdata/multi-resource- [ ] kubernetes/hack/testdata/multi-resource-svclist- [x] kubernetes/hack/testdata/multi-resource-yaml- [x] kubernetes/hack/testdata/multi-resource- [x] kubernetes/hack/testdata/null-propagation/deployment- [x] kubernetes/hack/testdata/null-propagation/deployment- [x] kubernetes/hack/testdata/OWNERS [x] kubernetes/hack/testdata/pod- [x] kubernetes/hack/testdata/pod- [x] kubernetes/hack/testdata/pod-with-api- [x] kubernetes/hack/testdata/pod-with-large- [x] kubernetes/hack/testdata/pod-with- [x] [x] [x] [x] [x] kubernetes/hack/testdata/prune- [x] kubernetes/hack/testdata/prune- [x] kubernetes/hack/testdata/recursive/deployment/deployment/nginx- [x] [x] [x] [x] [x] kubernetes/hack/testdata/recursive/pod/pod/busybox- [x] [x] [x] kubernetes/hack/testdata/recursive/pod- [x] kubernetes/hack/testdata/recursive/pod-modify/pod/busybox- [x] kubernetes/hack/testdata/recursive/pod- [x] kubernetes/hack/testdata/recursive/pod- [x] [x] kubernetes/hack/testdata/recursive/rc/rc/busybox- [x] [x] [x] kubernetes/hack/testdata/redis-slave- [x] kubernetes/hack/testdata/retainKeys/deployment/deployment- [x] kubernetes/hack/testdata/retainKeys/deployment/deployment- [x] kubernetes/hack/testdata/rollingupdate-daemonset- [x] kubernetes/hack/testdata/rollingupdate- [x] kubernetes/hack/testdata/rollingupdate-statefulset- [x] kubernetes/hack/testdata/rollingupdate- [x] kubernetes/hack/testdata/scale-deploy-1.yaml [x] kubernetes/hack/testdata/scale-deploy-2.yaml [x] kubernetes/hack/testdata/scale-deploy-3.yaml [x] [x] kubernetes/hack/testdata/service- [x] kubernetes/hack/testdata/service- [x] kubernetes/hack/testdata/sorted-pods/sorted- [x] kubernetes/hack/testdata/sorted-pods/sorted- [x] kubernetes/hack/testdata/sorted-pods/sorted- [ ] [ ] [x] kubernetes/hack/test- [ ] kubernetes/hack/test- [x] kubernetes/hack/update- [ ] kubernetes/hack/update- [x] kubernetes/hack/update- [ ] kubernetes/hack/update-generated-api-compatibility- [x] kubernetes/hack/update-generated-device-plugin- [ ] kubernetes/hack/update-generated-device- [ ] kubernetes/hack/update-generated- [ ] kubernetes/hack/update-generated-kms- [ ] kubernetes/hack/update-generated- [x] kubernetes/hack/update-generated-kubelet-plugin-registration- [ ] kubernetes/hack/update-generated-kubelet-plugin- [x] kubernetes/hack/update-generated-pod-resources- [ ] kubernetes/hack/update-generated-pod- [ ] kubernetes/hack/update-generated-protobuf- [ ] kubernetes/hack/update-generated- [ ] kubernetes/hack/update-generated-runtime- [ ] kubernetes/hack/update-generated- [ ] kubernetes/hack/update-generated-swagger- [x] kubernetes/hack/update- [x] kubernetes/hack/update-import- [ ] kubernetes/hack/update-openapi- [x] kubernetes/hack/update- [ ] kubernetes/hack/update-vendor- [ ] kubernetes/hack/update- [ ] kubernetes/hack/update-workspace- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify-api- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify-cli- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify-conformance- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify-external-dependencies- [ ] kubernetes/hack/verify-flags/excluded- [x] kubernetes/hack/verify-flags/OWNERS [x] kubernetes/hack/OWNERS [ ] kubernetes/hack/verify-flags- [x] kubernetes/hack/verify-generated-device- [x] kubernetes/hack/verify-generated- [x] kubernetes/hack/verify-generated-files- [x] kubernetes/hack/verify-generated- [x] kubernetes/hack/verify-generated- [x] kubernetes/hack/verify-generated-kubelet-plugin- [x] kubernetes/hack/verify-generated-pod- [x] kubernetes/hack/verify-generated- [x] kubernetes/hack/verify-generated- [x] kubernetes/hack/verify-generated-swagger- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify-import- [x] kubernetes/hack/verify-import- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify-no-vendor- [x] kubernetes/hack/verify-openapi- [x] kubernetes/hack/verify-pkg- [x] kubernetes/hack/verify-publishing- [x] kubernetes/hack/verify-readonly- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify-staging-meta- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify-test- [x] kubernetes/hack/verify-test- [x] kubernetes/hack/verify-test- [x] kubernetes/hack/verify-typecheck- [x] kubernetes/hack/verify- [x] kubernetes/hack/verify-vendor- [x] kubernetes/hack/verify- [x]
i will pick up , i will do it step by step.
I agree with your idea, and thanks the checkbox to check progress. there are many scripts, so let's work together!
/assign /assign
I will pick up hack/verify-
I will pick up hack/verify-
I will pick up hack/verify- (all of verify scripts). But there are large number of scripts(over 40), I want to split it into two or three PRs.
I will pick up hack/update-
I will pick up these scripts. kubernetes/hack/benchmark- kubernetes/hack/build- kubernetes/hack/build- kubernetes/hack/dev-build-and- kubernetes/hack/dev-build-and- kubernetes/hack/dev-push- kubernetes/hack/e2e-node- kubernetes/hack/generate-
I will pick up these scripts get- ginkgo- grab- install- lint- list-feature- local-up- pin- print-workspace- run-in- test- test-
How about this now? /help Marking this tag so that others can easily access it.
This request has been marked as needing help from a contributor. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : How about this now? /help Marking this tag so that others can easily access it. 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
I think we've finished adding simple explanations to the almost scripts. It seems that several scripts of update- does not complete yet. I think we may able to close after that work.
I will pick up these scripts:
/assign

# See the License for the specific language governing permissions and # limitations under the License. <ins> # This script generates `/pkg/kubelet/apis/podresources/v1alpha1/api.pb.go` # from the protobuf file `/pkg/kubelet/apis/podresources/v1alpha1/api.proto` # for pods. # Usage: `hack/update-generated-pod-resources.sh`. </ins> set -o errexit set -o nounset set -o pipefail