jiebi/CodeConvo huggingface dataset:
Change:
// Convert errors into failures to catch timeouts. return probe.Failure, err.Error(), nil } <ins> if _, ok := headers["User-Agent"]; !ok { if headers == nil { headers = http.Header{} } // explicitly set User-Agent so it's not set to default Go value v := version.Get() headers.Set("User-Agent", fmt.Sprintf("kube-probe/%s.%s", v.Major, v.Minor)) } </ins> req.Header = headers if headers.Get("Host") != "" { req.Host = headers.Get("Host")

Discussion:
Grabbed tcpdump of a readiness probe - the src ip was the bridge address (10.244.1.1), but apart from this, there is no identifying information in the HTTP request that this is a Kubernetes daemon requesting readiness checks - this might help QoS/priority assignment by the container application.
IIUC, you mean we should add a better when kubernetes daemon request a readiness check to identify this request comes from kubernetes daemon?
Yes, we should override the default net/http user-agent with our own. Better usability for users and we have no future upgrade hazards if users start hardcoding and expecting this default User-Agent string in their analytic tools.
Any news about this one? It would be nice! I've this little hack in my nginx configuration (in order to not be spamed by health check in logs) :)
This can probably be closed now that probes have support.
Change:
srcs = [ "aggregator.go", "apiextensions.go", <del> "plugins.go", </del> "server.go", ], deps = [

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The current help message from kube-apiserver is wrong. It shows only the 'NamespaceLifecycle' plug-in is available, and the default value is . Users cannot know what are the available plug-ins, and they get confused where comes from. What you expected to happen: The correct output should be this: How to reproduce it (as minimally and precisely as possible): Run using master or at least 1.7.2. Anything else we need to know?: This is a regression introduced when refactoring code into generic server code. Environment: Kubernetes version (use ): 1.7.2+ ? Cloud provider or hardware configuration**: Any OS (e.g. from /etc/os-release): Any Kernel (e.g. ): Any Install tools: Any Others: None
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
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
Yes, it is really exist. If no guys works on this, i will pick it up.
Thanks for confirming this. I'm already working on it. Will submit pr in minutes.
cool. :)
Change:
key := getStableKey(pod, container) if backOff.IsInBackOffSince(key, ts) { if containerRef, err := kubecontainer.GenerateContainerRef(pod, container); err == nil { <del> m.recorder.Eventf(containerRef, v1.EventTypeWarning, events.BackOffStartContainer, "Back-off restarting failed container") </del> <ins> m.recorder.Eventf(containerRef, v1.EventTypeWarning, events.BackOffStartContainer, fmt.Sprintf("Back-off restarting failed container %s in pod %s", container.Name, format.Pod(pod))) </ins> } err := fmt.Errorf("back-off %s restarting failed container=%s pod=%s", backOff.Get(key), container.Name, format.Pod(pod)) klog.V(3).InfoS("Back-off restarting failed container", "err", err.Error())

Discussion:
Add back-off restarting failed container name in the event message, like: When there are multiple containers in a pod, we use to show the event, it is not showing the failed container name, but it is useful and needed.
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 node
Maybe we can get the container information from upper, including State, Last State...
Yes, we can see more info on the upper part, but it is more straight-forward to see the container name in the event msg, especially when there are multiple containers in a pod.
I think it is a valuable feature.
Change:
externalInformers.Core().V1().Pods().Lister(), ) serviceAccountTokenAuth := serviceaccount.JWTTokenAuthenticator([]string{serviceaccount.LegacyIssuer}, []interface{}{&serviceAccountKey.PublicKey}, nil, serviceaccount.NewLegacyValidator(true, serviceAccountTokenGetter)) <del> authenticator := union.New( </del> <ins> authenticator := group.NewAuthenticatedGroupAdder(union.New( </ins> bearertoken.New(rootTokenAuth), bearertoken.New(serviceAccountTokenAuth), <del> ) </del> <ins> )) </ins> // Set up a stub authorizer: // 1. The "root" user is allowed to do anything

