jiebi/CodeConvo huggingface dataset:
Change:
reportedLevels:      []uint64{100, 300, 500, 250, 250}, reportedCPURequests: []resource.Quantity{resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0"), resource.MustParse("1.0")}, useMetricsAPI:       true, <ins> recommendations:     []timestampedRecommendation{}, </ins> expectedConditions: []autoscalingv1.HorizontalPodAutoscalerCondition{ <del> {Type: autoscalingv1.AbleToScale, Status: v1.ConditionTrue, Reason: "ScaleDownStabilized"}, {Type: autoscalingv1.ScalingActive, Status: v1.ConditionTrue, Reason: "ValidMetricFound"}, {Type: autoscalingv1.ScalingLimited, Status: v1.ConditionFalse, Reason: "DesiredWithinRange"}, </del> <ins> {Type: autoscalingv1.AbleToScale, Status: v1.ConditionTrue, Reason: "SucceededGetScale"}, {Type: autoscalingv1.ScalingActive, Status: v1.ConditionFalse, Reason: "FailedGetExternalMetric"}, </ins> }, } _, _, _, testEMClient, _ := tc.prepareTestClient(t)

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --If you have 2 or more metrics defined on an HPA and one metric is suggesting to scale down and the other metric is unavailable, the HPA will scale down despite missing metrics. Example: Imagine the following Horizontal Pod Autoscaler resource: And the deployment is currently scaled to replicas. If the metric is suggesting to scale to 1 AND the metric is unavailable e.g. HPA can't fetch the metrics. Then it will happily scale down to despite not knowing what the currently unavailable metric would suggest. It's clearly stated in the docs the scale down should not happen if one or more metrics are unavailable: Until Kubernetes v1.15.x the behavior was as expected. However with the . The logic was removing the special handling of stopping scale down in case of unavailable metrics. 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: /bug /sig autoscaling
/triage accepted
Change:
"time" kubecontainer "k8s.io/kubernetes/pkg/kubelet/container" <del> containertest "k8s.io/kubernetes/pkg/kubelet/container/testing" </del> ) func testGetContainersToDeleteInPod(t *testing.T) {

Discussion:
Kubelet evicts pods whenever there is memory or disk pressure. It marks the pods as to evict them. To help with reducing disk pressure, kubelet should delete all containers belonging to pods right away. This will result in loss of logs. In the future, we can copy out logs from dead containers before deleting them. Logs can be rotated separately from dead containers. IMO, this feature is required for disk usage based evictions to work reliably in kubelet.
Change:
} func (ts *azureTokenSourceDeviceCode) Token() (*azureToken, error) { <del> oauthConfig, err := adal.NewOAuthConfig(ts.environment.ActiveDirectoryEndpoint, ts.tenantID) </del> <ins> oauthConfig, err := adal.NewOAuthConfigWithAPIVersion(ts.environment.ActiveDirectoryEndpoint, ts.tenantID, nil) </ins> if err != nil { return nil, fmt.Errorf("building the OAuth configuration for device code authentication: %v", err) }

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: In the to acquire AAD token, because of the inclusion of the API version in the URLs for authorization, the returned token is not compatible with many AAD scenarios like OIDC and On-Behalf-Of flow. There is a long list of issues documenting this problem: The fix is pretty simple, use with set to . This incompatible behavior impacts What you expected to happen: Follow the to acquire AAD token How to reproduce it (as minimally and precisely as possible): use kubectl to get AAD token, paste token into and verify the audience claim Anything else we need to know?: Environment: Kubernetes version (use ): all versions 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:
/area provider-azure
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /area provider-azure Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/area provider/azure
/sig cli
/sig cloud-provider
/assign
Change:
description:                "static policy - broken reservation", cpuPolicyName:              "static", nodeAllocatableReservation: v1.ResourceList{}, <del> panicMsg:                   "unable to determine reserved CPU resources for static policy", </del> <ins> expectedError:              fmt.Errorf("unable to determine reserved CPU resources for static policy"), </ins> skipIfPermissionsError:     true, }, { description:                "static policy - no CPU resources", cpuPolicyName:              "static", nodeAllocatableReservation: v1.ResourceList{v1.ResourceCPU: *resource.NewQuantity(0, resource.DecimalSI)}, <del> panicMsg:                   "the static policy requires systemreserved.cpu + kubereserved.cpu to be greater than zero", </del> <ins> expectedError:              fmt.Errorf("the static policy requires systemreserved.cpu + kubereserved.cpu to be greater than zero"), </ins> skipIfPermissionsError:     true, }, }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When enable cpumanager by , but not set and , kubelet will get panic error in log What you expected to happen: Should graceful exit with error not panic. How to reproduce it (as minimally and precisely as possible): set and but not set and Anything else we need to know?:
/sig node
Great that it's not panicing anymore, but I'd also love to get the "requires + to be greater than zero" hint in this particular case. It looks like even with this doesn't seem to be the case (since it errors out with the non-actionable "unable to determine reserved CPU resources for static policy". Should I open another issue for this?
Change:
registryBurst           = flag.Int("registry_burst", 10, "Maximum size of a bursty pulls, temporarily allows pulls to burst to this number, while still not exceeding registry_qps.  Only used if --registry_qps > 0") runonce                 = flag.Bool("runonce", false, "If true, exit after spawning pods from local manifests or remote urls. Exclusive with --etcd_servers and --enable-server") enableDebuggingHandlers = flag.Bool("enable_debugging_handlers", true, "Enables server endpoints for log collection and local running of containers and commands") <del> minimumGCAge            = flag.Duration("minimum_container_ttl_duration", 0, "Minimum age for a finished container before it is garbage collected.  Examples: '300ms', '10s' or '2h45m'") </del> <ins> minimumGCAge            = flag.Duration("minimum_container_ttl_duration", 1*time.Minute, "Minimum age for a finished container before it is garbage collected.  Examples: '300ms', '10s' or '2h45m'") </ins> maxContainerCount       = flag.Int("maximum_dead_containers_per_container", 5, "Maximum number of old instances of a container to retain per container.  Each container takes up some disk space.  Default: 5.") authPath                = flag.String("auth_path", "", "Path to .kubernetes_auth file, specifying how to authenticate to API server.") cAdvisorPort            = flag.Uint("cadvisor_port", 4194, "The port of the localhost cAdvisor endpoint")

