jiebi/CodeConvo huggingface dataset:
Change:
kubectl set resources --dry-run --local -f ${fluentd_gcp_yaml}  --limits=memory=${FLUENTD_GCP_MEMORY_LIMIT}  --requests=cpu=${FLUENTD_GCP_CPU_REQUEST},memory=${FLUENTD_GCP_MEMORY_REQUEST}  <del> -o yaml > ${fluentd_gcp_yaml}.tmp </del> <ins> --containers=fluentd-gcp -o yaml > ${fluentd_gcp_yaml}.tmp </ins> mv ${fluentd_gcp_yaml}.tmp ${fluentd_gcp_yaml} }

Discussion:
I'm consistently seeing the following failure in those runs: Seems like they're failing scheduling. Will look into it. cc
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
Ok.. So it's consistently failing to create 6 pods and almost surely it's an issue with requests. Most probably some node-daemon is requesting more than before.
From the I'm almost 100% sure that it's failing due to this PR - It seems to have increased the fluentd memory request. Could one of you confirm this?
It hasn't (shouldn't have) changed the resource requirement, defaults for the env variable are the same as in the yaml
Cool, thanks. I'll check what else it could've been.
So it's due to insufficient cpu:
Unless kubemark was using another value than set in that yaml? At some point in time the cpu request was lower ().
It was almost immediately reverted:
We need 50m (kubelet) + 20m (proxy) + 20m (npd) for each hollow-node. And all nodes seem very close to being exhausted: Do you by any chance remember how much was used before?
The above pr should fix this
So the problem is indeed with fluentd. It's requesting 200m of CPU instead of 100m (as is expected). The fluentd container requests 100m as it should be - But the prometheus-to-sd-exporter sidecar container has also requested 100m : We don't have any requests for the exporter set in the yaml template - But it's being set.
There is a limitranger that sets default request to 100m but that's in default namespace which shouldn't affect fluentd. So it's indeed a bug with your PR Could you fix it?
Now these numbers seems awfully similar to the fluentd numbers. Now I see the link with Please investigate, it's a huge bug and has to be rolled back!
Testing a fix, I will send a PR soon.
Seems fixed - https://k8s-
Change:
return cfg } <del> func newFackeAzureToken(accessToken string, expiresOn string) adal.Token { </del> <ins> func newFakeAzureToken(accessToken string, expiresOnTime time.Time) *azureToken { return &azureToken{ token:       newFakeADALToken(accessToken, strconv.FormatInt(expiresOnTime.Unix(), 10)), environment: "testenv", clientID:    "fake", tenantID:    "fake", apiserverID: "fake", } } func newFakeADALToken(accessToken string, expiresOn string) adal.Token { </ins> return adal.Token{ AccessToken:  accessToken, RefreshToken: "fake",

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently, when AAD login is configured, refresh token timeout would make kubectl print an error, not able to re-login without manually remove the tokens. Expect kubectl to promote user to login again. Why is this needed: Configure refresh-token timeout from Azure is a way to force re-login after inactivity. kubectl doesn't promote re-login makes users harder to apply timeout policy.
/sig azure
The label(s) cannot be appled. These labels are supported: <detailsIn response to : /sig 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
The label(s) cannot be appled. These labels are supported: <detailsIn response to : /sig platform/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
the root cause of this issue is in this first gets the cached token (result of device code flow) at it's trying to refresh an expired token at and failed. An error is returned. Since the expired token is still in the cache, it will always hit this path until user removes the token from kubeconfig. the fix should be: the token from cache a retry to re-initiate the device code flow in
The label(s) cannot be appled. These labels are supported: <detailsIn response to : /sig platform/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
/sig cli These SIGs are my best guesses for this issue. Please comment if I am incorrect about one. I am a bot run by vllry. ‍
I'm working on it.
are you working on it? I will grab it if I dont hear it from you :)
have the code ready will try PR this weekend Best, Ping
/assign
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
Closing as merged
Change:
set -e SSH_OPTS="-oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -oLogLevel=ERROR -C" <ins> source "${KUBE_ROOT}/cluster/common.sh" </ins> MASTER="" MASTER_IP=""

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:
"        ExecStart=/opt/bin/kube-apiserver n", "        --address=0.0.0.0 n", "        --port=8080 n", <del> "        --portal_net 10.244.0.0/16 n", </del> <ins> "        --portal_net=10.244.0.0/16 n", </ins> "        --etcd_servers=http://127.0.0.1:4001 n", "        --public_address_override=$private_ipv4 n", "        --logtostderr=truen",

Discussion:
The issue is a missing = in the arguments for starting kube-apiserver. Fix at: in branch:
Change:
GetStats(path string, stats *libcontainercgroups.Stats) error } <del> // getSupportedSubsystems returns list of subsystems supported func getSupportedSubsystems() []subsystem { supportedSubsystems := []subsystem{ &cgroupfs.MemoryGroup{}, &cgroupfs.CpuGroup{}, </del> <ins> // getSupportedSubsystems returns a map of subsystem and if it must be mounted for the kubelet to function. func getSupportedSubsystems() map[subsystem]bool { supportedSubsystems := map[subsystem]bool{ &cgroupfs.MemoryGroup{}: true, &cgroupfs.CpuGroup{}:    true, </ins> } <ins> // not all hosts support hugetlb cgroup, and in the absent of hugetlb, we will fail silently by reporting no capacity. </ins> if utilfeature.DefaultFeatureGate.Enabled(kubefeatures.HugePages) { <del> supportedSubsystems = append(supportedSubsystems, &cgroupfs.HugetlbGroup{}) </del> <ins> supportedSubsystems[&cgroupfs.HugetlbGroup{}] = false </ins> } if utilfeature.DefaultFeatureGate.Enabled(kubefeatures.SupportPodPidsLimit) { <del> supportedSubsystems = append(supportedSubsystems, &cgroupfs.PidsGroup{}) </del> <ins> supportedSubsystems[&cgroupfs.PidsGroup{}] = true </ins> } return supportedSubsystems }

Discussion:
If I run first time it goes fine (after reboot). For subsequent runs I get nodes NotReady. I've tried restarting docker but that won't help. Before christams this used to work all the time. Running Arch Linux if it helps. In I see
/sig node
ditto for me: Looking for a work around I noticed that HugePages recently moved to beta. I can get pods to start again by disabling the HugePages feature gate .
/assign
cc
default Arch kernel doesn't have a hugetlb cgroup controller compiled in(been there done that, I use Arch as well), so you have to prepare your own kernel to run it.
If it were a kernel problem I would have expected the kubelet to fail the first time it was started rather than the second time. This isn't confined to Arch, though. I'm having the same problem with the default Debian kernel:
can you check if your Kernel was compiled with flag? You can do it by running: I bet we have to add documentation, describing this behavior. On Ubuntu 16.04 machine:
Sure, looks like it was not: Documentation (especially in the error message) would be great, but if the kubelet isn't going to survive a restart, I would prefer that it not start the first time. Better to fail immediately than eventually.
can you please check if works (as in fails!) for you?
No, this doesn't resolve the issue. Logs from the first start: Logs from the second start:
Do you have the directory? in that case what i have is insufficient :( If you don't have that directory, then we should probably look for a better spot to put that check? any advice?
No, that directory is missing on my system:
I'm seeing this issue as well.
I am preparing a fix to not fail when hugetlb mount is not present. Will post a fix shortly.
I posted a fix here:
Change:
<ins> /* Copyright 2016 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package kubeadm import ( "bytes" "fmt" "io" "os" "os/exec" ) // Forked from test/e2e/framework because the e2e framework is quite bloated // for our purposes here, and modified to remove undesired logging. func RunCmd(command string, args ...string) (string, string, error) { var bout, berr bytes.Buffer cmd := exec.Command(command, args...) cmd.Stdout = io.MultiWriter(os.Stdout, &bout) cmd.Stderr = io.MultiWriter(os.Stderr, &berr) err := cmd.Run() stdout, stderr := bout.String(), berr.String() if err != nil { return "", "", fmt.Errorf("error running %s %v; got error %v, stdout %q, stderr %q", command, args, err, stdout, stderr) } return stdout, stderr, nil } </ins>

Discussion:
go test ./cmd/kubeadm/... fails with: it appears to be following a "RunCmd" pattern used by e2e tests, but unit tests should not require built binaries
can work on this
has a long discussion as to why this is. These tests only get run when gets run, which will produce the needed binary and pass it in as arg. For more information, authored this and should be able to provide more details.
Yup, the target explicitly ignores these tests: and like said, runs this script as part of its target:
then the test should have build tags to exclude it from a regular run of the package
or up for fixing that?
I thought build tags only works on the OS level or if you it would ignore it completely? Wouldnt break the command as well?
I'd also tolerate skipping the test if the built binary doesn't exist
I think that is a great solution. I think in I had initially suggested something like that. If everyone is ok with that, I will go ahead and make that change.
Sounds good, make that change and we'll see how it turns out. I'd really want these tests start working, so +1
Change:
func (f *fakeExtender) Bind(binding *v1.Binding) error { if f.isBinder { <ins> if f.errBind { return errors.New("bind error") } </ins> f.gotBind = true return nil }

Discussion:
I use extenders to add webhook for default-scheduler: And set to ignore scheuler error when scheduler extender is not working. But I got an error: . I suppose work fine in predicate path, but not work fine in bind path. The Ignorable logic in kube-scheduler: 637: and, 905: the is not judge in . Schedule should not error when set . extenders to kube-scheduler config(which has filterVerb and bindVerb and ignorable flag), example: and add config flag in kube-scheduler pod start up command. a scheduler-extender() and then stop it. a pod and you will see the schedule error. No response <details</details<detailsLocal environment </details<details</details<details</details<details</details<details</details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig scheduling
/cc
/assign
Maybe this is not a bug but as designed, because bind is more critical than filter, what would you do in bind? I have no history context, cc
Hi, Kerthcet, in my scene, I use extender to bind IP(from my own network system) to my pod's annotaion. I'm aware of the critical of binding path, but, what If the extender is broken, how to skip it and continue? The scheduler extender design has supported ignorable, but only work for filter path make no sense for extender both has filter and bind. Maybe we can add an option to allow user to chose what can be ignored. Thanks for your reply anyway~
Reiterating the mentions to trigger a notification: <detailsIn response to : Maybe this is not a bug but as designed, because bind is more critical than filter, what would you do in bind? I have no history context, cc I'm aware of the critical of binding path, but, what If the extender is broken, how to skip it and continue?

The scheduler extender design has supported ignorable, but only work for filter path make no scence for extender both has filter and bind. Maybe we can add an option to allow user to chose what can be ignored. thanks for your reply anyway~ Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
So even the extender bind failed, will not impact your pod scheduling, right?
Yup
Right, if the field is there, we should support it. It's up to the cluster administrator to judge whether it makes sense to ignore a failed extender during bind.
Change:
azureSource := volume.AzureDisk pv := &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", AzureDiskDriverName, azureSource.DiskName), </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:
ResourceTypeOrNameArgs(args...). Flatten(). Do() <ins> checkErr(r.Err()) </ins> found := 0 err = r.IgnoreErrors(errors.IsNotFound).Visit(func(r *resource.Info) error {

Discussion:
I've reported this before.
From a Makefile I get exit status 255.
Just to be clear (sorry for the basic question), are you saying that when the service file is malformed the crash is unhelpful for debugging? Or that creating any/all services using is currently broken?
The YAML file is not malformed. I think there was something perhaps not quite right about firewalls/rules etc. and this caused to crash unhelpfully.
Change:
"//staging/src/k8s.io/cli-runtime/pkg/genericclioptions:go_default_library", "//staging/src/k8s.io/cli-runtime/pkg/printers:go_default_library", "//staging/src/k8s.io/cli-runtime/pkg/resource:go_default_library", <ins> "//staging/src/k8s.io/client-go/discovery:go_default_library", </ins> "//staging/src/k8s.io/client-go/kubernetes/typed/authorization/v1:go_default_library", "//staging/src/k8s.io/client-go/kubernetes/typed/core/v1:go_default_library", "//staging/src/k8s.io/client-go/kubernetes/typed/rbac/v1:go_default_library",

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 you expected to happen: if returns true I expect to be able to perform the action without issue. Note in this case my service user has a rolebinding in a single namespace (and that is also what my kubecontext is set to.) if I change my default to a different namespace then the command returns false How to reproduce it (as minimally and precisely as possible): create a namespace (test) create a service account in that namespace create a role that gives get list and watch permissions to create a rolebinding from that role to the service account. Anything else we need to know?: this is special because namespaces are not scoped to a namespace. if you replace the command with then you get the exepcted result however this breaks the path of least suprise. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: GKE OS (e.g: ): Kernel (e.g. ): Install tools: Others:
/sig auth
asks the authorization system if the given verb can be performed on the given noun at the given scope. It does not interpret whether the resource exists at that scope. We could warn if we find the specified resource and it does not exist at the specified scope (just like we warn if you ask about a resource that we can't find), but we would still interrogate the authorization system and return the results as we do today. /kind feature /remove-kind bug
/cc
Change:
cmds.AddCommand(NewCmdExplain(f, out)) cmds.AddCommand(NewCmdConvert(f, out)) <del> if cmds.Flag("namespace").Annotations == nil { cmds.Flag("namespace").Annotations = map[string][]string{} </del> <ins> if cmds.Flag("namespace") != nil { if cmds.Flag("namespace").Annotations == nil { cmds.Flag("namespace").Annotations = map[string][]string{} } cmds.Flag("namespace").Annotations[cobra.BashCompCustom] = append( cmds.Flag("namespace").Annotations[cobra.BashCompCustom], "__kubectl_get_namespaces", ) </ins> } <del> cmds.Flag("namespace").Annotations[cobra.BashCompCustom] = append( cmds.Flag("namespace").Annotations[cobra.BashCompCustom], "__kubectl_get_namespaces", ) </del> return cmds }

Discussion:
ci-kubernetes-e2e-gce-iscsi-serial and ci-kubernetes-e2e-gce-iscsi I guess it is create cluster step not tests Not clear I guess may be From I guess it is releated to /sig storage
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
From I get I think there's a problem here.