jiebi/CodeConvo huggingface dataset:
Change:
b.Do().Visit(func(r *resource.Info) error { services := r.Object.(*api.ServiceList).Items for _, service := range services { <del> splittedLink := strings.Split(strings.Split(service.ObjectMeta.SelfLink, "?")[0], "/") // insert "proxy" into the link splittedLink = append(splittedLink, "") copy(splittedLink[4:], splittedLink[3:]) splittedLink[3] = "proxy" link := client.Host + strings.Join(splittedLink, "/") + "/" printService(out, service.ObjectMeta.Labels["name"], link, true) </del> <ins> link := client.Host + "/api/v1beta3/proxy/namespaces/" + service.ObjectMeta.Namespace + "/services/" + service.ObjectMeta.Name printService(out, service.ObjectMeta.Labels["name"], link) </ins> } return nil })

Discussion:
Right now at the end of I get We should update the output to point to the appropriate v1beta3 URL endpoints instead.
/cc
Ref and . cc
And as a minor nit, not all of those URLs need a trailing slash hack e.g. I don't think it is required for Elasticsearch. I think most recently worked on this code?
Thanks for fixing this
Change:
return err } <del> func (s *ServiceController) createLoadBalancer(service *v1.Service) (*v1.LoadBalancerStatus, error) { </del> <ins> func (s *ServiceController) ensureLoadBalancer(service *v1.Service) (*v1.LoadBalancerStatus, error) { </ins> nodes, err := s.nodeLister.ListWithPredicate(getNodeConditionPredicate()) if err != nil { return nil, err

Discussion:
According to code snippet The handles the ServiceUpdate events, it first check out whether or not current service need a LoadBalancer, and if not, it ensures corresponding LoadBalacner deleted. However, another branch of the statement is a little bit confusing. It says The load balancer doesn't exist yet, so create it_, and then it calls . I think at this time, we're not sure whether or not the load balancer already exists (since we didn't call ), so the proper behavior would be ensure load balancer exists (actually just calls indeed), so the comment (L-283) and the function name (L-285 ) isn't very appropriate, it's confusing right?
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
/sig network
/area cloudprovider
Please see
I just follow and I think these are two different issues because 1) focus on the potential logical error in code (should check existence before calling create..) which I don't agree. I think the code logic is fine. But, 2) This issue focus on the code/comment expression, which means the code logic is okay but the comment and function name is NOT appropriate.
The only comment I think should be changed is L283.
Yes, I mean L283 too, however, I think the function name s. should also be changed.
- it may be called , i agree that if you do not have prior knowledge of the servicecontroller it may be confusing. can you open a PR ?
Takes me a lot of time for the first PR preparation... Now I've opened the PR, please check it out.
Change:
To run serialization tests just for a previous version, like `v1.14.0`: ```sh <del> go test ./vendor/k8s.io/api -run //v1.14.0 </del> <ins> go test k8s.io/api -run //v1.14.0 </ins> ``` To run serialization tests for a particular group/version/kind, like `apps/v1` `Deployment`: ```sh <del> go test ./vendor/k8s.io/api -run /apps.v1.Deployment/ </del> <ins> go test k8s.io/api -run /apps.v1.Deployment/ </ins> ``` Failures to decode, to round-trip identical bytes, or to decode identical objects from json/yaml/protobuf,

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 --I tried rebasing an old open PR, and got merge conflicts on api testdata. I read and tried the command listed there for regenerating the test data. It failed as follows. I expected successful regeneration of the api test data. Checkout and issue the command exhibited above. Kubernetes version (use ): is at commit right nowCloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/cc
ah, latest go versions changed the invocation to
fixed in
/triage accepted
Change:
} defer conn.Close() <del> select { case <-conn.CloseChan(): close(idleSuccess) case <-time.After(150 * time.Millisecond): t.Fatalf("Timed out waiting for connection closure due to idle timeout") } </del> <ins> <-conn.CloseChan() </ins> } func TestServePortForward(t *testing.T) {

Discussion:
this is you
Hmm, I had upped waiting from 100ms to 500ms and that seemed to fix it. Do you have any better ideas?
Don't wait? :)
If the only reason you would timeout would be the code is broken, that's why the test runs have -timeout set.
Then the test fails immediately. It's waiting for the net.Listen calls to finish so it can connect to the specified local ports.
*finish enough so that socket connections work
So I can remove the timeout gating in my tests?
Yes ----- Original Message -----
Just failed again: https://travis-
Seems to be failing frequently now.
If this is test is failing again, my gut says it's not the same root cause. The original failure was a timeout issue. This new one is connection reset by peer. I've got the test running in a loop waiting for a failure but haven't seen one yet. is this still failing frequently?
No. It had failed twice in ~10 builds when I reopened this issue, but hasn't failed since. Reclosing. Will file a new issue if it recurs.
Change:
import ( "context" <ins> "fmt" </ins> v1 "k8s.io/api/core/v1" storagev1 "k8s.io/api/storage/v1" apierrors "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/apimachinery/pkg/labels" </ins> types "k8s.io/apimachinery/pkg/types" "k8s.io/apimachinery/pkg/util/uuid" <ins> "k8s.io/client-go/util/retry" </ins> "k8s.io/kubernetes/test/e2e/framework" "k8s.io/kubernetes/test/e2e/storage/utils" imageutils "k8s.io/kubernetes/test/utils/image" admissionapi "k8s.io/pod-security-admission/api" "github.com/onsi/ginkgo/v2" <ins> "github.com/onsi/gomega" </ins> ) var _ = utils.SIGDescribe("CSIInlineVolumes", func() {

Discussion:
[X] test approval issue : [X] test pr : 26 May 2023 [x] two weeks soak end date : 9 June 2023 [x] test promotion pr : [x] remove endpoint from [x] End of release 1.28 Release: Remove duplicate Conformance test the do not cover Patch, Replace, DeleteCollection. According to following APIsnoop query, there are still 3 CSIDriver endpoints that are not tested for Conformance. Using a number of existing e2e test practices a new has been created to address these 3 endpoints. The e2e logs for this test are listed below. This query shows the following csiDriver 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 3 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
Reopened this issue. <detailsIn response to : /reopen 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 For end of release 1.28 Release: Remove duplicate Conformance test the do not cover Patch, Replace, DeleteCollection.
Reopened this issue. <detailsIn response to : /reopen For end of release 1.28 Release: Remove duplicate Conformance test the do not cover Patch, Replace, DeleteCollection. 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:
} } <ins> func configFromEnvWithPasswd() (cfg Config, ok bool) { cfg, ok = configFromEnv() if !ok { return cfg, ok } cfg.Global.Password = os.Getenv("OS_PASSWORD") return cfg, ok } </ins> func TestNewOpenStack(t *testing.T) { <del> cfg, ok := configFromEnv() </del> <ins> cfg, ok := configFromEnvWithPasswd() </ins> if !ok { t.Skip("No config found in environment") }

Discussion:
This issue was reported in the Description When configuring components of infrastructure, environment variables allow a trivial method of gathering settings. However, not all settings should be derived from these variables. For example, the file used the CFSSLCAPKPASSWORD environment variable, where a plain-text password should be found within the variable. Figure 8.1: A string password being recovered from the CFSSLCAPKPASSWORD environment variable. If this variable is configured, an attacker could potentially gain access to its stored value through environment logging, or further exploitation of the endpoint. The assessment team found seemingly sensitive environment variables in at least the following locations: Exploit Scenario Alice configures her environment with the CFSSLCAPKPASSWORD environment variable. Eve gains access to Alice’s environment and determines that the CFSSLCAPK_PASSWORD environment variable is set. Because this variable contains the private key password, Eve is able to recover the private key and use it trivially, leading to further exploitation of Alice’s environment. Recommendation Short term, ensure highly sensitive information is not collected directly from environment variables for long periods of time. Long term, consider using Kubernetes secrets for all areas of the system. This will allow users to have one unified interface and location for all secrets, and avoid accidentally exposing secrets to other users within a host system. 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-005 and it was finding 9 of the report. The vendor considers this issue Medium Severity. To view the original finding, begin on page 35 of the Environment: Kubernetes version: 1.13.4
/sig auth /sig cloud-provider /area security /kind bug /remove-kind feature
Also secrets
Bug triage for 1.17 here with a gentle reminder that code freeze for this release is on November 14. Is this issue still intended for 1.17?
is it ok to close this issue also cc:
no, still remains
cc
seen this yet?
Thanks for the attention, we are using it as a fallback option mostly for test and dev env, we are working to remove them.
AFAIK is the only use for this testing. Would it be appropriate to move this code into ?
Submitted a PR to move password retrieval to
Change:
"time" "k8s.io/api/core/v1" <ins> "k8s.io/apimachinery/pkg/api/resource" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/util/sets"

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Today, the scheduler re-processes unschedulable nodes . Node updates are sent by Kubelet frequently (every 10 seconds) and often times they don't change any of the node properties that could potentially make them feasible. We should be smarter about these updates and move pods to the schedulable queue only when certain properties of nodes change that could make them feasible. These properties include node allocatable, node conditions, taints, labels, .... Why is this needed: Improves performance of the scheduler and avoids doing unnecessary attempts to schedule pods. This is particularly helpful when a cluster has a lot of unschedulable pods. <!-- DO NOT EDIT BELOW THIS LINE --/kind feature This is not a feature really. It is performance optimization, but in the absence of such a label, I need to use "feature" here. /sig scheduling
I can help to fix it. /assign mlmhl
The main reason for this problem is / update their status too frequently and most of these updates are heartbeats without any meaningful change. Recently sig-node introduces a new to alleviate this problem. With this mechanism, kubelet will split heartbeat and node status updates into two independent operations, and reduce the frequency of status updates to once per 1 minute(or more). In the long run this mechanism can indeed alleviate our problems, but at present it does not help us much as this is still an alpha feature and the node status updates frequency is still a bit high(per 1 minute right now).
Maybe we can try comparing old and new nodes after stripping their heartbeat info, like this:
I think that had sent earlier is more efficient. However, that PR does not filter out . In Wei's code, the heartbeat time is removed correctly. I think we should fix this issue and resubmit that PR.
could you resubmit a PR to: disregard in conditions comparison: and (optionally) disregard timestamp in taints comparison:
Thanks for all your advice, a new PR is submitted: This PR does not include your second suggestion(disregard timestamp in taints comparison) as I'm not sure if can be changed when node updating.

If it can be changed, I will add this filter later, otherwise I think we can keep the current implementation to make the compare operation simpler and faster. What's more, just as I said in the PR's description, I'm not sure how much side effects this change has on scheduler's resource consumption, as it always copy node's conditions before comparison.
I am thinking whether we could move this logic(whether node became more schedulable) to kubelet, kubelet reports it through heartbeats.
Change:
if err := testutil.GatherAndCompare(legacyregistry.DefaultGatherer, strings.NewReader(test.wantMetrics), "apiserver_encryption_config_controller_automatic_reload_success_total", "apiserver_encryption_config_controller_automatic_reload_failures_total", <ins> "apiserver_encryption_config_controller_automatic_reloads_total", </ins> ); err != nil { t.Errorf("failed to validate metrics: %v", err) }

Discussion:
Change encryption config controller reload metrics to be consistent with other places (Authn, Authz) xref: Combine and into a single metric with with an enum value of and . /sig auth /triage accepted
cc
We probably should keep the existing metrics for some time to allow folks to migrate to the new one.
Ah I was thinking about this as well! Looking at "may be deleted at any time", I was leaning towards just removing it. If the common approach is to keep it for a release before removing, we could do that. I believe we can set a for the 2 metrics we want to remove.
I don't have a good sense of metrics stability because they tend to stay alpha forever and folks don't go back to update them. Since the associated feature set is GA, I think we should be conservative with the changes we make. Perhaps SIG instrumentation folks can provide some guidance here?
As part of the PR, I was going to ask when is the right time to graduate these metrics do you have thoughts on to take while deleting an alpha metric metrics should be graduated from alpha to beta and stable?
Change:
fail. release: v1.14 file: test/e2e/common/configmap.go <ins> - testname: ConfigMap lifecycle codename: '[sig-node] ConfigMap should run through a ConfigMap lifecycle [Conformance]' description: Attempt to create a ConfigMap. Patch the created ConfigMap. Fetching the ConfigMap MUST reflect changes. By fetching all the ConfigMaps via a Label selector it MUST find the ConfigMap by it's static label and updated value. The ConfigMap must be deleted by Collection. release: v1.19 file: test/e2e/common/configmap.go </ins> - testname: DownwardAPI, environment for CPU and memory limits and requests codename: '[sig-node] Downward API should provide container''s limits.cpu/memory and requests.cpu/memory as env vars [NodeConformance] [Conformance]'

Discussion:
[x] Original approval issue: [x] Two weeks soak end date: 8 May 2020 [x] Two weeks soak end date: 23 June 2020 This issue is created to allow edit by /wip /hold This issue proposes the writing of a new test for the API endpoints , with the intention of promoting it to Conformance. This issue contains a very basic mock test in order to start the conversation about what a good e2e test would look like for this endpoint. The code below is verified to be hitting the intended endpoint, show as per the queries in APIsnoop's live view of the cluster's audit logs. According to this APIsnoop query, there are still some remaining ConfigMap endpoints which are untested. a ConfigMap with a static label the ConfigMap with a new Label and updated data the ConfigMap to ensure it's patched all ConfigMaps in all Namespaces find the ConfigMap(1) ensure that the ConfigMap is found and is patched Namespaced ConfigMap(1) via a Collection with a LabelSelector This mock test uses client-go's standard functions for talking to the Event area of the API. Discover useragents: Display endpoints hit by the test: Show the change in coverage after the mock test: If a test with these calls gets merged, Conformance coverage will go up by 2 points
/sig testing /sig architecture /area conformance
/assign Issue created to replace
GitHub didn't allow me to assign the following users: raymonddeng99. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/reopen On hold & soaking
Reopened this issue. <detailsIn response to : /reopen On hold & soaking 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:
FailedCreatePodSandBox               = "FailedCreatePodSandBox" FailedStatusPodSandBox               = "FailedPodSandBoxStatus" FailedMountOnFilesystemMismatch      = "FailedMountOnFilesystemMismatch" <ins> FailedPrepareDynamicResources        = "FailedPrepareDynamicResources" </ins> ) // Image manager event reason list

Discussion:
When API fails there is no way to understand what happens because error is not reported. Error should be either logged or, better event should be recorded, so user would see it in the output. this patch to the kubernetes sources: a pod: the pod details: is not mentioning why pod is in pending state. No response <details</details<detailslocal </details<details</details<details</details<details</details<details</details
/sig node
/assign /cc
Logging is not enough, users don't have access to kubelet logs. Let's generate an event. I don't know whether we should have a well-defined condition for this. Thoughts anyone?
+1 on a condition.
From
In I am proposing as new pod condition.
/triage accepted /priority important-soon Is it a bug or a feature? Will it be tracked as a part of the enhancement work? If so we can close this one
/cc
/cc
Can you explain why do you prefer a condition over an event?
Depends on expectations :sweatsmile: The : . I expected this to be done already as part of the initial implementation, which would make this a bug. But one can also argue that this particular part had been deferred until later, which makes this a feature. We are using separate issues to track individual aspects of the enhancement work, so let's keep this open. Let's focus on adding the event in this issue and discuss the condition in
Change:
i.Images[test.originalImage.name].Username = test.originalImage.username i.Images[test.originalImage.name].Uid = test.originalImage.uid <del> uid, username, error := m.getImageUser(test.originalImage.name) assert.NoError(t, error, "TestCase[%d]", j) </del> <ins> uid, username, err := m.getImageUser(test.originalImage.name) assert.NoError(t, err, "TestCase[%d]", j) </ins> if test.expectedImageUserValues.uid == (*int64)(nil) { assert.Equal(t, test.expectedImageUserValues.uid, uid, "TestCase[%d]", j)

Discussion:
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
Change:
UnavailableReplicas: 1, }, <del> msg:  "Waiting for rollout to finish: 1 of 2 updated replicas are available...n", </del> <ins> msg:  "Waiting for deployment "foo" rollout to finish: 1 of 2 updated replicas are available...n", </ins> done: false, }, {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: In our CI, we run multiple times in parallel when we update multiple deployments. This lets us see the status of all deployments as they run. When a deployment succeeds, the final message tells us the name of the deployment. However, the intermediate "Waiting for rollout to finish" messages do not say the name of the deployment. This means that in order to look at multiple rollouts in parallel, we need to manually pipe through another command to prefix it with the rollout name. What you expected to happen: Each line to mention the rollout name. How to reproduce it (as minimally and precisely as possible): Update any deployment, run , note that intermediate status names don't contain the deployment name. Anything else we need to know?: Arguably another fix would be to allow you to pass multiple rollouts to and have kubectl handle polling multiple deployments in parallel. Environment: This is still true on master by code inspection.
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