Discussion:
Things like SyncFrequency should have a lower-bound of acceptable, and that really should be 0ns.
The main point of this is now fixed, though we could be better about input checking all over
Change:
cp ~/kube/init_scripts/* /etc/init.d/ groupadd -f -r kube-cert <del> ${PROXY_SETTING} ~/kube/make-ca-cert.sh "${MASTER_IP}" "${EXTRA_SANS}" </del> <ins> ${PROXY_SETTING} DEBUG='${DEBUG}' ~/kube/make-ca-cert.sh "${MASTER_IP}" "${EXTRA_SANS}" </ins> mkdir -p /opt/bin/ cp ~/kube/master/* /opt/bin/ service etcd start

Discussion:
cluster/saltbase/salt/generate-cert/make-ca- sets but does not echo what it is doing, so in the case of an error there is no evidence of which command produced the error.
Change:
if len(svc.Spec.Ports) > 0 { expectedFrontendIPCount++ expectedFrontendIP := ExpectedFrontendIPInfo{ <del> Name:   az.getFrontendIPConfigName(&svc, subnet(&svc)), </del> <ins> Name:   az.getFrontendIPConfigName(&svc), </ins> Subnet: subnet(&svc), } expectedFrontendIPs = append(expectedFrontendIPs, expectedFrontendIP) } for _, wantedRule := range svc.Spec.Ports { expectedRuleCount++ <del> wantedRuleName := az.getLoadBalancerRuleName(&svc, wantedRule.Protocol, wantedRule.Port, subnet(&svc)) </del> <ins> wantedRuleName := az.getLoadBalancerRuleName(&svc, wantedRule.Protocol, wantedRule.Port) </ins> foundRule := false for _, actualRule := range *loadBalancer.LoadBalancingRules { if strings.EqualFold(*actualRule.Name, wantedRuleName) &&

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: When the specified internal LB uses a subnet with longer name, the LB configuration will fail with following error: What you expected to happen: When constructing the frontend IP configuration name and the load balancing rules name, the subnet name should be truncated if too long. How to reproduce it (as minimally and precisely as possible): Use a subnet that has long name (70 charactors) and create ILB service. Anything else we need to know?: Environment: Kubernetes version (use ): 1.15 Cloud provider or hardware configuration: azure OS (e.g: ): Ubuntu 16.04 Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig cloud-provider /area provider/azure /assign
Change:
if c.Type == certificates.CertificateDenied { return false, fmt.Errorf("certificate signing request is not approved, reason: %v, message: %v", c.Reason, c.Message) } <del> if c.Type == certificates.CertificateApproved && csr.Status.Certificate != nil { return true, nil </del> <ins> if c.Type == certificates.CertificateApproved { if csr.Status.Certificate != nil { klog.V(2).Infof("certificate signing request %s is issued", csr.Name) return true, nil } klog.V(2).Infof("certificate signing request %s is approved, waiting to be issued", csr.Name) </ins> } } return false, nil

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently, during kubelet bootstrapping, while waiting for the node certificate being signed, there is no logs showing what is happening. I would like to add some logging to for easier troubleshooting. Why is this needed: When troubleshooting kubelet bootstrapping process on a node, if there is some issue with certificate signing mechanism, kubelet will wait for its certificate being signed for without a single line of log. Often, the last lines of kubelet log would look like the following, and kubelet will be in an confusing "infinite" wait. And then, some healthchecking monitor for kubelet may kick in and restart kubelet, resulting in a confusing loop. Adding some logging here will greatly help troubleshooting bootstrapping process on the node side. /sig node
The logging would be in the following func: I think we should control the frequency of logging (by remembering the timestamp of last log).
Change:
"k8s.io/apiserver/pkg/authentication/request/headerrequest" unionauth "k8s.io/apiserver/pkg/authentication/request/union" "k8s.io/apiserver/pkg/authentication/request/x509" <del> "k8s.io/apiserver/pkg/authentication/user" </del> webhooktoken "k8s.io/apiserver/plugin/pkg/authenticator/token/webhook" authenticationclient "k8s.io/client-go/kubernetes/typed/authentication/v1beta1" "k8s.io/client-go/util/cert"

Discussion:
When an auth proxy tries to proxy an anonymous request, the user.Info ends up with the group system:authenticated, which is wrong.
Change:
<del> This file has moved to [https://github.com/kubernetes/examples/blob/master/staging/volumes/flexvolume/README.md](https://github.com/kubernetes/examples/blob/master/staging/volumes/flexvolume/README.md) </del> <ins> This file has moved to [https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md](https://github.com/kubernetes/community/blob/master/contributors/devel/flexvolume.md) </ins>

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Some url in markdown file is invalid or need to be redirected to dest. url one time or more. What you expected to happen: So cleaning them up is necessary. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
This can be closed now. It is fixed in
/close
Change:
} return &unstructured.Unstructured{Object: u}, nil } <ins> type noCorrespondingTypeErr struct { gvk schema.GroupVersionKind } func newNoCorrespondingTypeError(gvk schema.GroupVersionKind) error { return &noCorrespondingTypeErr{gvk: gvk} } func (k *noCorrespondingTypeErr) Error() string { return fmt.Sprintf("no corresponding type for %v", k.gvk) } func isNoCorrespondingTypeError(err error) bool { if err == nil { return false } _, ok := err.(*noCorrespondingTypeErr) return ok } </ins>

Discussion:
Found by failing TestApplyConvertsManagedFieldsVersion test in () It seems that conversion depends on schema info that is collected from served API versions only. However, managedFields stores data in etcd from REST versions served in previous releases which may no longer be served. That means that we have to be able to deal with managedFields persisted via API calls to versions that are no longer served, but which we still have and understand conversions for. /cc /sig api-machinery /wg apply /priority important-soon
This may be fixed in a more recent version of structured-merge-diff. I'll look into it
/assign
At one point we were using the types registered to the scheme to generate the openAPI definitions used by apply, but we switched to using the installed endpoints instead, because it was less invasive (We needed to expose which types are convertible to which other types, and also a way to skip generating openAPI for internal types). We might want to revisit the first approach, given this use case.
Change:
ProxierMinSyncPeriod time.Duration NodeLabels           map[string]string RegisterWithTaints   []core.Taint <ins> MaxPods              int ExtendedResources    map[string]string </ins> } const (

Discussion:
A kubernetes cluster is normally constructed from a variety of machine templates. Different instance groups may have different CPU, memory capacity. They may be equipped with specialized accelerators, network devices. I think we should have an extensible way for users to custom node configuration to simulate real production cluster states. Currently, nodelabel and nodetaints are supported. I am consider to accept a template with more configuration like resources so we won't grow option list in the future. Without this feature, it's hard for users to simulate heterogeneous cluster.
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/sig scalability
Change:
wantMinor: 5, wantErr:   false, }, <del> /*{ </del> <ins> { </ins> name:    "multiple declarations of same tag should return an error", tagName: "someVersionTag:version", tagComments: []string{

Discussion:
The commands under will benefit of a batter unit test coverage as seen in Originally posted by in
/sig api-machinery /assign
GitHub didn't allow me to assign the following users: damiansawicki. Note that only with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /sig api-machinery 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
/triage accepted
Hi I would like to work on this issue. Could you tell me how many test files are needed per PR under this issue?
Hi the issue is already assigned to me. Would you consider contributing to other issues to avoid duplication?
Hi do you mind if I work on this issue along with you? I would only like to write tests on limited number of files, if that's okay with you...
Hi thanks for your engagement! If you also want to work on this particular issue, we should coordinate. Are you working on something other than ?
Hey currently I'm thinking of shifting to Do let me know if you are already working on that particular directory. Also I could assist you in any of your work on this issue as I'm not preoccupied at the moment.
Change:
} // Check runtime support. Currently only Docker is supported. <del> if runtime != "docker" { return fmt.Errorf("AppArmor is only enabled for 'docker' runtime. Found: %q.", runtime) </del> <ins> if runtime != "docker" && runtime != "remote" { return fmt.Errorf("AppArmor is only enabled for 'docker' and 'remote' runtimes. Found: %q.", runtime) </ins> } return nil

Discussion:
AppArmor validator returns error if the runtime is not . For other runtime integrated via CRI, the runtime will be , and will not be able to provide AppArmor support because of this. Currently, we decided to always pass validation for remote runtime, but we need a better solution in the future. This is similar with , and also related to . /cc
I think we should pass validation for all container runtimes in validateHost, since it is host-wide. We could add runtime-specific validation after .
Let me remove this requirement. /assign
Change:
return &v1.PersistentVolume{ ObjectMeta: metav1.ObjectMeta{ <del> // A.K.A InnerVolumeSpecName required to match for Unmount Name: volume.Name, </del> <ins> // Must be unique per disk as it is used as the unique part of the // staging path Name: fmt.Sprintf("%s-%s", GCEPDDriverName, pdSource.PDName), </ins> }, Spec: v1.PersistentVolumeSpec{ PersistentVolumeSource: v1.PersistentVolumeSource{

Discussion:
Minimal Repro: Create 2 different disks Create 2 Pods each using one of the disks Start both pods on the same node You will notice one of the disks gets ed to a path: , then both disks are ed from to a target path: which is similar but at least uses the pod . Both of these volumes are being treated as the same volume in the Kubelet even though they are definitely not the same volume. Note: it may not be "treated" as the same volume - it may just be that since the paths are the same the following volumes see that the path is already a mountpoint and skip the step. This is the more likely scenario based on observations. The value is the "name" of the inline-volume. These can obviously be the same across different pods - we should actually be placing it in a more unique directory (based off the translated maybe?). /cc
/sig storage
The inline volume example I'm using (ignore the fact that is a complete misnomer): I've confirmed that changing the "name" makes inline volumes work well since there is no longer a collision on the paths
/assign
Alright, problem is sort of twofold: The referred to above for inline-volumes is set here: As we can see from the comment: it is set to the because the in-tree CSI Plugin makes a lot of naming assumptions based on the which for PVC/PVs is the PV name (unique in a cluster). Primarily, during unmount the CSI Plugin tries to from a "well known ": which happens to be some path based on the which for the inline volume is just the ( above). So we run into the problem that if we use the directory is not sufficiently unique for different disks. And if we use something else like then the unmount pathway is unable to find the . I think using is a no-go. So we need to use something sufficiently unique (like ) for the ( above) and fix up some of the other codepaths to either use different "well-known paths" to write to, or to fix up path generation code so they give us the correct locations. I'm also going to check to see whether 's refactor fixes this issue (because it might since it translates things earlier)
OK. Really good news.

your refactor in its current state actually fixes this issue if we set the to something unique here: Looks like the early translation is also making the pathway from the "correct" dir for inline migration. So I will create a PR that fixes this issue that should merge after
Change:
}() if wait.PollImmediate(Poll, timeout, func() (bool, error) { <del> // We get the new list of pods and replication controllers in every // iteration because more pods come online during startup and we want to // ensure they are also checked. </del> <ins> // We get the new list of pods, replication controllers, and // replica sets in every iteration because more pods come // online during startup and we want to ensure they are also // checked. replicas, replicaOk := int32(0), int32(0) </ins> rcList, err := c.Core().ReplicationControllers(ns).List(api.ListOptions{}) if err != nil { Logf("Error getting replication controllers in namespace '%s': %v", ns, err) return false, nil } <del> replicas := int32(0) </del> for _, rc := range rcList.Items { replicas += rc.Spec.Replicas <ins> replicaOk += rc.Status.ReadyReplicas } rsList, err := c.Extensions().ReplicaSets(ns).List(api.ListOptions{}) if err != nil { Logf("Error getting replication sets in namespace %q: %v", ns, err) return false, nil } for _, rs := range rsList.Items { replicas += rs.Spec.Replicas replicaOk += rs.Status.ReadyReplicas </ins> } podList, err := c.Core().Pods(ns).List(api.ListOptions{})

Discussion:
The logic to account for all pods being ready is incorrectly counting some pods as being controlled by a replication controller. This is causing the 1.3-1.5 upgrade tests to fail. See https://k8s- as an example. Since , the pre-flight checks fail and the rest of the tests never run. I think this was exposed by which changed some things from ReplicationControllers to Deployments. There's a pod being created by a deployment that also matches the selector of a replication controller, and is therefore being incorrectly counted by cc