jiebi/CodeConvo huggingface dataset:
Change:
kube::golang::setup_env <ins> # The sort at the end makes sure we feed the topological sort a deterministic # list (since there aren't many dependencies). </ins> generated_files=($( find . -not (  ( 

Discussion:
See, e.g. This seems to be blocking multiple PRs from even being tested.
Looking.
I think I figured it out. The order of generation matters. The verify script subtly breaks that by renaming and checking the files one at a time. The update script deletes everything and then recreates them.
I have a fix. Will send a PR shortly.
Change:
"k8s.io/kubernetes/pkg/features" kubeletconfig "k8s.io/kubernetes/pkg/kubelet/apis/config" kubelettypes "k8s.io/kubernetes/pkg/kubelet/types" <ins> e2eskipper "k8s.io/kubernetes/test/e2e/framework/skipper" </ins> testutils "k8s.io/kubernetes/test/utils" )

Discussion:
Failing on cri-o serial job. Looks like the dbus command isn't available for graceful shutdown tests that aren't running on Ubuntu. /assign /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
/triage accepted /priority important-soon
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
hmm, is this still issue? The testgrid job is still failing even after the fix appears to be merged? !
Please take a look when you get a chance, the error still seems to be that dbus-send is unavailable... /cc
oops... I forgot to add this to the other
Change:
embed = [":go_default_library"], deps = [ "//pkg/kubelet/apis/pluginregistration/v1:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/util/wait:go_default_library", </ins> "//vendor/github.com/stretchr/testify/require:go_default_library", "//vendor/k8s.io/klog:go_default_library", ],

Discussion:
What happened: A race condition in the plugin watcher might happen when a is created, started and immediately stopped and cleaned up. If executed several times, the unit test will expose this issue. The PR addressed part of the problem by serializing the handling of CREATE and DELETE events. However, a race might still happen in the function. describes in detail the problem. How to reproduce it (as minimally and precisely as possible): /sig storage /sig node
/assign
Change:
# Launches an nginx container and verifies it can be reached. Assumes that # we're being called by hack/e2e-test.sh (we use some env vars it sets up). <ins> # TODO: remove this once test/e2e/kubectl.go is green in jenkins </ins> set -o errexit set -o nounset set -o pipefail

Discussion:
Part of issue Re-write test in Go, generate unique names for top level resources, ensure test is idempotent, clean up all resources at end of test.
I was just glancing at this test to see how crunchy it was to port. One of the sad things would be abandoning , so if we do port this, I think we should definitely go through the to make sure it stays tested.
That reminds me... Do we have an issue yet to add an e2e test to specifically test kubectl?
We do now:
Thanks.
I am unassigning myself from this for now. I expect to be working on the fixit for cluster level logging for several days so I'd rather not have this assigned to me while I can't give it attention. If it is still open later then I may try to take a crack at it.
Change:
"unicode" "unicode/utf8" <ins> "github.com/google/go-cmp/cmp" </ins> v1 "k8s.io/api/core/v1" apiequality "k8s.io/apimachinery/pkg/api/equality" "k8s.io/apimachinery/pkg/api/resource"

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 --pod with nodeSeletor edit pod, delete the nodeSeletor field report error with: ! The errors message should displayed as: Because the nodeSeletor is been deleted with this edit. 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:
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig api
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig api 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
/sig api-machinery
/remove-sig api-machinery /sig apps
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle stale
/remove-lifecycle rotten
Change:
scheduleAttempts, e2eSchedulingLatency, SchedulingAlgorithmLatency, <del> BindingLatency, SchedulingAlgorithmPreemptionEvaluationDuration, </del> <ins> DeprecatedBindingLatency, DeprecatedSchedulingAlgorithmPreemptionEvaluationDuration, </ins> PreemptionVictims, PreemptionAttempts, pendingPods,