Discussion:
While moving APF to beta (see comments on ), we discovered that the integration tests commonly present users which are not members of any groups. We had thought that the system enforced membership in either the authenticated or unauthenticated group. If this is supposed to be a system invariant (as we thought), we'd like to ask SIG Auth: Please fix the integration tests Please add e.g. logging so that if real, operational clusters hit this there's at least a log message and people will file bugs. /sig auth
Can I suggest also, if this is a real invariant, that it be documented in some place(s) likely to be read?
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-contributor-experience at . /lifecycle stale
/remove-lifecycle stale /priority important-longterm /triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/lifecycle frozen
fixes the authenticator configured in one of the integration test API server startup helpers which resolved this issue for . Remaining tests that still need fixing that are encountering unexpected users look to be ones set up to specifically test auth paths:
open to fix remaining integration test users
Change:
action.Value = opts _, _ = c.Fake.Invokes(action, &v1.Pod{}) <del> return &restclient.Request{} </del> <ins> fakeClient := &fakerest.RESTClient{ Client: fakerest.CreateHTTPClient(func(request *http.Request) (*http.Response, error) { resp := &http.Response{ StatusCode: http.StatusOK, Body:       ioutil.NopCloser(strings.NewReader("fake logs")), } return resp, nil }), NegotiatedSerializer: scheme.Codecs.WithoutConversion(), GroupVersion:         podsKind.GroupVersion(), VersionedAPIPath:     fmt.Sprintf("/api/v1/namespaces/%s/pods/%s/log", c.ns, name), } return fakeClient.Request() </ins> } func (c *FakePods) Evict(ctx context.Context, eviction *policy.Eviction) error {

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: I tried to use  in a unit test, however I get a nil pointer panic when is invoked. What you expected to happen: would return a that doesn't panic on any method call. Ideally, it would allow me to interact with the client in someway for testing. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: client-go version: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig testing
I believe this also impacts returning logs via a reactor as does not implement
Seems to be a problem with . Since we're creating the request with all empty fields. Not sure what the best way it to resolve this. The best thing I came up with is to use to return a request with everything set up. But I'm a noob here so that's just a shot in the dark :man_shrugging:
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
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
The request returned has a nil which is used in the
I have filed a PR trying to fix this issue.
Change:
return nil, err } <ins> var metricsProvider volume.MetricsProvider if plugin.capabilities.SupportsMetrics { metricsProvider = volume.NewMetricsStatFS(plugin.host.GetPodVolumeDir( pod.UID, utilstrings.EscapeQualifiedNameForDisk(sourceDriver), spec.Name())) } else { metricsProvider = &volume.MetricsNil{} } </ins> return &flexVolumeMounter{ flexVolume: &flexVolume{ driverName:            sourceDriver,

Discussion:
kind feature What happened: Currently there is no mechanism to report metrics as the flex plugins are not enabled to collect metrics. All flex volumes lack this feature as compared to in-tree/built-in drivers even though it is possible to collect such metrics for most of the plugins. What you expected to happen: Depending on the availability of the metrics from the mounted FS, flex plugins should allow to report metrics for the FS. How to reproduce it (as minimally and precisely as possible): The default behavior that can be proved easily by just running a command similar to the following command on a node that is running a flex volume. This will show that there are no metrics collected for flex volumes. kubectl proxy $curl 127.0.0.1:8001/api/v1/nodes/<IP/proxy/stats/summary Environment**: Kubernetes version (use ): 1.12 Cloud provider or hardware configuration: local x86 OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Linux KubeStorage 4.4.0-130-generic -Ubuntu SMP Thu Jun 14 08:53:28 UTC 2018 x8664 x8664 x86_64 GNU/Linux Install tools: Others: /sig storage
+1 Yes, it will be good, if flex volume can support atleast the default metrics( i.e ), which most of the volume plugins support now. Based upon flex plugin "capabilities" parameters, it can be decided, whether the plugin supports "default metrics" or "nil metrics".
Change:
klog.V(6).Infof("Optional subsystem not supported: hugetlb") } <del> manager, err := cgroupfs2.NewManager(cgroupConfig, cgroupConfig.Path, false) </del> <ins> manager, err := cgroupfs2.NewManager(cgroupConfig, filepath.Join(cmutil.CgroupRoot, cgroupConfig.Path), false) </ins> if err != nil { return fmt.Errorf("failed to create cgroup v2 manager: %v", err) }

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: is created on a cgroup2 host What you expected to happen: Such directory should not be created How to reproduce it (as minimally and precisely as possible): Boot Ubuntu 20.04 with Install moby/moby with containerd/containerd and opencontainers/runc Install kubernetes-sigs/kind . This version uses as the base image. Run with Run Run to drop into the shell of the node The following directories are unexpectedly created. (No process seems to belong to these groups actually) Environment: (See above)
cc
/sig node
Change:
// proxied by this service. Port int `json:"port"` <del> // Optional: Supports "TCP" and "UDP".  Defaults to "TCP". </del> <ins> // Required: Supports "TCP" and "UDP". </ins> Protocol Protocol `json:"protocol,omitempty"` // This service will route traffic to pods having labels matching this selector. If empty or not present,

Discussion:
Many comments in there say "if not specified, default is ..." - but we previously asserted that there are no defaults for the internal API. We should strip those comments out, and leave them in versioned structs only.
cc
Change:
"k8s.io/apiserver/pkg/storage/value" kmstypes "k8s.io/apiserver/pkg/storage/value/encrypt/envelope/kmsv2/v2alpha1" "k8s.io/apiserver/pkg/storage/value/encrypt/envelope/metrics" <ins> "k8s.io/klog/v2" </ins> "k8s.io/utils/lru" )

