jiebi/CodeConvo huggingface dataset:
Code change:
<ins> #!/bin/sh # Copyright 2017 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. # A script encapsulating a common Dockerimage pattern for installing packages # and then cleaning up the unnecessary install artifacts. # e.g. clean-install iptables ebtables conntrack set -o errexit if [ $# = 0 ]; then echo >&2 "No packages specified" exit 1 fi apt-get update apt-get install -y --no-install-recommends $@ clean-apt </ins>

Related discussion:
text: main'
You can solve it temporary by removing I'm working on the solution
A solution here might be to base fluentd-es off an image with journald supporting XZ and LZ4 compression. I'm looking :)
Thanks
Code change:
stats := make(map[string]*statsapi.NetworkStats) for _, c := range containers { <del> container, err := hcsshim.OpenContainer(c.ID) </del> <ins> cstats, err := fetchContainerStats(c) </ins> if err != nil { <del> klog.V(4).Infof("Failed to open container %q with error '%v', continue to get stats for other containers", c.ID, err) </del> <ins> klog.V(4).Infof("Failed to fetch statistics for container %q with error '%v', continue to get stats for other containers", c.ID, err) </ins> continue } <del> cstats, err := container.Statistics() if err != nil { klog.V(4).Infof("Failed to get statistics for container %q with error '%v', continue to get stats for other containers", c.ID, err) continue } </del> if len(cstats.Network) > 0 { stats[c.ID] = hcsStatsToNetworkStats(cstats.Timestamp, cstats.Network) }

Related discussion:
text: <!-- 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: 's memory usage is increasing over time. When more pods are run, it increases even more. What you expected to happen: it should not keep increasing How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.14.0 Cloud provider or hardware configuration: AKS OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: !
/sig windows /sig azure
/assign
Code change:
<ins> /* Copyright 2017 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 clientcmd import ( "testing" "github.com/spf13/pflag" ) func TestNamespacePrefixStrip(t *testing.T) { testData := map[string]string{ "namespaces/foo": "foo", "NAMESPACES/foo": "foo", "NameSpaces/foo": "foo", "namespace/foo":  "foo", "NAMESPACE/foo":  "foo", "nameSpace/foo":  "foo", "ns/foo":         "foo", "NS/foo":         "foo", "namespaces/":    "namespaces/", "namespace/":     "namespace/", "ns/":            "ns/", } for before, after := range testData { overrides := &ConfigOverrides{} fs := &pflag.FlagSet{} BindOverrideFlags(overrides, fs, RecommendedConfigOverrideFlags("")) fs.Parse([]string{"--namespace", before}) if overrides.Context.Namespace != after { t.Fatalf("Expected %s, got %s", after, overrides.Context.Namespace) } } } </ins>

Related discussion:
text: the use cases I've observed doing code reviews: over all namespaces to get certain resources from that namespace: over all namespaces, then iterate of over resource types that produce logs and fetch logs one by one: Above we can use for listing pods because later we'll pass it to that accept the syntax. We cannot do the same for namespaces, because doesn't like the format.
Alternatively we could be kubectl recognize as valid
I'll take a look on it if it's not taken by anyone yet. CC
Have you started this?
Only investigated due to being out of office since Thursday last week. I can work on it in upcoming week, but I'll understand if it's piority issue and you'll reassign it.
Ready :-)
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list .
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
Code change:
test.old.Spec.RestartPolicy = "Always" } <del> errs := ValidatePodUpdate(&test.new, &test.old, PodValidationOptions{}) </del> <ins> errs := ValidatePodUpdate(&test.new, &test.old, test.opts) </ins> if test.err == "" { if len(errs) != 0 { t.Errorf("unexpected invalid: %s (%+v)nA: %+vnB: %+v", test.test, errs, test.new, test.old)

Related discussion:
text: See for context. This issue is creating to track work on the API validation changes. Validation relaxation of certain fields in the pod spec to allow for mutable scheduling directives.
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 scheduling
Docs PR:
Code change:
masqueradeValue := 1 << uint(masqueradeBit) masqueradeMark := fmt.Sprintf("%#08x/%#08x", masqueradeValue, masqueradeValue) <del> if nodeIP == nil { klog.Warning("invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP") nodeIP = net.ParseIP("127.0.0.1") } </del> if len(clusterCIDR) == 0 { klog.Warning("clusterCIDR not specified, unable to distinguish between internal and external traffic") } else if utilnet.IsIPv6CIDRString(clusterCIDR) != ipt.IsIpv6() {

Related discussion:
text: <!-- 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: Using Kubernetes 1.16.1, I started kube-proxy in iptables mode as a static pod on a master node. The master node was intentionally (and permanently) not available in the API as a Node object. kube-proxy started up and terminated soon after because it failed to (which is supposed to function as the bound address) and eventually returned an error: What you expected to happen: I expected the same behavior as in Kubernetes 1.15 where failure to look up the Node in the API would result in . How to reproduce it (as minimally and precisely as possible): Configure kube-proxy with iptables mode on Kubernetes 1.16 without the hosting Node being available in the Kubernetes API (under the OS hostname). Anything else we need to know?: PR (Fix for kube-proxy to wait for some duration for the node to be defined) introduced an additional . I believe this is the part that is causing the change in behavior: in Kubernetes 1.15, the check would be omitted and cause to set the default bind address to 127.0.0.1 (when iptables mode is set; I haven't checked other modes). The PR's primary purpose seems to be a different one (retrying node IP retrieval from the API), so my understanding is that the check was not really needed; unless I'm misunderstanding things which I don't want to rule out at all. The quick workaround was to explicitly configure kube-proxy with . However, I'm not entirely sure if that's a good solution long-term compared to letting Kubernetes do The Right Thing, which is what I'd like to clarify through this issue. Environment: Kubernetes version (use ): v1.16.1 Cloud provider or hardware configuration: Kubernetes running on DigitalOcean VMs (droplets) OS (e.g: ): Debian GNU/Linux 9 (stretch) Kernel (e.g.
Code change:
masqueradeValue := 1 << uint(masqueradeBit) masqueradeMark := fmt.Sprintf("%#08x/%#08x", masqueradeValue, masqueradeValue) <del> if nodeIP == nil { klog.Warning("invalid nodeIP, initializing kube-proxy with 127.0.0.1 as nodeIP") nodeIP = net.ParseIP("127.0.0.1") } </del> if len(clusterCIDR) == 0 { klog.Warning("clusterCIDR not specified, unable to distinguish between internal and external traffic") } else if utilnet.IsIPv6CIDRString(clusterCIDR) != ipt.IsIpv6() {

Related discussion:
text: ): Linux master-k8s-1-16-test1 4.19.0-0.bpo.6-amd64 SMP Debian 4.19.67-2+deb10u1~bpo9+1 (2019-09-30) x86_64 GNU/Linux /sig network /cc who were involved in the referenced PR.
I made a similar comment in , wondering if this is a breaking change in v1.16 that we should revert? Previously if is nil, kube-proxy defaults to but now kube-proxy always exits with error instead of defaulting to local host. I think a lot of external cloud providers relied on this behavior because they needed to talk to API server prior to node addresses being set by the provider. Thoughts /assign
Opened to preserve behavior before v1.16 where node IP defaults to 127.0.01 is none is found. PTAL
Code change:
"path" "time" <ins> "github.com/onsi/ginkgo" "github.com/onsi/gomega" </ins> v1 "k8s.io/api/core/v1" <ins> rbacv1 "k8s.io/api/rbac/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/fields" "k8s.io/apimachinery/pkg/labels"

Related discussion:
text: Which jobs are failing: Which test(s) are failing: Since when has it been failing: Last successful run (23 Oct 2020, 10:07 PDT): First unsuccessful run (23 Oct 2020, 12:08 PDT): Testgrid link: Reason for failure: Anything else we need to know: presubmit job in repository also started to fail in the same fashion. Attempted to debug it myself, found out the following stuff: last successful run was accessing the apiserver via HTTP: all unsuccessful runs attempted to access the apiserver via HTTPS but to no avail: perused the history of to find out that the PR is almost certainly the reason of the failures (or rather uncovered some problem with the NPD or its tests): first, it coincides with the start of the failures of , second, we changed the default hostname of the apiserver in node tests in that PR. Judging by the code and the changes in the aforementioned PR I think that a quick mitigation would be to add a flag to the of these jobs. /assign /sig node /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
Opened for a mitigation that would make those jobs stop failing.
This won't work, unfortunately. Copying response:
I have filed to address this issue, but it seems I could not run the test in advance to verify my patch, did you know how to manually trigger the presubmit job?
Unfortunately I don't :/. My PR was also a wild guess. could you take a look at the proposed fix? Thanks once again for your help - really appreciated :).
the submission of hasn't fixed the problems, unfortunately :/. Sample failing run: We still have some peculiar problem related to health checking: and now NPD panics, too:
Thanks for your report, I believe the reason is admission controller has been disabled in node e2e tests: We need to figure out a new approach now. /reopen
Reopened this issue.
Code change:
"path" "time" <ins> "github.com/onsi/ginkgo" "github.com/onsi/gomega" </ins> v1 "k8s.io/api/core/v1" <ins> rbacv1 "k8s.io/api/rbac/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/fields" "k8s.io/apimachinery/pkg/labels"

Related discussion:
text: <detailsIn response to : Thanks for your report, I believe the reason is admission controller has been disabled in node e2e tests: We need to figure out a new approach now. 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
filed . I hope we could completely address this issue this time.
/milestone v1.20
Code change:
klog.Infof("Request Headers:") for key, values := range reqInfo.RequestHeaders { for _, value := range values { <ins> value = maskValue(key, value) </ins> klog.Infof("    %s: %s", key, value) } }

Related discussion:
text: This issue was reported in the Description Kubernetes requires an authentication mechanism to enforce users’ privileges. One method of authentication, bearer tokens, are opaque strings used to associate a user with their having successfully authenticated previously. Any user with possession of this token may masquerade as the original user (the “bearer”) without further authentication. Within Kubernetes, the bearer token is captured within the hyperkube kube-apiserver system logs at high verbosity levels (--v 10). A malicious user with access to the system logs on such a system could masquerade as any user who has previously logged into the system. Exploit Scenario Alice logs into a Kubernetes cluster and is issued a Bearer token. The system logs her token. Eve, who has access to the logs but not the production Kubernetes cluster, replays Alice’s Bearer token, and can masquerade as Alice to the cluster. Recommendation Short term, remove the Bearer token from the log. Do not log any authentication credentials within the system, including tokens, private keys, or passwords that may be used to authenticate to the production Kubernetes cluster, regardless of the logging level. Long term, either implement policies that enforce code review to ensure that sensitive data is not exposed in logs, or implement logging filters that check for sensitive data and remove it prior to outputting the log. In either case, ensure that sensitive data cannot be trivially stored in logs. Anything else we need to know?: See for current status of all issues created from these findings. The vendor gave this issue an ID of TOB-K8S-001 and it was finding 6 of the report. The vendor considers this issue Medium Severity. To view the original finding, begin on page 31 of the Environment: Kubernetes version: 1.13.4
/sig auth /sig api-machinery
/remove-kind feature /kind bug
Should remote the "Authorization" header here?
for authorization headers, everything after the type should be masked (and potentially, only recognized auth types should be logged). Something like:
I think people would be unpleasantly surprised to see credentials in a logfile after turning up logging to debug an issue. /priority important-soon
Does either of you intend to createe PR to remove the "Authorization" header ?
Code change:
klog.Infof("Request Headers:") for key, values := range reqInfo.RequestHeaders { for _, value := range values { <ins> value = maskValue(key, value) </ins> klog.Infof("    %s: %s", key, value) } }

Related discussion:
text: This issue seems CVE-worthy to me: loss of confidentiality (bearer tokens) + cross of privilege boundary (debug log level could be set by admin, then logs read later by low privileged user). My draft cvss would be: CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N (5.3)
Two potential vectors: local user with access to system logs (local access, low privilege) (4.7) remote user with access to system logs (network access, high privilege): (4.4) CVE-2019- has been assigned to this issue.
If you want to, go ahead
- should this have the official CVE feed label ( retrospectively, I mean)?
probably? I have no idea how that label is supposed to get applied, but there appear to be several CVE issues that don't have it -
I think you're likely to know who to highlight this to. Sorry to mention you individually; please feel free to point out docs if there are any.
/label official-cve-feed thanks for the tag, the label now!
thanks for the useful filter. Currently in-scope issues are issues that were closed as fixed by code changes to k/k. So with that in mind, I have the labels to some of the closed issues too that conform to the scope defined here:
I would like to reply nearly four years later: There are valid cases to want to see the token, for example my current case, trying to debug token validation between the API server and other services.
Code change:
return intr.Run(func() error { _, err := watch.Until(0, w, func(e watch.Event) (bool, error) { // print deployment's status <del> status, done, err := statusViewer.Status(cmdNamespace, info.Name, revision) </del> <ins> status, done, err := statusViewer.Status(info.Namespace, info.Name, revision) </ins> if err != nil { return false, err }

Related discussion:
text: <!-- 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 ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): rollout status namespace Is this a BUG REPORT or FEATURE REQUEST? (choose one): Bug Report <!-- 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: Macbook Pro 2015 OS (e.g. from /etc/os-release): Mac OSX Sierra Kernel (e.g. ): Install tools: Others: What happened: , where does the following: Describes a Deployment object Sets a non-default namespace in the metadata . An error message says the resource was not found . The response shows the status of the rollout. What you expected to happen: I expected to work as well by using the namespace that is set inside for the rollout status request. How to reproduce it (as minimally and precisely as possible): the following file as (taken from the but updated to add the namespace): Returns Returns Anything else we need to know: We've seen this issue on 1.5.1 as well, and also on Ubuntu. The recreate instructions above were performed on a fresh minikube setup.
I also noticed this today. The node is using version 1.5.2 and we are using latest gcloud SDK components (v146). At the moment I have to use
This issue also exists on kubectl built from HEAD.
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.
Code change:
return intr.Run(func() error { _, err := watch.Until(0, w, func(e watch.Event) (bool, error) { // print deployment's status <del> status, done, err := statusViewer.Status(cmdNamespace, info.Name, revision) </del> <ins> status, done, err := statusViewer.Status(info.Namespace, info.Name, revision) </ins> if err != nil { return false, err }

Related discussion:
text: Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Code change:
"sync" "time" <ins> cadvisormemory "github.com/google/cadvisor/cache/memory" </ins> cadvisorfs "github.com/google/cadvisor/fs" cadvisorapiv2 "github.com/google/cadvisor/info/v2" "google.golang.org/grpc/codes"

Related discussion:
text: What happened: New overlay filesystems created for Pods after kubelet start trigger repeated error messages. For example: Error messages are logged every 10 seconds for every filesystem created after kubelet start. For large kubelet nodes, this issue creates an excessive amount of error logs. What you expected to happen: New overlay filesystems created for Pods after kubelet start should not log error messages. How to reproduce it (as minimally and precisely as possible): Use cristatsprovider with cri-o and configure overlay storage. UsingLegacyCadvisorStats() needs to return false per for cristatsprovider to be used. Start with an empty /var/lib/containers/storage and schedule Pods on the node. Anything else we need to know?: As part of , cadvisor.GetFsInfoByFsUUID() was changed to cadvisor.GetDirFsInfo() in getFsInfo(); however, the test for cadvisorfs.ErrNoSuchDevice was not modified, changing how getFsInfo() handles a cache miss from cadvisor. cadvisor caches UUIDs/partitions/mounts on kubelet start and the cache is never refreshed. Given that it's expected that getFsInfo() will fail to retrieve data from cadvisor (see comments in ImageFsStats() and ), this condition should not be logged as an error. Alternatively, cadvisor fs could be modified to refresh on cache miss enabling getFsInfo() to return data on these filesystems. Environment: Kubernetes version (use ): 1.18.6 CRI: CRI-O
/sig node cc
ptal
thanks for reporting the issue. I will take a look at in upcoming week.
/assign
Sorry this is taking slightly longer. Currently held up in something little urgent, but as soon as that's over I will look into this one.
Do you have the time to look at this issue ? I can help with testing / debugging if required. Environment Kubernetes 1.19.3 Cri-o 1.19.0
Sorry I haven't gotten a chance to look into it yet, I would certainly appreciate any help in debugging. Thanks.
Right now I am thinking of either handling the cache miss better, or returning the even if the fs type is not in cadvisor, or both.
Issues go stale after 90d of inactivity. Mark the issue as fresh with .