Discussion:
Mark the following metrics as deprecated and . Both of those metrics are now covered as part of , the former as a the latter and a plugin. This can be done by setting in each of the two metrics opts. Changing the name of the metric variable to be prefixed with "Deprecated" is useful as well. /help /sig scheduling
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 : Mark the following metrics as deprecated and . Both of those metrics are now covered as part of , the former as a the latter and a plugin. /sig scheduling Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/kind deprecation
Change:
v1 "k8s.io/api/core/v1" apierrors "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/apimachinery/pkg/apis/meta/v1/unstructured" "k8s.io/apimachinery/pkg/runtime" </ins> "k8s.io/apimachinery/pkg/util/intstr" "k8s.io/apimachinery/pkg/util/uuid" "k8s.io/apimachinery/pkg/util/wait" <ins> clientscheme "k8s.io/client-go/kubernetes/scheme" "k8s.io/client-go/util/retry" </ins> "k8s.io/kubernetes/test/e2e/framework" e2epod "k8s.io/kubernetes/test/e2e/framework/pod" imageutils "k8s.io/kubernetes/test/utils/image"

Discussion:
[x] test approval issue : [x] test pr : [x] two weeks soak end date : 1 Aug 2022 [x] test promotion pr : According to this APIsnoop query, there is still some remaining NamespaceStatus endpoints which are untested. readCoreV1NamespaceStatuspatchCoreV1NamespaceStatus Using a number of existing e2e test practices a new has been created for 2 namespace status endpoints. The e2e logs for this test are listed below. This query shows the endpoints hit within a short period of running the e2e test If a test with these calls gets merged, test coverage will go up by 3 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
default: return nil, fmt.Errorf("unsupported algorithm source: %v", source) } <del> metrics.Register() </del> // Additional tweaks to the config produced by the configurator. sched.Recorder = recorder sched.DisablePreemption = options.disablePreemption

Discussion:
What happened: two scheduler metrics, and , was not recorded in . scheduler has some code for this already. It seems to be a bug. What you expected to happen: and was recorded How to reproduce it (as minimally and precisely as possible): /king bug /sig scheduling
/assign
What do you expect for ? And I think pending pods are available in metrics, but not from scheduler. You can get it from pods info metrics.
actually, scheduler has some code already for recording these metrics. But I found a bug in these code. I will post my PR to fix this issue soon. // I updated the issue description for clarifying.
Change:
// NOTE: The $Format strings are replaced during 'git archive' thanks to the // companion .gitattributes file containing 'export-subst' in this same // directory.  See also https://git-scm.com/docs/gitattributes <del> gitVersion   string = "v0.0.0-master+$Format:%h$" </del> <ins> gitVersion   string = "v0.0.0-master+$Format:%H$" </ins> gitCommit    string = "$Format:%H$" // sha1 from git, output of $(git rev-parse HEAD) gitTreeState string = ""            // state of git tree, either "clean" or "dirty"

Discussion:
Ref. includes: // NOTE: The $Format strings are replaced during 'git archive' thanks to the // companion .gitattributes file containing 'export-subst' in this same // directory. See also https://git- gitVersion string = "v0.0.0-master+" This directive, activated by and the  containing the line , results in file contents served by GitHub Archives that can change in unexpected ways. For example, the length of the commit SHA can expand over time as there are collisions. This non-determinism can lead to surprises, such as , where a client-go dependency resulted in unexpectedly different tar hashes, which was detected when a new version of the ko binary was being to Homebrew. tl;dr: though the client-go dependency itself didn't change for ko, later runs of (via GitHub Archives) resulted in different contents for the string to avoid a new collision for the previous prefix length, which cascaded into different content SHAs and shady-looking binary SHAs. I'm not sure, but after reading docs I believe you could naively solve this by replacing with so the string includes the full commit hash instead of the abbreviated one. I have no idea if anything depends on being a shorter string, but presumably things are fine with it having been a variable-length string so . Given enough time/collisions, I suppose theoretically will slow grow to be equal to , but I don't think that will happen during any of our lifetimes cc
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
Thanks for the report. Moving to kubernetes/kubernetes where this source comes from. There's not a lot we can do for past releases, but I'd be in favor of switching to %H going forward. Reproducibility of source archives is important.
/sig release
/kind bug
Thanks for taking this on !!
since we don't actually use to full-fill the commit info as version, should we just delete that file? containerd a issue about checksum mismatch due to this.