Discussion:
Add additional logging at level that associates UID with the metadata from the request. xref: /sig auth
/triage accepted
/milestone v1.26
Mind if I take a look at this? /assign
Hello I am wondering how's this coming along. Is there anything I can help with?
Sorry. I got a bit occupied with a different project.. Will have a PR opened for this for review tomorrow.. I am trying to find a way to inject the Verbs into log. But haven't found the right way to include that into the context.. Any suggestion on what can be done?
any suggestion on what is the best way to get the additional metadata for verbs into this log? Move that info across using ?
Hello , bug triage team here, just wanted to touch base with you for updates on this ticket. Thanks!
Thanks! This is being worked on and is still on track for .
There is a Pull request opened on this already as well. But Waiting on some clarification to see if that needs additional changes.
/reopen /assign /unassign
Reopened this issue. <detailsIn response to : /reopen /assign /unassign 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
/milestone v1.27
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Hi Bug Triage Team for v1.27 here o/ Just wanted to touch base with you for updates on this ticket. Thanks!
I am not working on this anymore Carlos. This was re-assigned
This is tracked for . I've linked the PR.
Change:
Portals       []string Iqn           string Lun           string <ins> InitIface     string </ins> Iface         string chapDiscovery bool chapSession   bool

Discussion:
What happened: When creating a block volume, the iSCSI storage plugin stores volume-related data in different directories: As a result, some data is not cleaned up once the volume is detached: How to reproduce it (as minimally and precisely as possible): These are the objects I used to reproduce this issue: pod- /sig storage CC
/assign
Change:
--- - createCoreV1NamespacedServiceAccountToken <del> - createCoreV1Node </del> - createStorageV1CSINode <del> - deleteCoreV1Node </del> - deleteStorageV1CollectionCSINode - deleteStorageV1CSINode - listStorageV1CSINode

