jiebi/CodeConvo huggingface dataset:
Change:
// obj must be a pointer to an API type. An error is returned if the minimum // required fields are missing. Fields that are not required return the default // value and are a no-op if set. <del> // TODO: return bool instead of error </del> func Accessor(obj interface{}) (metav1.Object, error) { switch t := obj.(type) { case metav1.Object:

Discussion:
Anything else we need to know?: I notice there are TODOs in apimachinerypkgapimeta,return bool instead of error func CommonAccessor, ListAccessor, Accessor. If is it necessary to do,I push a PR for it. Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
cc
/sig api-machinery
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Change:
// sets, the same network interface couldn't be added to more than one load balancer of // the same type. Omit those nodes (e.g. masters) so Azure ARM won't complain // about this. <ins> newBackendPoolsIDs := make([]string, 0, len(newBackendPools)) </ins> for _, pool := range newBackendPools { <del> backendPool := *pool.ID matches := backendPoolIDRE.FindStringSubmatch(backendPool) if len(matches) == 2 { lbName := matches[1] if strings.HasSuffix(lbName, InternalLoadBalancerNameSuffix) == isInternal { klog.V(4).Infof("Node %q has already been added to LB %q, omit adding it to a new one", nodeName, lbName) return nil } </del> <ins> if pool.ID != nil { newBackendPoolsIDs = append(newBackendPoolsIDs, *pool.ID) </ins> } } <ins> isSameLB, oldLBName, err := isBackendPoolOnSameLB(backendPoolID, newBackendPoolsIDs) if err != nil { return err } if !isSameLB { klog.V(4).Infof("Node %q has already been added to LB %q, omit adding it to a new one", nodeName, oldLBName) return nil } </ins> } newBackendPools = append(newBackendPools,

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: SLB backend pools are empty if outbound rules are defined in a separate backend pool. This is because, although we the check for not adding the backend pools from different LBs, the lbName is not checked: The new backend pool's lbName should be also checked in above codes. What you expected to happen: SLB backend pools should be updated correctly when outbound rules are defined in a separate backend pool. 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: ): Kernel (e.g. ): Install tools: Others: /sig azure /kind bug /assign
Change:
# besides the default ones. extra_prune_whitelist= if [ -n "${KUBECTL_EXTRA_PRUNE_WHITELIST:-}" ]; then <del> extra_prune_whitelist=( "${KUBECTL_EXTRA_PRUNE_WHITELIST:-}" ) </del> <ins> read -ra extra_prune_whitelist <<< "${KUBECTL_EXTRA_PRUNE_WHITELIST}" </ins> fi prune_whitelist=( "${KUBECTL_PRUNE_WHITELIST[@]}"  "${extra_prune_whitelist[@]}" ) prune_whitelist_flags=$(generate_prune_whitelist_flags "${prune_whitelist[@]}")

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: Regression in 1.17 introduced by When there are several items passed using KUBECTLEXTRAPRUNE_WHITELIST flag, cluster/addons/addon-manager/kube- generates wrong flags for kubectl: Which causes: What you expected to happen: It should generate: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: /sig release Environment: Kubernetes version (use ): 1.17.*
/assign
- FYI This seems like a regression in 1.17, so we should merge fix in 1.17.
cc for shellcheck-induced regressions
This happens because we don't have an "API" documented for these environment variables. Ideally we should not be depending on space splitting strings.
Not yet fixed for 1.17 /reopen
Reopened this issue. <detailsIn response to : Not yet fixed for 1.17 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:
GCE_HOSTS= GCE_IMAGE_CONFIG_PATH=test/e2e_node/jenkins/image-config.yaml GCE_ZONE=us-central1-f <del> GCE_PROJECT=kubernetes-jenkins </del> <ins> GCE_PROJECT=k8s-jkns-ci-node-e2e </ins> CLEANUP=true GINKGO_FLAGS='--focus="[Serial]" --skip="[Flaky]"' SETUP_NODE=false

