jiebi/CodeConvo huggingface dataset:
Change:
echo "minion-$((${BASH_REMATCH[1]} - 1))" } <del> # Find the vagrant machien name based on the host name of the minion </del> <ins> # Find the vagrant machine name based on the host name of the minion </ins> function find-vagrant-name-by-minion-name { local ip="$1" if [[ "$ip" == "${INSTANCE_PREFIX}-master" ]]; then

Discussion:
This is an umbrella issue to track changes in the . It is required to update the guide based on the suggestion we've received so far after officially migrating , , and (ongoing migration). The guide can be improved by adding more relevant details about structured logging migration, examples, common mistakes, and easy navigation in the guide using appropriate referencing. We've observed common mistakes made by contributors while doing the migration. To avoid those "common mistakes", more examples are needed in the structured logging migration guide: approach could be manually looking at various review comments that we've received so far while performing migration of , , and and figure out common mistakes done by contributors. Add examples to avoid those mistakes, and enhance the guidelines present in addition to this, people involved in the previous migration process, either as approver/reviewer or as contributors, can suggest changes in this umbrella issue or open a pull request towards the necessary changes referencing this issue. As we advance, we need to make the migration guide suitable for both "contributors" and "users" of Kubernetes. Since slowly we are progressing and covering more components of Kubernetes, it is required to improve the guide so that both contributors and Kubernetes users can effectively use it.
Suggestions in form of review comments from previous migrations are here:
/sig instrumentation /wg structured-logging /area logging /priority important-longterm /kind documentation /cc
Do you intend to update the documentation yourself, or are you looking for others to help here?
Yes, 1) I'm looking for contributors and reviewers to suggest more changes (I may not be able to cover all the required changes) and I'll add those changes in the table above. 2) Contributors can submit PRs for these changes in the migration guide, I can definitely submit PRs if we see that the issue is not progressing enough
Thanks. I'm going to assign this to you for now then. /assign shivanshu1333
/assign
/triage accepted
/sig docs
/assign
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
Change:
return len(s) } <del> func less[T ordered](lhs, rhs T) bool { </del> <ins> func less[T cmp.Ordered](lhs, rhs T) bool { </ins> return lhs < rhs }

Discussion:
Package use a custom-defined type . Go 1.21 support an official package cmp which has .
/sig api-machinery
cc
/assign xgp01
/triage accepted
/kind cleanup
Change:
- [Deprecation of PodSecurityPolicy](#deprecation-of-podsecuritypolicy) - [Kubernetes API Reference Documentation](#kubernetes-api-reference-documentation) - [Kustomize Updates in Kubectl](#kustomize-updates-in-kubectl) <del> - [Default Container Labels](#default-container-labels) </del> <ins> - [Default Container Annotation](#default-container-annotation) </ins> - [Immutable Secrets and ConfigMaps](#immutable-secrets-and-configmaps) - [Structured Logging in Kubelet](#structured-logging-in-kubelet) - [Storage Capacity Tracking](#storage-capacity-tracking)

Discussion:
is wrong as it says default label can be specified, but KEP and other lines of changelog mentions annotation. Changelog is correct and consistent about default container feature for kubectl. I'm still not able to get this feature to work actually for . Kubernetes version (use ): v1.21.0
/triage accepted thanks for reporting early!
/remove-kind bug /kind documentation
/sig release
Change:
// This call is idempotent, and must not return an error if the sandbox has // already been removed. RemovePodSandbox(context.Context, *RemovePodSandboxRequest) (*RemovePodSandboxResponse, error) <del> // PodSandboxStatus returns the status of the PodSandbox. </del> <ins> // PodSandboxStatus returns the status of the PodSandbox. If the PodSandbox is not // present, returns an error. </ins> PodSandboxStatus(context.Context, *PodSandboxStatusRequest) (*PodSandboxStatusResponse, error) // ListPodSandbox returns a list of PodSandboxes. ListPodSandbox(context.Context, *ListPodSandboxRequest) (*ListPodSandboxResponse, error)

Discussion:
The behavior when requested id doesn't exist is not defined clearly in CRI. Currently, we define that should return when requested image doesn't exist (), and kubelet is relying on this behavior now (). However, we haven't clearly defined the behavior of and . Currently, they return error when requested sandbox/container doesn't exist, and kubelet is also relying on this behavior. Not super urgent, just track the issue here. /cc
/assign
Added for clarifying the behavior.
Change:
// define volume limit to be 2 for this test var err error <del> init(testParameters{attachable: true, nodeSelectorKey: "node-attach-limit-csi", attachLimit: 2}) </del> <ins> init(testParameters{nodeSelectorKey: "node-attach-limit-csi", attachLimit: 2}) </ins> defer cleanup() nodeName := m.config.ClientNodeName attachKey := v1.ResourceName(volumeutil.GetCSIAttachLimitKey(m.provisioner))

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: in Which test(s) are failing: Since when has it been failing: 2019-02-27 () -- since it was Testgrid link: Reason for failure: Timeout: Anything else we need to know: /kind failing-test /sig storage /priority important-soon /milestone v1.14 cc
cc Could you help with this please?
/assign
Neither of the failing tests mentioned in this issue are present in testgrid anymore. is all clear
Change:
// Wait for some endpoints. count := 0 for t := time.Now(); time.Since(t) < 5*time.Minute; time.Sleep(10 * time.Second) { <del> endpoints, err = c.Endpoints(api.NamespaceSystem).Get("elasticsearch-logging") </del> <ins> endpoints, err = c.Endpoints(namespace).Get("elasticsearch-logging") </ins> if err != nil { continue }

Discussion:
Now elasticsearchloggingdiscovery will only look for the endpoints in kube-system namespace due to hard-coded api.NamespaceSystem value. Maybe let user to decide in which namespace elasticsearchloggingdiscovery binary will look for endpoints ?
Change:
// calling again, or risk having new info getting clobbered by delayed // old info. func (p *PodCache) UpdateAllContainers() { <ins> // TODO: this is silly, we should pro-actively update the pod status when // the API server makes changes. p.clearNodeStatus() </ins> ctx := api.NewContext() pods, err := p.pods.ListPods(ctx, labels.Everything()) if err != nil {

Discussion:
I have 3 identical nodes, 1 replication controller with 2 replicas of a pod. I simulate failure of one of the nodes to where pods have been scheduled by simply unplugging the node. Kubernetes realizes that the node has failed, but the pod gets not re-scheduled to the another available node. The documentation at says the following: and So is that a mistake in the documentation or a missing or a bug? I use v0.10.
That's definitely a bug, and something that used to work correctly. I will investigate today, and follow up on this bug. Thanks for the report. Brendan On Feb 5, 2015 8:11 AM, "peter-braun" wrote:
Actually, it's really a missing feature -- . I believe the last of the mechanisms we needed were ~last week. said he would start on it.
Is there a rudimentary solution that we could get in quickly, and then improve next week?
Just sent a simple PR with the fix.
Note that this issue is about a replication-controller set of pods. This isn't which is a broader "fix pods on failed nodes in general" issue.
Ah, a cache bug. Will take a look.
Re-opening this, because I reverted the relevant code in the replication controller with
I'll comment on the other thread later. Sorry I was out yesterday. I'm a bit free this weekend and should be able to work on the problem for at least one day.
Fixed by . Re-open if not fixed.
was merged a few days ago. It referenced , but not this issue.
Change:
// Rather than serialize the patched map to JSON, then decode it to an object, we go directly from a map to an object if err := runtime.DefaultUnstructuredConverter.FromUnstructured(patchedObjMap, objToUpdate); err != nil { <del> return err </del> <ins> return errors.NewInvalid(schema.GroupKind{}, "", field.ErrorList{ field.Invalid(field.NewPath("patch"), fmt.Sprintf("%+v", patchMap), err.Error()), }) </ins> } // Decoding from JSON to a versioned object would apply defaults, so we do the same here defaulter.Default(objToUpdate)

Discussion:
/kind bug /sig api-machinery /cc What happened: patching (SMP) any object's annotation using invalid patch content will result in an (500) internal-server error. expecting a (400) bad-request error in this case. patch body: received error: the error is thrown from converter instead of the patcher, so it seems that patcher considers the body as valid then the converter complained. Anything else we need to know?: when my grandpa was 65 years old he started running one mile a day to keep fit. he's 70 now and we have no idea where he is.
I just tried the same patch with "MergePatchType", and it also fails with 500.
I can't make it fail with JSONPatchType, I get a 422
I suspect the error should read "the server rejected your request due to an error in our request"
Change:
// internalError renders a simple internal error func internalError(w http.ResponseWriter, req *http.Request, err error) { <ins> w.Header().Set("Content-Type", "text/plain") w.Header().Set("X-Content-Type-Options", "nosniff") </ins> w.WriteHeader(http.StatusInternalServerError) fmt.Fprintf(w, "Internal Server Error: %#v", req.RequestURI) runtime.HandleError(err)

Discussion:
The error reporting functions here all repeat a URI without sanitizing it. An XSS attacker could use this to get the server to embed a reference to a malicious script. (As always, please note that kubernetes apiserver is NOT xss hardened and we do NOT recommend using the api directly from a browser.)
The error correctly sets the content type to , so this is only an issue using a browser that does content sniffing. Would it be sufficient to just add the header here?
Yes, that will work for browsers that honor the header. It's probably sufficient-- we could do that globally, we set Content-Type correctly everywhere, I think.
Change:
}, }, api.PodPending, <del> "mixed state #2", </del> <ins> "mixed state #2 with restart onfailure", </ins> }, } for _, test := range tests {

Discussion:
I'm actually not sure if it's by design. But certainly replication controller doesn't behave like it expects this.
If restart policy is to restart always, they should be restarted, but in that case they shouldn't be reported as failed.
This is a known issue, and by design based on upper-level will observe the status reported from kubelet, but not check with RestartPolicy and generate PodCondition / PodStatus. When RestartPolicy is Always, even Kubelet reports all containers are at failed state, apiserver shouldn't mark Pod as failed state. This is why initially I want kubelet report Pod state / status / condiction.
As a quick fix, we could let apiserver populate the right state / status based on containerStatus and RestartPolicy for now. In a long term, I still think we should make kubelet smarter and atomic and self-contained component, not just a wrapper around docker.
Short term fix should be P1 then we can de-prio for a "realer" fix.
Yes, I am working on the short term fix, and should have it included in 0.6 cut.
are you still working on this?
Yes, I am working on this. Should finish it today.
Change:
clientConfig: &testClientConfig{namespace: "test", namespaceSpecified: true}, icc:          &testICC{}, <del> result: "test", ok:     true, </del> <ins> result:     "test", overridden: true, </ins> }, "in-cluster checked when namespace is not specified, but is defaulted": {

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!--What happened: In-cluster namespace isn't overridden by kubeconfig if the context is specified via kubectl flag. When using , the override works as expected. What you expected to happen: If I specify for a context in kubeconfig, then I expect to use as the default namespace, regardless of whatever's in . How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: supposedly fixed this issue, but not for the case where the context is specified via a command line flag (). This is because this line checks for . Environment: Kubernetes version (use ): v1.10.5 (details above) Cloud provider or hardware configuration: - OS (e.g. from /etc/os-release): - Kernel (e.g. ): - Install tools: - Others: - <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
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
fixed in
Change:
// or transport level security defined by the provided Config. Will return the // default http.DefaultTransport if no special case behavior is needed. func TransportFor(config *Config) (http.RoundTripper, error) { <del> cfg, err := config.transportConfig() </del> <ins> cfg, err := config.TransportConfig() </ins> if err != nil { return nil, err }

Discussion:
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite} Previous issues for this test:
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
We understand the problem here - I'm working on the fix.
https://k8s- Failed: [] Load capacity [Feature:Performance] should be able to handle 30 pods per node {Kubernetes e2e suite}
Change:
}, { cfg: &kubeadmapi.MasterConfiguration{ <del> Networking:        kubeadmapi.Networking{PodSubnet: "2001:101:115::/48"}, </del> <ins> Networking:        kubeadmapi.Networking{PodSubnet: "2001:db8::/64"}, </ins> CertificatesDir:   testCertsDir, KubernetesVersion: "v1.7.0", },

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 bug What happened: For IPv6, the node CIDR size is hard coded to /64. This causes an error bringing up the kube-controller, as the size must be for a smaller subnet (larger value) that what is used for the pod subnet, which is specified for some CNI plugins (e.g. Calico). In addition, this is a catch-22, as the pod subnet prefix cannot be for a larger network (smaller value) than /66, so we cannot set it to /63, for example. What you expected to happen: The node CIDR size should be computed, based on the pod subnet specified, so that it can meet the requirements. How to reproduce it (as minimally and precisely as possible): Bring up a cluster using KubeAdm, specifying IPv6 and choose any pod subnet prefix desired. Anything else we need to know?: Note, there is a second requirement, that the difference between pod subnet size and node CIDR size be 16 or less (issue ). I'll be submitting a proposed PR to address this. Environment: Kubernetes version (use ): latest on master, using 1.9.2 in my case Cloud provider or hardware configuration: bare metal, single node OS (e.g. from /etc/os-release): Ubuntu 16.04 Kernel (e.g. ): Linux bxb-c2-77 4.4.0-109-generic -Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x8664 x8664 x86_64 GNU/Linux Install tools: kubeadm Others: /area ipv6 /sig network
/assign pmichali
Change:
"VolumeBinding":               ValidateVolumeBindingArgs, } <del> seenPluginConfig := make(sets.String) for i := range profile.PluginConfig { pluginConfigPath := path.Child("pluginConfig").Index(i) name := profile.PluginConfig[i].Name args := profile.PluginConfig[i].Args if seenPluginConfig.Has(name) { errs = append(errs, field.Duplicate(pluginConfigPath, name)) } else { seenPluginConfig.Insert(name) } if validateFunc, ok := m[name]; ok { // type mismatch, no need to validate the `args`. if reflect.TypeOf(args) != reflect.ValueOf(validateFunc).Type().In(1) { errs = append(errs, field.Invalid(pluginConfigPath.Child("args"), args, "has to match plugin args")) return errs } in := []reflect.Value{reflect.ValueOf(pluginConfigPath.Child("args")), reflect.ValueOf(args)} res := reflect.ValueOf(validateFunc).Call(in) // It's possible that validation function return a Aggregate, just append here and it will be flattened at the end of CC validation. if res[0].Interface() != nil { errs = append(errs, res[0].Interface().(error)) } } } </del> if profile.Plugins != nil { stagesToPluginSet := map[string]config.PluginSet{ "queueSort":  profile.Plugins.QueueSort,

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 --Have a legacy scheduler config, upgrade to v1beta2 since we are at v1beta2 now, scheduler failed to start with some unreadable raw data, accurate and readable error message. config scheduler config like what has been said above. Kubernetes version (use ): latest. Cloud provider or hardware configuration: OS (e.g: ): all Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /sig scheduling /assign
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
Change:
return buffer.String() } <del> // NewIPerf parses an IPerf CSV output line into an IPerfResult. func NewIPerf(csvLine string) *IPerfResult { </del> <ins> // NewIPerf parses an IPerf CSV output line into an IPerfCSVResult. func NewIPerf(csvLine string) (*IPerfCSVResult, error) { if len(csvLine) == 0 { return nil, errors.New("No iperf output received in csv line") } </ins> csvLine = strings.Trim(csvLine, "n") slice := StrSlice(strings.Split(csvLine, ",")) if len(slice) != 9 { <del> framework.Failf("Incorrect fields in the output: %v (%v out of 9)", slice, len(slice)) </del> <ins> return nil, errors.Errorf("Incorrect fields in the output: %v (%v out of 9)", slice, len(slice)) </ins> } <del> i := IPerfResult{} </del> <ins> i := IPerfCSVResult{} </ins> i.date = slice.get(0) i.cli = slice.get(1) i.cliPort = intOrFail("client port", slice.get(2))

Discussion:
What happened: The iperf tests were written a while ago but i think havent been updated. They measure bandwidth over multiple pods, but they probably should also have a test which reports individual pod's bandwidth between one pod over a SEP. They should pretty print a table so its easy to see exactly what is going on with the bandwidth They should use iperf3 (need to check that) Maybe we should have permutations for udp and tcp? The current output is something like: What you expected to happen: That running the tests would result in a table such as those that you can get from iperf3, i.e. How to reproduce it: run the e2es on any cluster, Environment: Kubernetes version (use ): master, any version
/sig network
/assign
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
I've taken a first pass at this , working on resolving a couple issues then we can circle back to determine how else it could be improved!
Cool c/p the new test output so we can compare when u get a chance
ah yess. much better then what we have now.
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
Change:
f.run(getKey(d, t)) } <del> func TestSyncDeploymentClearsOverlapAnnotation(t *testing.T) { f := newFixture(t) d := newDeployment("foo", 1, nil, nil, nil, map[string]string{"foo": "bar"}) d.Annotations[util.OverlapAnnotation] = "overlap" f.dLister = append(f.dLister, d) f.objects = append(f.objects, d) rs := newReplicaSet(d, "deploymentrs-4186632231", 1) f.expectUpdateDeploymentStatusAction(d) f.expectCreateRSAction(rs) f.expectUpdateDeploymentStatusAction(d) f.expectUpdateDeploymentStatusAction(d) f.run(getKey(d, t)) d, err := f.client.ExtensionsV1beta1().Deployments(d.Namespace).Get(d.Name, metav1.GetOptions{}) if err != nil { t.Fatalf("can't get deployment: %v", err) } if _, ok := d.Annotations[util.OverlapAnnotation]; ok { t.Errorf("OverlapAnnotation = %q, wanted absent", d.Annotations[util.OverlapAnnotation]) } } </del> func TestSyncDeploymentDontDoAnythingDuringDeletion(t *testing.T) { f := newFixture(t)

Discussion:
The Deployment overlap annotation () is no longer populated nor used by 1.6+ on the server side. However, in we maintained knowledge of the annotation for 1.6 clients in case they talk to pre-1.6 servers. That PR also adds code to clean up the annotation whenever it's found in 1.6+ clusters, so that pre-1.6 clients don't see it and make the wrong assumptions. The code handling this annotation should be removed when all the following conditions are met: We no longer support a 1.5.x client talking to the latest server version. We no longer support upgrading the server directly from 1.5.x to the latest version. The soonest milestone that meets both conditions according to the is v1.8. This issue should be moved to that milestone once it exists.
TODOs: [x] deployment controller: [x] deployment util: [x] deployment reaper: [x] deployment describer:
I can help on this
/assign
GitHub didn't allow me to assign the following users: wanghaoran1988. Note that only can be assigned. <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
thanks, feel free to send patches