and before that it was and before that , so everywhere
I have created to stop including the files in k8s libraries. For anyone vendoring these libraries in the future, you should no longer be affected by this issue.
Change:
embed = [":go_default_library"], deps = [ "//vendor/github.com/Azure/azure-sdk-for-go/services/containerregistry/mgmt/2019-05-01/containerregistry:go_default_library", <ins> "//vendor/github.com/Azure/go-autorest/autorest/azure:go_default_library", </ins> "//vendor/github.com/Azure/go-autorest/autorest/to:go_default_library", ], )

Discussion:
What happened: An aks-engine cluster with a user assigned managed service cluster identity fails to authenticate to azure container registries in private clouds when the proper (acrpull) azure role assignments are in place and when there are no image pull secrets. What you expected to happen: The cluster should be able to authenticate and pull from an ACR hosted in the same azure cloud without needing additional pull secrets when the cluster identity has the proper acrpull azure role assignment, no matter which azure cloud it is operating in. How to reproduce it (as minimally and precisely as possible): Assume you have a private azure cloud where every url ends with "". That would mean the ACR suffix would be . Let's pretend you have an ACR at and you try to deploy a pod in your cluster referencing the image . This will fail to pull when you have no image pull secrets. Anything else we need to know?: The problem stems from the following lines where expected ACR suffix domains are hardcoded: Environment: Kubernetes version (use ): 1.16.9 Cloud provider or hardware configuration: Azure private OS: ubuntu 16.0.4 Network plugin and version: Azure CNI
/sig provider-azure
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig provider-azure Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/area provider/azure /sig cloud-provider
It looks like we may be able to obtain the acr suffix from the azure environment:
there is a security issue here: if we support self defined ACR domain, e.g. , then service principal secret could be sent to that remote server. The reason why we use hardcoded domains is that we could always make sure the following 4 domains are owned by Azure:
Change:
}, }, expectedUpdateCalls: []fakecloud.UpdateBalancerCall{ <ins> {Service: etpLocalservice1, Hosts: []*v1.Node{node1, node3}}, {Service: etpLocalservice2, Hosts: []*v1.Node{node1, node3}}, </ins> {Service: service3, Hosts: []*v1.Node{node1, node3}}, }, }, {

Discussion:
In 1.26 the service controller in the Kubernetes cloud controller manage (KCCM) introduced a new mechanism for syncing load balancers based on predicates. The predicates applied will depend on "service classes", specifically if it's or , see: This implementation is not well suited for internal GCP load balancers which use InstanceGroups. from Google, feel free to correct me: any cluster has all nodes grouped together into an instance group. Service of have individual GCP load balancers, but these load balancers end up referencing the same instance group (which is the cluster's instance group). This means that the inclusion/exclusion predicates for any service, will trickle down and impact the cluster's global instance group, thereby impacting other services which don't necessarily apply the same set of predicates. Ex: services exclude nodes, whereas do not. A Node going will therefore be removed from all backends for services, however on GCP with load balancer solution based on InstanceGroups: this means that the same node will be removed from all backends for services too. This is NOT a problem on = 1.27 using the feature , because all services on 1.27 using that feature gate will have the same set of predicates. Node updates requiring the removal of the instance from load balancers belonging to services of should not impact other services of . Bring up a cluster using "Internal load balancers" on GCP. Define two services, one being and the other . Have one node go . The instance corresponding to that Node might be removed from the InstanceGroup backend of the service. This will depend on the order the services are synced, if the service is synced last then the instance will be removed. This is actually not really that bad, because the only different predicate between both is the readiness condition - and a node should go back to if all is fine, and finally be included. But I wanted to raise this for issue for completeness sake so that it is known. <details</details<detailsGCP </details<details</details<details</details<details</details<details</details
/sig network /sig cloud-provider /cc
/triage accepted
Change:
"//vendor/k8s.io/apimachinery/pkg/runtime:go_default_library", "//vendor/k8s.io/apimachinery/pkg/types:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/sets:go_default_library", <del> "//vendor/k8s.io/apimachinery/pkg/util/validation/field:go_default_library", </del> "//vendor/k8s.io/apimachinery/pkg/util/wait:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/yaml:go_default_library", "//vendor/k8s.io/client-go/kubernetes:go_default_library",