Discussion:
I want to isolate these in their own project:
Right now just the CI jobs, but after we also need to do this for the PR jobs.
Change:
export KUBE_CONFIG_FILE=${KUBE_CONFIG_FILE:-${KUBE_ROOT}/cluster/ubuntu/config-default.sh} source "${KUBE_CONFIG_FILE}" <del> source "${KUBE_ROOT}/cluster/common.sh" </del> tear_down_alive_resources check-pods-torn-down

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: I was following to install a cluster but failed due to the following. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else do we need to know:
The current workaround solution is remove in ./kube-
please have a look
thanks for the quick response
Just FYI, I think that you should fix both kube-up and kube-down
i have already move: source "${KUBE_ROOT}" to the head of ,is there something can't work?
Thanks, I did not have a try but just a reminder, just check code, yes, I think it works. Thanks
Seems the kube-up still does not work, filed another issue here
can you help take a look? Thanks!
/sig cluster-lifecycle
hi, I still see the issue but wondering since you have closed considering planned deprecation of the script. Does this issue still requires a fix or any decision was made not to work on it? Thanks!
Thanks , I think that we can close this now as it is not supported any more.
sure and thank you for the quick response and closing it !!
Change:
} ginkgo.By("deleting the pod") <del> err = podClient.Delete(ctx, pod.Name, *metav1.NewDeleteOptions(30)) </del> <ins> err = podClient.Delete(ctx, pod.Name, *metav1.NewDeleteOptions(1)) </ins> framework.ExpectNoError(err, "failed to delete pod") }) ginkgo.It("should provide hostIPs as an env var", func(ctx context.Context) { <ins> if !utilfeature.DefaultFeatureGate.Enabled(kubefeatures.PodHostIPs) { e2eskipper.Skipf("PodHostIPs feature is not enabled") } </ins> podName := "downward-api-" + string(uuid.NewUUID()) env := []v1.EnvVar{ {

Discussion:
4 other Test Failures in ci-crio-cgroupv1-node-e2e-features. Test has failed 61 times (no passing result found). Earliest failure found at commit/ (Thu Oct 19 21:41 PDT). /cc { failed [FAILED] Error creating Pod: pods "pod-dualstack-host-ips9ddb9810-134c-4d35-a0c6-" is forbidden: violates PodSecurity "restricted:latest": host namespaces (hostNetwork=true) In [It] at: @ 10/23/23 01:38:06.024 } No response_ /sig network node
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
is also failing on these tests
the test has a bug, it checks the contrary
, let's start over, 1 commit for the e2e test, other for the promotion, and let's validate everything is alright before merging
Change:
ALLOCATE_NODE_CIDRS=true <del> KUBE_PROMPT_FOR_UPDATE=y KUBE_SKIP_UPDATE=${KUBE_SKIP_UPDATE-"n"} </del> <ins> KUBE_PROMPT_FOR_UPDATE=${KUBE_PROMPT_FOR_UPDATE:-"n"} </ins> # How long (in seconds) to wait for cluster initialization. KUBE_CLUSTER_INITIALIZATION_TIMEOUT=${KUBE_CLUSTER_INITIALIZATION_TIMEOUT:-300}

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): all :smile: Environment: Cloud provider or hardware configuration: GCE OS (e.g. from /etc/os-release): all Kernel (e.g. ): all Install tools: Others: What happened: uses the cli a lot and does a (in the commonly used function ) before doing things like . updates can introduce breaking changes (for example in the recent 132.0.0 release it removed a bunch of flags). This has caused cross-the-board test failures like . But this is not limited to just tests. Any kubernetes GCE users who rely on the and commands could have been broken. What you expected to happen: Stop updating gcloud automatically. We could either warn user to have the required dependencies installed, or pin to specific versions of dependencies like gcloud. How to reproduce it (as minimally and precisely as possible): download 1.4.4 release tarball run and Anything else do we need to know:
cc
/cc
cc I think it's reasonable to remove gcloud update calls from scripts, as I believe gcloud is updated out of band by k8s continuous testing. The scripts will still need to work with latest, so maybe they should check for a minimum version.
Good idea.
Yeah, we definitely want to continue using latest in CI so that we know if things break, but I think it's reasonable to remove the update itself from the kubernetes cluster util scripts.
Change:
if gcloud compute addresses create "$1"  --project "${PROJECT}"  --region "${REGION}" -q > /dev/null; then <del> # successful operation </del> <ins> # successful operation - wait until it's visible start="$(date +%s)" while true; do now="$(date +%s)" # Timeout set to 15 minutes if [ $((now - start)) -gt 900 ]; then echo "Timeout while waiting for master IP visibility" exit 2 fi if gcloud compute addresses describe "$1" --project "${PROJECT}" --region "${REGION}" >/dev/null 2>&1; then break fi echo "Master IP not visible yet. Waiting..." sleep 5 done </ins> break fi

Discussion:
I'm seeing the following failures of Kubemark in presubmit: It calls stop-kubemark without clear reason. Such failure are e.g. here:
Ref
Actually, both these failures are a different issue. The logs that are problematic are: Why we don't have kubectl there?
I don't know why - ? I haven't seen those error recently, so I guess this is fixed. OTOH I have seen a number of runs where cluster startup failed, but there's a fun thing about those failures. All of them occurred on runs on worker-22:
I found something even more interesting. Extending the log: It seems that the cluster was created around 00:30 on 2016-09-20, MTV time (this is a default Jenkins time). But doing: gives the following result: Which seems to indicate that the address was never created around that time... cc
[FLAKE-PING] This flaky-test issue would love to have more attention.
Change:
# Persist %PSCORE% ENV variable for user convenience PSCORE="C:Program FilesPowerShellpwsh.exe" <del> LABEL image_version="1.29" </del> <ins> LABEL image_version="1.29-1" </ins> ENTRYPOINT ["cmd.exe", "/s", "/c"]

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI -- [sig-windows] [Feature:Windows] GMSA Kubelet [Slow] kubelet GMSA support when creating a pod with correct GMSA credential specs passes the credential specs down to the Pod's containers [sig-windows] [Feature:Windows] GMSA Full [Serial] [Slow] GMSA support works end to end ** pause image using in image was transitioned to the official pause image which no longer has in the image related to /sig windows /triage accepted
Change:
testSvcLabels := map[string]string{"e2e-test": "proxy-endpoints"} framework.Logf("Creating pod...") <del> _, err := f.ClientSet.CoreV1().Pods(ns).Create(context.TODO(), &v1.Pod{ </del> <ins> pod := &v1.Pod{ </ins> ObjectMeta: metav1.ObjectMeta{ <del> Name: "agnhost", </del> <ins> Name:      "agnhost", Namespace: ns, </ins> Labels: map[string]string{ "e2e-test": "proxy-endpoints"}, },

Discussion:
pull-kubernetes-e2e-kind-ipv6 - Not sure. Time out on waiting Pod to be started. No response /sig network
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
Change:
"k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/api/resource" "k8s.io/apimachinery/pkg/util/sets" <del> cloudprovider "k8s.io/cloud-provider" </del> <ins> "k8s.io/cloud-provider" </ins> volumehelpers "k8s.io/cloud-provider/volume/helpers" "k8s.io/kubernetes/pkg/util/mount" "k8s.io/kubernetes/pkg/volume"

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: We have pretty large clusters in aws and in production, we found an inefficiency in provisioning dynamic EBS volumes, where aws-ebs volume provisioner tries to look for available zone from aws directly. With scale, this can trigger massive from ec2, and affect cluster stability. This is also related to What you expected to happen: To simply get zones with available instances, we can get information from API server for efficiency. There might be a delay between node gets shutting down and such change is reflected in api server, but in case node is not ready or gets terminated, there will be higher level reconciliation triggered so we are safe. How to reproduce it (as minimally and precisely as possible): We only expect this to be hit when the cluster is huge (or aws account is huge) so not easy to reproduce. /assign /sig aws /sig cloud-provider
/assign
Change:
} } <del> func TestPodAddressChanged(t *testing.T) { </del> <ins> func TestPodChanged(t *testing.T) { </ins> podStore := cache.NewStore(cache.DeletionHandlingMetaNamespaceKeyFunc) ns := "test" addPods(podStore, ns, 1, 1, 0)

Discussion:
This test has started failing on our e2e test suite, erroring out with "Failed to get endpoints..." https://k8s- https://k8s- Example failures https://k8s- https://k8s- cc cc
This may be related to our recently-merged endpoints change in . I'll look into it.
I verified that the flakiness introduced was a result of . A fix in should be merging soon. /assign
GitHub didn't allow me to assign the following users: joelsmith. Note that only can be assigned. <detailsIn response to : I verified that the flakiness introduced was a result of . A fix in should be merging soon. /assign 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:
// PodMetrics sets resource usage metrics of a pod. type PodMetrics struct { <del> metav1.TypeMeta   `json:",inline"` </del> <ins> metav1.TypeMeta `json:",inline"` // Standard object's metadata. // More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata // +optional </ins> metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"` // The following fields define time interval from which metrics were

Discussion:
no explanation for metadata filed of NodeMetrics/PodMetrics, code: should be like $ kubectl explain NodeMetrics KIND: NodeMetrics VERSION: DESCRIPTION: NodeMetrics sets resource usage metrics of a node. FIELDS: apiVersion <stringAPIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: kind <stringKind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: metadata <Objecttimestamp <string-required- The following fields define time interval from which metrics were collected from the interval [Timestamp-Window, Timestamp]. usage <map[string]string-required- The memory usage is the memory working set. window <string-required- and $ kubectl explain PodMetrics KIND: PodMetrics VERSION: DESCRIPTION: PodMetrics sets resource usage metrics of a pod. FIELDS: apiVersion <stringAPIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: containers <[]Object-required- Metrics for all containers are collected within the same time window. kind <stringKind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: metadata <Objecttimestamp <string-required- The following fields define time interval from which metrics were collected from the interval [Timestamp-Window, Timestamp]. window <string-required- able to see the explanation for metadata filed of NodeMetrics/PodMetrics Kubernetes Version: v1.22.0-rc.0+
/sig instrumentation
/kind documentation /assign /triage accepted
Change:
return } <del> fs.StringVar(&o.ServiceAccountKeyFile, "service-account-private-key-file", o.ServiceAccountKeyFile, "Filename containing a PEM-encoded private RSA or ECDSA key used to sign service account tokens.") </del> <ins> fs.StringVar(&o.ServiceAccountKeyFile, "service-account-private-key-file", o.ServiceAccountKeyFile, "Enables legacy secret-based tokens when set. Filename containing a PEM-encoded private RSA or ECDSA key used to sign service account tokens.") </ins> fs.Int32Var(&o.ConcurrentSATokenSyncs, "concurrent-serviceaccount-token-syncs", o.ConcurrentSATokenSyncs, "The number of service account token objects that are allowed to sync concurrently. Larger number = more responsive token generation, but more CPU (and network) load") fs.StringVar(&o.RootCAFile, "root-ca-file", o.RootCAFile, "If set, this root certificate authority will be included in service account's token secret. This must be a valid PEM-encoded CA bundle.") }

Discussion:
The kube-controller-manager issues a warning during startup when is specified without providing a . This warning is misleading because the legacy service account token controller, which relies on the , is no longer required for most modern Kubernetes clusters unless explicitly needed for generating long-lived tokens. Additionally, the documentation does not clearly state the purpose of this flag or its impact on legacy token mechanisms. I expected that the warning related to the would either not appear or be updated to reflect its relevance only to the legacy token mechanism. Furthermore, I expected the documentation to clearly explain that this flag is only necessary for enabling the legacy service account token controller and to provide updated guidance on generating long-lived tokens. kube-controller-manager with the --use-service-account-credentials flag but without the --service-account-private-key-file flag. the warning message that is issued during initialization. the current documentation for kube-controller-manager flags and the process for generating long-lived service account tokens. for context <details</details<detailsBare metal </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/sig auth