jiebi/CodeConvo huggingface dataset:
Change:
// The context and/or DRAPlugin.Stop can be used to stop all background activity. // Stop also blocks. A logger can be stored in the context to add values or // a name to all log entries. <ins> // // If the plugin will be used to publish resources, [KubeClient] and [NodeName] // options are mandatory. </ins> func Start(ctx context.Context, nodeServer interface{}, opts ...Option) (result DRAPlugin, finalErr error) { logger := klog.FromContext(ctx) o := options{

Discussion:
When calling draplugin.Start without supplying kubeclient no error is reported, while the kubeclient is vital for further announcement of resourceSlice. An error needs to be returned when nodeName or kubeclient parameters are not set. Do not supply kubeclient parameter when creating draplugin, for isntance here: No response master <details</details<details</details<details</details<details</details<details</details
/sig node /triage accepted /project 95
Change:
} // MergeSpecsV3 merges OpenAPI v3 specs for CRDs <del> // For V3, the static spec is never merged with the individual CRD specs so no conflict resolution is necessary </del> <ins> // Conflicts belonging to the meta.v1 or autoscaling.v1 group versions are skipped as all CRDs reference those types // Other conflicts will result in an error </ins> func MergeSpecsV3(crdSpecs ...*spec3.OpenAPI) (*spec3.OpenAPI, error) { <del> // create shallow copy of staticSpec, but replace paths and definitions because we modify them. </del> crdSpec := &spec3.OpenAPI{} if len(crdSpecs) > 0 { crdSpec.Version = crdSpecs[0].Version crdSpec.Info = crdSpecs[0].Info } for _, s := range crdSpecs { <del> // merge specs without checking conflicts, since the naming controller prevents // conflicts between user-defined CRDs mergeSpecV3(crdSpec, s) </del> <ins> err := mergeSpecV3(crdSpec, s) if err != nil { return nil, err } </ins> } return crdSpec, nil } // mergeSpecV3 copies paths and definitions from source to dest, mutating dest, but not source. <del> // We assume that conflicts do not matter. func mergeSpecV3(dest, source *spec3.OpenAPI) { </del> <ins> // Conflicts belonging to the meta.v1 or autoscaling.v1 group versions are skipped as all CRDs reference those types // Other conflicts will result in an error func mergeSpecV3(dest, source *spec3.OpenAPI) error { </ins> if source == nil || source.Paths == nil { <del> return </del> <ins> return nil </ins> } if dest.Paths == nil { dest.Paths = &spec3.Paths{}