Discussion:
[x] two weeks soak end date : 2024-09-08 According to following APIsnoop query, there are two Node endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 2 endpoints. The e2e logs for this test are listed below. This query shows the following Node endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 2 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/sig node
/reopen Tracking the next steps to conformance
Reopened this issue. <detailsIn response to : /reopen Tracking the next steps to conformance 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
/reopen Tracking the final step
Reopened this issue. <detailsIn response to : /reopen Tracking the final step 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:
profileName: profile, }, } <del> return f.ClientSet.Core().ConfigMaps(f.Namespace.Name).Create(cm) </del> <ins> _, err := f.ClientSet.Core().ConfigMaps(f.Namespace.Name).Create(cm) framework.ExpectNoError(err, "Failed to create apparmor-profiles ConfigMap") </ins> } <del> func createAppArmorProfileLoader(f *framework.Framework) (*extensions.DaemonSet, error) { </del> <ins> func createAppArmorProfileLoader(f *framework.Framework) { </ins> True := true <del> // Copied from https://github.com/kubernetes/contrib/blob/master/apparmor/loader/example-configmap.yaml loader := &extensions.DaemonSet{ </del> <ins> One := int32(1) loader := &api.ReplicationController{ </ins> ObjectMeta: metav1.ObjectMeta{ Name:      "apparmor-loader", Namespace: f.Namespace.Name, }, <del> Spec: extensions.DaemonSetSpec{ Template: api.PodTemplateSpec{ </del> <ins> Spec: api.ReplicationControllerSpec{ Replicas: &One, Template: &api.PodTemplateSpec{ </ins> ObjectMeta: metav1.ObjectMeta{ <del> Labels: map[string]string{"name": "apparmor-loader"}, </del> <ins> Labels: map[string]string{loaderLabelKey: loaderLabelValue}, </ins> }, Spec: api.PodSpec{ Containers: []api.Container{{

Discussion:
The "AppArmor load AppArmor profiles should enforce an AppArmor profile" e2e test in failing on our 5k-node gce clusters - https://k8s- (run no. 8) due to timeout: Seems like the test is trying to load the profiles across all the nodes using a daemonset and then running a test pod to check that. It's passing on our 2k-node clusters (https://k8s-) but failing for 5k - suggesting that it's likely due to size of the cluster. I think it's the ds creation taking longer on large cluster. cc
Seems like you're the most relevant here. Could one of you take a look into it? And does increasing the timeout for the test-pod based on no. of nodes sound reasonable?
Assigning it you since is OOO. Feel free to reassign as apt.
This is part of the correctness suite and large cluster tests are release-blocking.
FYI
Reassigning to who is back on Tuesday. He wrote the AppArmor stuff and should be able to debug this quickly. /assign
Ref
Could you manage to take a look into this?
Sorry, I meant to reply to this! I have a fix, just need to confirm it works. I think you're right about the DaemonSet timing out. There's no reason this needs to load the profiles on every node, so the fix just runs a single loader, and uses pod affinity to co-schedule the test pod.
Smooth!
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/node sig/scalability: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</aThe commands available for adding these labels are documented <a href=""here</a</details
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 kubectl import ( "reflect" "testing" "k8s.io/api/core/v1" extensionsv1beta1 "k8s.io/api/extensions/v1beta1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" ) func TestDeploymentBasicGenerate(t *testing.T) { one := int32(1) tests := []struct { name           string deploymentName string images         []string expected       *extensionsv1beta1.Deployment expectErr      bool }{ { name:           "deployment name and images ok", deploymentName: "images-name-ok", images:         []string{"nn/image1", "registry/nn/image2", "nn/image3:tag", "nn/image4@digest"}, expected: &extensionsv1beta1.Deployment{ ObjectMeta: metav1.ObjectMeta{ Name:   "images-name-ok", Labels: map[string]string{"app": "images-name-ok"}, }, Spec: extensionsv1beta1.DeploymentSpec{ Replicas: &one, Selector: &metav1.LabelSelector{ MatchLabels: map[string]string{"app": "images-name-ok"}, }, Template: v1.PodTemplateSpec{ ObjectMeta: metav1.ObjectMeta{ Labels: map[string]string{"app": "images-name-ok"}, }, Spec: v1.PodSpec{ Containers: []v1.Container{ {Name: "image1", Image: "nn/image1"}, {Name: "image2", Image: "registry/nn/image2"}, {Name: "image3", Image: "nn/image3:tag"}, {Name: "image4", Image: "nn/image4@digest"}, }, }, }, }, }, expectErr: false, }, { name:           "empty images", deploymentName: "images-empty", images:         []string{}, expectErr:      true, }, { name:           "no images", deploymentName: "images-missing", expectErr:      true, }, { name:      "no deployment name and images", expectErr: true, }, } for _, test := range tests { generator := &DeploymentBasicGeneratorV1{ BaseDeploymentGenerator{ Name:   test.deploymentName, Images: test.images, }, } obj, err := generator.StructuredGenerate() if !test.expectErr && err != nil { t.Errorf("unexpected error: %v", err) } if test.expectErr && err != nil { continue } if !reflect.DeepEqual(obj.(*extensionsv1beta1.Deployment), test.expected) { t.Errorf("test: %vnexpected:n%#vnsaw:n%#v", test.name, test.expected, obj.(*extensionsv1beta1.Deployment)) } } } </ins>

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind enhancement What happened: there is no UT for /sig testing
This issue should be closed because the corresponding PR has been merged already