Discussion:
To read a pod manifest file from disk (or from the http source), kubelet execute the following code to Decode a on-disk v1 pod manifest to an internal pod object (the defaults are applied in this process). Validate the internal pod. Convert the internal pod back to a v1 pod. The downstream pod cache (which gets v1 pods from different sources) performs similar operations: Convert the v1 pod to an internal pod. Validate the internal pod. One of two conversion/validation should be removed, and some of them should be simplified.
/cc for suggestions on defaulting and conversion.
If no one is working on this, I will take it.
Change:
# Default registry, arch and tag. This can be overwritten by arguments to make PLATFORM?=linux ARCH?=amd64 <del> TAG?=1.6 </del> <ins> TAG?=1.7 </ins> REGISTRY?=gcr.io/google_containers GOLANG_VERSION=1.6

Discussion:
Now that merged, we need to build a new kube-dns release.
I just put in a PR yesterday to fix the missing changelog entry for kube-dns:1.6
Change:
clientset "k8s.io/client-go/kubernetes" "k8s.io/client-go/tools/cache" watchtools "k8s.io/client-go/tools/watch" <ins> "k8s.io/client-go/util/retry" </ins> "k8s.io/kubernetes/test/e2e/framework" e2enode "k8s.io/kubernetes/test/e2e/framework/node" e2epod "k8s.io/kubernetes/test/e2e/framework/pod"

Discussion:
[X] Test PR: kuberenetes/kubernetes 17 June 2021 [x] Two weeks soak end date: 1 Jul 2021 [X] Test promotion PR: kubernetes/kubernetes According to this APIsnoop query, there are still some remaining StatefulSet endpoints which are untested. Create a watch to track stateful set events Create a stateful set with a static label. Confirm that the pods are running. Get the stateful set status. Parse the response and confirm that the stateful set status conditions can be listed. Update the stateful set status. Confirm via the watch that the status has been updated. Patch the stateful set status. Confirm via the watch that the status has been patched. Using an existing as a template for a new for stateful set lifecycle test. This query shows the endpoints hit within a short period of running the e2e test If a test with these calls gets merged, test coverage will go up by 3 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
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
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
ServiceLoadBalancerFinalizer:   {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, LocalStorageCapacityIsolationFSQuotaMonitoring: {Default: false, PreRelease: featuregate.Alpha}, NonPreemptingPriority:                          {Default: false, PreRelease: featuregate.Alpha}, <del> VolumePVCDataSource:                            {Default: true, PreRelease: featuregate.Beta}, </del> <ins> VolumePVCDataSource:                            {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.20 </ins> PodOverhead:                                    {Default: true, PreRelease: featuregate.Beta}, IPv6DualStack:                                  {Default: false, PreRelease: featuregate.Alpha}, EndpointSlice:                                  {Default: true, PreRelease: featuregate.Beta},

Discussion:
/kind feature /sig storage /sig api PVC Data Sources have been in beta since 1.16 and should be ready to be promoted to GA in the 1.18 release. KEP:
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /kind feature /sig storage /sig api Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
} } if err := ds.client.StopContainer(podSandboxID, defaultSandboxGracePeriod); err != nil { <del> glog.Errorf("Failed to stop sandbox %q: %v", podSandboxID, err) </del> // Do not return error if the container does not exist if !libdocker.IsContainerNotFoundError(err) { <ins> glog.Errorf("Failed to stop sandbox %q: %v", podSandboxID, err) </ins> errList = append(errList, err) } }

Discussion:
/kind bug What happened: logs when container is gone, should only log when we return an error
/sig node