Discussion:
Related to Seeing the following errors in kube-apiserver logs when CRDs are applied: No errors in logs Apply any CRD manifest No response <details</details<details</details<details</details<detailsRancher RKE2 </details<detailscontainerd 1.6.4 </details<detailscanal </details
/sig api-machinery
/assign
Did this cause any specific trouble to your cluster I'm curious what the impact/severity of this is.
Everything seems to work fine, but there's a bunch of log spew every time a CRD manifest is loaded. In K3s we mix all the control-plane component logs together in a single pair of stdout/stderr streams so it's quite noisy, compared to previous releases. The fact that these come out at WARN level with a scary prefix makes them look pretty serious, and I expect we will get a fair bit of users asking about it once we release.
/triage accepted
Change:
FilteredNodesStatuses: filteredNodesStatuses, } } <del> trace.Step("Computing predicates done") </del> <ins> trace.Step("Running postfilter plugins done") </ins> metrics.SchedulingAlgorithmPredicateEvaluationDuration.Observe(metrics.SinceInSeconds(startPredicateEvalTime)) metrics.DeprecatedSchedulingAlgorithmPredicateEvaluationDuration.Observe(metrics.SinceInMicroseconds(startPredicateEvalTime)) metrics.SchedulingLatency.WithLabelValues(metrics.PredicateEvaluation).Observe(metrics.SinceInSeconds(startPredicateEvalTime))

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We have enabled in genericscheduler. However, the steps being traced seem outdated. In particular, the "snapshot" is expensive and should be traced. Other steps can be traced as well wherever appropriate, e.g., PreFilter. Why is this needed: Improve granularity of tracing. /sig scheduling
/assign
Change:
} } <del> func (o *EditOptions) visitToPatch( originalInfos []*resource.Info, patchVisitor resource.Visitor, results *editResults, ) error { </del> <ins> func (o *EditOptions) visitToPatch(originalInfos []*resource.Info, patchVisitor resource.Visitor, results *editResults) error { </ins> err := patchVisitor.Visit(func(info *resource.Info, incomingErr error) error { editObjUID, err := meta.NewAccessor().UID(info.Object) if err != nil {

Discussion:
Try running and adding an ingress object, or an empty list, then exit the editor – it will panic like this: I've also tried , and for the sake of experiment tried adding a Pod, then it failed rather gracefully with this message: But when I tried to add a DaemonSet, it paniced. I am not sure how we should fix, perhaps editing of lists isn't something a normal user is expected to do... Let's discuss.
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 cli
So I wanted to test how it would behave if I take an item out of my list, so I've create and ingress object and tried . To my surprise I've found only one ingress object without a list. When I a second object, gave me a list to edit. So I must say that flattening of the list in case there is only one object was a bit surprising. Now that I have a list of two items, I've decided to try deleting one by removing it from the list, and it turns that's not possible.
It feels like the problem is complicated, and I'd rather see disallowed unless users passed a name of a specific resource. If we belive some folks rely on to work when there is only one resource to edit, maybe we can keep that... If we cannot disallow this, I'd rather see it fixed in a way where removing items results in deletion and editing a single item list is actually about editing a list. At the very least, of course, we should fix the panic, but I still want to hear what people think about this before I open a PR (presumably fixing that panic should be trivial).
I'm working on this. Already submitted a PR in . PTAL.
I think at the very beginning, at least v1.5.0 the logic is already like this, I'm not sure why this bothering you I use this lot of time, I'd prefer keep it.

also cc
I don't think edit should open with an empty list. should open a list if there are multiple items, a single item if there is only one, and error if there are none of that type. should open a single item if it is found, and error if it is not found
that sounds good to me. I was just a bit surprised, that's all.
Change:
}, expected: "rule foo.com=othersvc:8080 is invalid and should be in format host/path=svcname:svcport[,tls[=secret]]", }, <ins> "valid catch all rule": { rules: []string{ "/path/subpath*=svc:redis,tls=blo", }, expected: "", }, </ins> } for name, tc := range tests {

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: kubectl create ingress panics because there is no cmdutil.AddDryRunFlag What you expected to happen: Command to work How to reproduce it (as minimally and precisely as possible): Compile the upstream, run ` Anything else we need to know?: Environment: Kubernetes version (use ): upstream/dev /sig cli /kind bug /priority critical-urgent
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:
<ins> #!/bin/bash # Copyright 2014 Google Inc. All rights reserved. # # 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. # Launches an nginx container and verifies it can be reached. Assumes that # we're being called by hack/e2e-test.sh (we use some env vars it sets up). # Exit on error set -e source "${KUBE_REPO_ROOT}/cluster/kube-env.sh" source "${KUBE_REPO_ROOT}/cluster/$KUBERNETES_PROVIDER/util.sh" function validate() { POD_ID_LIST=$($CLOUDCFG '-template={{range.Items}}{{.ID}} {{end}}' -l name=$controller list pods) # Container turn up on a clean cluster can take a while for the docker image pull. ALL_RUNNING=0 while [ $ALL_RUNNING -ne 1 ]; do echo "Waiting for all containers in pod to come up." sleep 5 ALL_RUNNING=1 for id in $POD_ID_LIST; do CURRENT_STATUS=$($CLOUDCFG -template '{{and .CurrentState.Info.datacontroller.State.Running .CurrentState.Info.net.State.Running}}' get pods/$id) if [ "$CURRENT_STATUS" != "true" ]; then ALL_RUNNING=0 fi done done ids=($POD_ID_LIST) if [ ${#ids[@]} -ne $1 ]; then echo "Unexpected number of pods: ${#ids[@]}" exit 1 fi } controller=dataController # Launch a container $CLOUDCFG -p 8080:80 run brendanburns/data 2 $controller function teardown() { echo "Cleaning up test artifacts" $CLOUDCFG stop $controller $CLOUDCFG rm $controller } trap "teardown" EXIT validate 2 $CLOUDCFG resize $controller 1 validate 1 $CLOUDCFG resize $controller 2 validate 2 # TODO: test rolling update here, but to do so, we need to make the update blocking # $CLOUDCFG -u=20s rollingupdate $controller # # Wait for the replica controller to recreate # sleep 10 # # validate 2 exit 0 </ins>

Discussion:
We have an e2e test that runs the guestbook example. We should also have one that runs through the other example.
Change:
// being upgraded, then the container runtime must also support the initially // selected version or the redial is expected to fail, which requires a restart // of kubelet. <del> func (r *remoteRuntimeService) determineAPIVersion(conn *grpc.ClientConn) error { </del> <ins> func (r *remoteRuntimeService) determineAPIVersion(conn *grpc.ClientConn, endpoint string) error { </ins> ctx, cancel := getContextWithTimeout(r.timeout) defer cancel()

Discussion:
When installing the latest component, got the error: Then the flag , got error: It is confusing to see these error msgs at the first glance, need to make it more clearly. Add the required field validation, and add more supportive error message. Download the latest v1.25.0 binary, and install it with systemd service or just manually start the binary, will reproduce these errors. <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 node
kubelet 1.24+ is not working with the docker, unless using Are you using it? If not, try switching to other available container runtimes. Please re-open if you have further questions /close
Closing this issue. <detailsIn response to : kubelet 1.24+ is not working with the docker, unless using Are you using it? If not, try switching to other available container runtimes. Please re-open if you have further questions 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, I got to know the , so need to add runtime validation by the fix PR: PTAL thanks.
Change:
podCount            = 100 podCreationInterval = 100 * time.Millisecond recoverTimeout      = 5 * time.Minute <del> startTimeout        = 3 * time.Minute </del> <ins> startTimeout        = 5 * time.Minute </ins> // restartCount is chosen so even with minPods we exhaust the default // allocation of a /24. minPods      = 50

Discussion:
node-kubelet-serial Kubelet should correctly account for terminated pods after restart Since test was created, flakes 10-20% of the time. Not entirely clear why, I haven't looked. No response /assign /sig node
Introduced by , maybe we should use to replace See the log below, a pod becomes Succeed may exhaust tens of seconds
/triage accepted
Yeah I only tested this locally and not in CI, it seems that in CI the pods take much longer. Timings just need to be tweaked.
/reopen still a number of flakes since the attached PR merged, I don't think that fixed it.
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
from this link, I see all suites passed, which flakes do you mean?
I see this failure in
so this problem should have been fixed by
From gubernator: In all cases, it's timing out. I'll try upping the startTimeout.
/reopen still flaking
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
Luckily the kubelet log is clear as to what's going on. From (flake ) The test should work fine if we drop the CPU request a bit, let me tweak it to make up for the possible extra 100m scheduled. I'm not sure what's causing that (aren't these tests serial? what the heck is getting scheduled) but we should be resilient to it. Also, needs to be fixed. This test will no longer detect the regression it was designed to show after that change. I will revert it and also fix the resource requirements and that should fix this test.
/milestone v1.23 need to fix this before test freeze
Change:
EtcdUpgradeVersion       string UpgradeImage             string GCEUpgradeScript         string <del> PrometheusPushGateway    string </del> ContainerRuntime         string ContainerRuntimeEndpoint string ImageServiceEndpoint     string

Discussion:
TLDR: removed a feature but left documentation and the flag intact. Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"6", GitVersion:"v1.6.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-03-28T16:36:33Z", GoVersion:"go1.7.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-01-12T04:52:34Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: irrelevant OS (e.g. from /etc/os-release): irrelevant Kernel (e.g. ): irrelevant Install tools: kops Others: What happened: I am trying to set up periodic conformance tests on our cluster to make sure it is working as expected. Prometheus will be used for monitoring. After ing kubernetes I executed a command along the lines of: GINKGOPARALLEL=y KUBERNETESPROVIDER=local KUBEMASTER=local --host="" --test.v=true --"[(SlowSerial)]" --"[Conformance]" --prom-push-gateway=prometheus-push- The push gateway does never receive the metrics, because the feature was removed. What you expected to happen: The tests send the metrics to the push gateway. How to reproduce it (as minimally and precisely as possible): Search for the "PrometheusPushGateway" flag in this repo. It is used nowhere. Anything else we need to know: The feature was removed in but the flags were left in place and also in the documentation. It is frustrating to see that this flag is just a black hole. A solution to this would be to either reinstate the feature or remove the flag from docs and flags.
Blerg. pointed this out back in the PR that remove the functionality, let's follow through and remove the flags. Easy PR if someone wants it
Change:
wantStatus:       framework.NewStatus(framework.Unschedulable, ErrReasonMaxVolumeCountExceeded), }, { <ins> newPod:           inTreeInlineVolPod, existingPods:     []*v1.Pod{inTreeTwoVolPod}, filterName:       "csi", maxVols:          2, driverNames:      []string{csilibplugins.AWSEBSInTreePluginName, ebsCSIDriverName}, migrationEnabled: true, limitSource:      "node", test:             "nil csi node", }, { </ins> newPod:           pendingVolumePod, existingPods:     []*v1.Pod{inTreeTwoVolPod}, filterName:       "csi",

Discussion:
handles cases when csiNode is nil. This is condition is used by cluster-autoscaler internal working. However, the log line refers to causing seg fault
/sig scheduling /sig storage
/sig storage /priority important-soon /triage accepted
/sig storage /sig scheduling Note that the lister returns an error for the case when the doesn't exist. But it's ignored here: It looks like the log line that causes the panic was introduced in in 1.25+
cc
/assign
As far as I can tell this issue is only fixed in version 1.27 (by ). Is there a plan to port it back to releases 1.25 and 1.26 as well?
it has already been picked to 1.25 and 1.26 () and will be in the next patch releases for those versions
Great. Thank you for the pointer.
Change:
function kube::release::package_salt_tarball() { echo "+++ Building tarball: salt" <del> local release_stage="${LOCAL_OUTPUT_ROOT}/release-stage/salt/kubernetes" </del> <ins> local release_stage="${RELEASE_STAGE}/salt/kubernetes" </ins> rm -rf "${release_stage}" mkdir -p "${release_stage}"

Discussion:
Sometimes it is nice to have non-tar'd binaries for releases. We should upload those along with the our packaged tarballs. This will help fix
Change:
"//staging/src/k8s.io/apimachinery/pkg/api/resource:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/apis/meta/v1:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/types:go_default_library", <ins> "//staging/src/k8s.io/apimachinery/pkg/util/errors:go_default_library", </ins> "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/wait:go_default_library", ],

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: A failed Prioritize Map Function caused Scheduler break down. What you expected to happen: Pod remains Pending and describe pod will show errors of failed functions. How to reproduce it (as minimally and precisely as possible): It happens when some prioritize's map functions return with error. Anything else we need to know?: Environment: Kubernetes version (use ): v1.9.6 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
As shown above, if priorityConfigs[i].Map(pod, meta, nodeInfo) returns with error, there will be no chance for results[i + 1] to initialize its value, thus causing panic when calling config.Reduce(pod, meta, nodeNameToInfo, results[i+1])
/sig scheduling
I opened a PR to initialize results with real host name instead of empty string.
Change:
checkpoint, err := ds.checkpointHandler.GetCheckpoint(podSandboxID) // Return empty portMappings if checkpoint is not found if err != nil { <ins> if err == utilstore.ErrKeyNotFound { return nil, nil } </ins> return nil, err }

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 CheckpointNotFoundError has been completely removed by But GetPodPortMappings method was not updated to return nil, when a checkpoint was not available. What happened: The CNI network (that is done for the shared containers only for windows) call would fail in this case, which is breaking CNI in windows. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
Related issue
/sig node /sig windows
/assign
Previous PR for tracking
Change:
], embed = [":go_default_library"], deps = [ <ins> "//pkg/kubelet/config:go_default_library", </ins> "//pkg/volume:go_default_library", "//pkg/volume/testing:go_default_library", "//staging/src/k8s.io/api/core/v1:go_default_library",

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: Deletion of a Pod with an ISCSI volume in mode results in an error during , leaving an ISCSI target logged into on the kubelet node despite the target being unused. In my case, the ISCSI Target server enforces a single session per LUN, which blocks the Pod from starting on another Node in the cluster. What you expected to happen: For the kubelet to issue a logout request for the given target once the refcounter hits zero. How to reproduce it (as minimally and precisely as possible): Have an ISCSI Target server Create a target/LUN that contains an ext4 filesystem. Have a Node configured as an ISCSI Initiator capable of logging into the those targets. Create a Pod on the Node that includes an volume referring the LUN, using (rather than ) mode. minimally: Delete the Pod Wait for the Pod to be destroyed and the related ISCSI block device to be removed. on the Node will show the target is still logged in Kubelet error: Anything else we need to know?: Environment: Kubernetes version (use ): 1.16.2 Cloud provider or hardware configuration: Reproducible on a bare metal (Intel NUC) lab and DigitalOcean DOKS. OS (e.g: ): Ubuntu 18.04 Kernel (e.g. ): 4.15 (NUC) / 4.19 (DigitalOcean) Install tools: Ubuntu package /sig storage