jiebi/CodeConvo huggingface dataset:
Code change:
<ins> /* Copyright 2020 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 logs import ( "fmt" "sync" "github.com/go-logr/logr" ) var logRegistry = NewLogFormatRegistry() // LogFormatRegistry store klog format registry type LogFormatRegistry struct { registry map[string]logr.Logger mu       sync.Mutex } // NewLogFormatRegistry return new init LogFormatRegistry struct func NewLogFormatRegistry() *LogFormatRegistry { return &LogFormatRegistry{ registry: make(map[string]logr.Logger), mu:       sync.Mutex{}, } } // Register new log format registry to global logRegistry func (lfr *LogFormatRegistry) Register(name string, logger logr.Logger) error { lfr.mu.Lock() defer lfr.mu.Unlock() if _, ok := lfr.registry[name]; ok { return fmt.Errorf("log format: %s already exists", name) } lfr.registry[name] = logger return nil } // Get specified log format logger func (lfr *LogFormatRegistry) Get(name string) (logr.Logger, error) { lfr.mu.Lock() defer lfr.mu.Unlock() re, ok := lfr.registry[name] if !ok { return nil, fmt.Errorf("log format: %s does not exists", name) } return re, nil } // Set specified log format logger func (lfr *LogFormatRegistry) Set(name string, logger logr.Logger) { lfr.mu.Lock() defer lfr.mu.Unlock() lfr.registry[name] = logger } // Delete specified log format logger func (lfr *LogFormatRegistry) Delete(name string) { lfr.mu.Lock() defer lfr.mu.Unlock() delete(lfr.registry, name) } func init() { // Text format is default klog format logRegistry.Register("text", nil) } </ins>

Related discussion:
text: What would you like to be : As part of should add logging configuration allowing to change logging implementation. Things to implement: --logging-format - flag to pick between available implementations. Defaults to "text" using unchanged klog. LoggingConfig - structure storing component configuration for logging LogFormatRegistry - Used for registration of additional log formats. New formats should be registered by providing unique name and implementation of interface LoggingConfig.Complete method should configure klog by passing logr interface implementation into klog.SetLogger method Why is this needed: Subtask of /help /wg component-standard
The klog 1.0.0 version looks like no SetLogger method, should update klog version in vendor?
yes, forgot about that. I remember saying that it will require some changes, but shouldn't be to hard. I will help with it if needed.
/assign /remove-help
Klog was upgraded to v2.
Code change:
if apierrs.IsMethodNotSupported(err) || apierrs.IsNotFound(err) || apierrs.IsForbidden(err) { continue } <ins> // skip unavailable servers if apierrs.IsServiceUnavailable(err) { continue } </ins> return false, err } unstructuredList, ok := obj.(*unstructured.UnstructuredList)

Related discussion:
text: https://k8s- https://k8s- https://k8s- https://k8s- https://k8s- ... A lot of them /cc
/assign
Still see this failure after is merged, although less frequently: https://k8s- https://k8s- Reopen.
Looks like the client doesn't differentiate between 500 and 503 here: It should. Will open a fix shortly
opened
fix merged, will monitor https://k8s-
Thanks! :)
haven't seen this in the 12 hours since the fix merged, was seeing it every 2-3 hours before. /close
Code change:
TEMP_DIR:=$(shell mktemp -d) ifeq ($(ARCH),amd64) <del> BASEIMAGE?=k8s.gcr.io/build-image/debian-base:v2.1.3 </del> <ins> BASEIMAGE?=k8s.gcr.io/build-image/debian-base:buster-v1.2.0 </ins> endif ifeq ($(ARCH),arm) <del> BASEIMAGE?=k8s.gcr.io/build-image/debian-base-arm:v2.1.3 </del> <ins> BASEIMAGE?=k8s.gcr.io/build-image/debian-base-arm:buster-v1.2.0 </ins> endif ifeq ($(ARCH),arm64) <del> BASEIMAGE?=k8s.gcr.io/build-image/debian-base-arm64:v2.1.3 </del> <ins> BASEIMAGE?=k8s.gcr.io/build-image/debian-base-arm64:buster-v1.2.0 </ins> endif ifeq ($(ARCH),ppc64le) <del> BASEIMAGE?=k8s.gcr.io/build-image/debian-base-ppc64le:v2.1.3 </del> <ins> BASEIMAGE?=k8s.gcr.io/build-image/debian-base-ppc64le:buster-v1.2.0 </ins> endif ifeq ($(ARCH),s390x) <del> BASEIMAGE?=k8s.gcr.io/build-image/debian-base-s390x:v2.1.3 </del> <ins> BASEIMAGE?=k8s.gcr.io/build-image/debian-base-s390x:buster-v1.2.0 </ins> endif RUNNERIMAGE?=gcr.io/distroless/static:latest

Related discussion:
text: What would you like to be : Have debian-iptables with iptables 1.8.5+ Why is this needed: To fix (nodelocaldns + iptables-nft) More informations Found a bug in iptables-nft, fixed in iptables 1.8.5, and now available in buster-backports https://alioth-
/sig api-machinery
ping as you did the last 2 updates
Yep, this is on my list. Will take of it next week. /sig release network /area release-eng /milestone v1.20 /assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Opened to bump the debian-iptables images in kubernetes/kubernetes. /remove-triage unresolved
Here are the digests for the new image ():
Please reopen if you run into any issues with the new images. /close
Closing this issue. <detailsIn response to : Please reopen if you run into any issues with the new images. /close 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:
framework.ExpectError(err) gomega.Expect(err).To(gomega.ContainSubstring("Using in-cluster namespace")) gomega.Expect(err).To(gomega.ContainSubstring("Using in-cluster configuration")) <del> gomega.Expect(err).To(gomega.ContainSubstring("Authorization: Bearer invalid")) </del> gomega.Expect(err).To(gomega.ContainSubstring("Response Status: 401 Unauthorized")) ginkgo.By("trying to use kubectl with invalid server")

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:
framework.ExpectError(err) gomega.Expect(err).To(gomega.ContainSubstring("Using in-cluster namespace")) gomega.Expect(err).To(gomega.ContainSubstring("Using in-cluster configuration")) <del> gomega.Expect(err).To(gomega.ContainSubstring("Authorization: Bearer invalid")) </del> gomega.Expect(err).To(gomega.ContainSubstring("Response Status: 401 Unauthorized")) ginkgo.By("trying to use kubectl with invalid server")

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:
klog.V(2).InfoS("Preemptor Pod preempted victim Pod", "preemptor", klog.KObj(pod), "victim", klog.KObj(victim), "node", c.Name()) } <del> fh.EventRecorder().Eventf(victim, pod, v1.EventTypeNormal, "Preempted", "Preempting", "Preempted by a pod on node %v", c.Name()) </del> <ins> fh.EventRecorder().Eventf(victim, pod, v1.EventTypeNormal, "Preempted", "Preempting", "Preempted by pod %v on node %v", pod.UID, c.Name()) </ins> } fh.Parallelizer().Until(ctx, len(c.Victims().Pods), preemptPod, ev.PluginName)

Related discussion:
text: /sig scheduling Include the Pod UID in the event message for preemption by kube-scheduler Minimizes the need for an end user to consult the ops team to learn about what caused their pods to be preempted, without compromising PII. From
/triage accepted
Can I pick this up?
Yes, just type . Note that we are in code freeze, so this won't be merged until about a month from now.
/assign
PII? I know that as personally identifying information (ie, data about humans).
BTW, ideally we'd also document the change.
In a multi-tenant environment, pod names could be sensitive information.
Code change:
- key: cloud.google.com/gke-accelerator operator: Exists tolerations: <del> - key: "nvidia.com/gpu" </del> <ins> - operator: "Exists" effect: "NoExecute" - operator: "Exists" </ins> effect: "NoSchedule" <del> operator: "Exists" </del> hostNetwork: true hostPID: true volumes:

Related discussion:
text: This issue is here to satisfy PR requirements of issue association. A lot of times we need to do version bumps for minor bug fixes that don't deserve a separate issue in the kubernetes/kubernetes repo. /kind bug /sig node
/lifecycle frozen
all the linked PRs are emrged and no activity since more than 3 years /close
Closing this issue. <detailsIn response to : all the linked PRs are emrged and no activity since more than 3 years /close 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:
// another goroutine isn't already in action. func (kl *Kubelet) podKiller() { killing := sets.NewString() <del> resultCh := make(chan types.UID) defer close(resultCh) </del> <ins> // guard for the killing set lock := sync.Mutex{} </ins> for { select { case podPair, ok := <-kl.podKillingCh:

Related discussion:
text: There is a defer calling in this method: defer close(resultCh) It may crash the goroutine created at line 777, which then will make the whole kubelet crash. A simple fix Another simple fix
cc do you think this make sense?
You could just drop the channel and go with a mutex to update the set.
indeed.
Code change:
func stringBody(body string) io.ReadCloser { return ioutil.NopCloser(bytes.NewReader([]byte(body))) } <ins> // Verify that resource.RESTClients constructed from a factory respect mapping.APIVersion func TestClientVersions(t *testing.T) { f := NewFactory(nil) versions := []string{ "v1beta1", "v1beta2", "v1beta3", } for _, version := range versions { mapping := &meta.RESTMapping{ APIVersion: version, } c, err := f.RESTClient(nil, mapping) if err != nil { t.Errorf("unexpected error: %v", err) } client := c.(*client.RESTClient) if client.APIVersion() != version { t.Errorf("unexpected Client APIVersion: %s %v", client.APIVersion, client) } } } </ins>

Related discussion:
text: I stumbled across this while experimenting with kubeconfig load order/merging. There are various helpers constructed from a Factory that use , however this always uses the same default ClientConfig because doesn't use the passed in version param: Am I missing something or is this a bug? /cc
Looks like a bug, clientforversion should accept "" (which can provide a default) and SetKubernetesDefaults has the final fallback protection (by using latest.Version). If version != defaultConfig.Version, we should copy defaultConfig, set version, then apply kubedefaults. The reason we take version here is if a resource is specified via file which only exists in a newer version, ie user says: --api-version=v1beta1 -f RESTMapper can handle that newresource is only valid for v1beta3 and apply the right override, then ask for client. --api-version is expected to bubble up via default config.
Code change:
if err != nil || portal != "127.0.0.1:3260" || iqn != "eui.02004567A425678D" { t.Errorf("extractPortalAndIqn: got %v %s %s", err, portal, iqn) } <ins> devicePath = "[2001:db8:0:f101::1]:3260-iqn.2014-12.com.example:test.tgt00-lun-0" portal, iqn, err = extractPortalAndIqn(devicePath) if err != nil || portal != "[2001:db8:0:f101::1]:3260" || iqn != "iqn.2014-12.com.example:test.tgt00" { t.Errorf("extractPortalAndIqn: got %v %s %s", err, portal, iqn) } </ins> } func TestRemoveDuplicate(t *testing.T) {

Related discussion:
text: Kubelet was not able to attach + mount an iSCSI PV when it has IPv6 server address. Volume is mounted + attached. Set up iSCSI target that's reachable over IPv6 and create a PV for it. For example: Kubelet logs: Notice around the IP address. Various iSCSI files in /sys and /dev/disk/by-path do not have these square brackets and kubelet is then not able to find the iSCSI host in /sys. That's where comes from. No response <detailsA recent master: console NAME="Fedora Linux" VERSION="36 (Workstation Edition)" </details<detailshack/local-up- </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 storage /priority important-soon
/assign
Code change:
// Wait for the DaemonSet to be created before proceeding err = waitForDaemonSetAndControllerRevisionCreated(clientset, ds.Name, ds.Namespace) if err != nil { <del> t.Fatalf("Failed to create DeamonSet: %v", err) </del> <ins> t.Fatalf("Failed to create DaemonSet: %v", err) </ins> } ds, err = dsClient.Get(ds.Name, metav1.GetOptions{})

Related discussion:
text: https://k8s- /sig apps /priority critical-urgent /assign PR that the test: /cc
GitHub didn't allow me to assign the following users: mortent. Note that only and repo collaborators can be assigned. For more information please see <detailsIn response to : https://k8s- /priority critical-urgent /assign /cc 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
/kind flake
I'm looking into this.
The test is still flaky, but with different symptom: An example flake: https://k8s- It's likely because the collision count was updated in a previous sync loop, but the in the cache store hasn't been updated and we used a stale collision count while calculating the new hash: /assign
Code change:
// the various afterEaches afterEaches map[string]AfterEachActionFunc <ins> // beforeEachStarted indicates that BeforeEach has started beforeEachStarted bool </ins> // configuration for framework's client Options Options

Related discussion:
text: What happened: When running external CSI Driver tests with the Kubernetes E2E: We seem to be getting the following error. From initial investigation it looks like this happens in the during check but only when the test is being skipped. Hunch is that maybe since the test is skipped some resources are never created or they are cleaned up already and they are nil when the is called and expecting them. Kind of low priority since it doesn't make any tests actually fail. /cc /sig storage
see
I think should address this
Code change:
# etcd - name: "etcd" <del> version: 3.5.0-rc.0 </del> <ins> version: 3.5.0 </ins> refPaths: - path: cluster/gce/manifests/etcd.manifest match: etcd_docker_tag|etcd_version

Related discussion:
text: /sig scalability This issue is tracking process of upgrading etcd to 3.5.0 planned for 1.22 K8s release. Etcd has recently released Beta versions and is starting the process of correctness and performance testing. To reduce change of finding performance regression late, we will start qualifying Beta Etcd releases on GKE master branch and will upgrade to 3.5.0 as soon as it is available. Steps: [x] Do preliminary scale testing of etcd v3.5.0-beta.3 release [x] Release etcd v3.5.0-beta.3 image (, ) [x] Release etcd v3.5.0-rc.0 image () [x] Upgrade etcd server to v3.5.0-rc.0 () [x] Wait for 3.5.0 release and upgrade etcd client () [x] Release etcd v3.5.0 image (, ) [x] Upgrade etcd server to v3.5.0 /milestone v1.22
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
/area etcd
Does this meant that the 3.5.0 should be promoted like
Yes, created
/area release-eng release-team /sig release For tracking: cc:
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /area release-eng release-team /sig release cc: 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
I do think this can be pointed in the Major Themes for the 1.22 release. I would like your opinions on this. If you do think it has a place in it, I will add it to the .
How can I be a contributor to this issue? what are the technical checklist that needs to be achieved to close out on the issue?
Code change:
# etcd - name: "etcd" <del> version: 3.5.0-rc.0 </del> <ins> version: 3.5.0 </ins> refPaths: - path: cluster/gce/manifests/etcd.manifest match: etcd_docker_tag|etcd_version

Related discussion:
text: PR to update Etcd is ready, but we found a blocker for merging . There is one test failing I will take a look into it on Monday, still more eyes on the problem could speed up resolution.
We'll also need a new kube-cross image w/ etcd v3.5.0. I'm working on that here:
We just need to upgrade the server to use new image like in
ok, looks like is busy. Let me take a look /assign
Thanks.
Code change:
"fmt" "io" "net/url" <ins> "strings" </ins> "time" "github.com/spf13/cobra"

Related discussion:
text: When attaching to an ephemeral container, prints a message suggesting that the container can be reattached after it exists. This is not true because an ephemeral container is never restarted. This cosmetic issue should be resolved for
/assign /sig node /triage accepted /priority important-longterm
Code change:
function ensure-local-disks() { <ins> # Skip if already mounted (a reboot) if ( grep "/mnt/ephemeral" /proc/mounts ); then echo "Found /mnt/ephemeral in /proc/mounts; skipping local disk initialization" return fi </ins> block_devices=() ephemeral_devices=$(curl --silent http://169.254.169.254/2014-11-05/meta-data/block-device-mapping/ | grep ephemeral)

Related discussion:
text: On AWS we (will) now run our bootstrap script on every boot. The function to initialize ephemeral volumes doesn't tolerate being re-run, and we probably shouldn't re-run it anyway for speed. This does preserve the contents, which may be a good thing to save user's data (it doesn't belong on ephemeral drives, but...). On the other hand, if the ephemeral drives are corrupted, we lose the opportunity to reformat them and recover. Arguably, if the ephemeral storage is corrupted the right thing to do is to terminate the instance entirely.
Code change:
<ins> apiVersion: "v1beta1" kind: "ReplicationController" id: "monitoring-influxGrafanaController" desiredState: replicas: 1 replicaSelector: name: "influxGrafana" podTemplate: labels: name: "influxGrafana" desiredState: manifest: version: "v1beta1" id: "monitoring-influxGrafanaController" containers: - name: "influxdb" image: "kubernetes/heapster_influxdb:v0.2" ports: - containerPort: 8083 hostPort: 8083 - containerPort: 8086 hostPort: 8086 - name: "grafana" image: "kubernetes/heapster_grafana:v0.2" ports: - containerPort: 80 hostPort: 80 env: - name: "HTTP_USER" value: "admin" - name: "HTTP_PASS" value: "**None**" labels: name: "influxGrafana" </ins>

Related discussion:
text: examples/monitoring/influx-grafana- and friends NEED to be replaced by a replication controller ASAP. As it stands they are bad examples. Also, they should probably move to contrib/monitoring to match contrib/logging and contrib/dns
Code change:
{ Object: map[string]interface{}{ "apiVersion": "example.com/v1", <ins> "metadata":   map[string]interface{}{}, </ins> "kind":       "foo", "other":      "data2", },

Related discussion:
text: If a CR converter is wired in and it modifies the input list, the delegating CR converter does not protect against this. A converter cannot effect the input list Not really possible externally - it's a coding issue that the current converters don't hit. No response <details</details<detailsN/A </details<details</details<details</details<details</details<details</details
/sig api-machinery /assign
/triage accepted