jiebi/CodeConvo huggingface dataset:
Change:
<tr> <td class="tableblock halign-left valign-top"><p class="tableblock">disruptedPods</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">DisruptedPods contains information about pods whose eviction was processed by the API server eviction subresource handler but has not yet been observed by the PodDisruptionBudget controller. A pod will be in this map from the time when the API server processed the eviction request to the time when the pod is seen by PDB controller as having been marked for deletion (or after a timeout). The key in the map is the name of the pod and the value is the time when the API server processed the eviction request. If the deletion didn&#8217;t occur and a pod is still there it will be removed from the list automatically by PodDisruptionBudget controller after some time. If everything goes smooth this map should be empty for the most of the time. Large number of entries in the map may indicate problems with pod deletions.</p></td> <del> <td class="tableblock halign-left valign-top"><p class="tableblock">true</p></td> </del> <ins> <td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td> </ins> <td class="tableblock halign-left valign-top"><p class="tableblock">object</p></td> <td class="tableblock halign-left valign-top"></td> </tr>

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: PodDisruptionBudget provides inappropriate message and cannot be updated as is required filed. What you expected to happen: works fine for editing labels under . Also, produce correct error message when edit field. How to reproduce it (as minimally and precisely as possible): Then, we will get following error after step-2. When edit , it should provide correct message as .When edit especially labels under metadata, they should be updated without error. Anything else we need to know?: According to the code comment, is valid. Environment: Kubernetes version (use ): build on
/sig cli
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 there is a PR open
Change:
return nil, nil } <ins> func (fVMC *fakeAzureVirtualMachinesClient) Update(ctx context.Context, resourceGroupName string, VMName string, parameters compute.VirtualMachineUpdate, source string) (resp *http.Response, err error) { fVMC.mutex.Lock() defer fVMC.mutex.Unlock() if _, ok := fVMC.FakeStore[resourceGroupName]; !ok { fVMC.FakeStore[resourceGroupName] = make(map[string]compute.VirtualMachine) } return nil, nil } </ins> func (fVMC *fakeAzureVirtualMachinesClient) Get(ctx context.Context, resourceGroupName string, VMName string, expand compute.InstanceViewTypes) (result compute.VirtualMachine, err error) { fVMC.mutex.Lock() defer fVMC.mutex.Unlock()

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Instead of using the VM CreateOrUpdate () function of the Azure Go SDK, use the VM Update function () in the azureclient () Why is this needed: Currently, the Azure Cloud Provider is using the VM CreateOrUpdate call when e.g. detach/attaching disks to a VM. In some scenarios, this will re-create a VM that was deleted by an external application. This can lead to orphaned VMs or blocked resources. The Update function will only update an existing VM and will fail if the VM does not exist.
/sig azure
/assign
/sig cloud-provider
Could you describe more about the scenarios? Have you noticed such issues? I wonder adding etags to the API call could help to prevent this?
If you have an application that maintains your K8s clusters, e.g. takes care of OS update/patching. If the application wants to patch the OS of a worker node, it would drain the node first. If draining times out, it will go ahead and delete the VM anyway. But K8s might still be detaching disks. These detach operations, because they use CreateOrUpdate, will recreate the VM. Is there a reason why you would want to create a VM i.e. why CreateOrUpdate is required and Update would not work? AFAIK, Azure Compute RP does not support etags.
that sounds reasonable, thanks change to use function would be safer since it's only detach/attach disk operation. I will do that.
thanks for the information. Reasonable enough. /assign
/milestone v1.16
BTW, the reason why we only use func in the beginning is that Azure Compute go sdk did not provide a func at that time...
Great. Thanks!
Change:
SRCS=loader ARCH ?= amd64 TARGET ?= $(CURDIR) <ins> GOARM ?= 7 </ins> GOLANG_VERSION ?= latest SRC_DIR = $(notdir $(shell pwd)) export

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: Building the image binaries requires the GOARM variable to be set. Because it is not defined in all Makefiles, cannot the image binaries for the images in question. What you expected to happen: should succeed. How to reproduce it (as minimally and precisely as possible): git clone cd kubernetes/test/images/entrypoint-tester make Anything else we need to know?: Environment: N/A Kubernetes version (use ): N/A Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
/sig testing
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
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
/lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Change:
"//staging/src/k8s.io/client-go/discovery:all-srcs", "//staging/src/k8s.io/client-go/dynamic:all-srcs", "//staging/src/k8s.io/client-go/examples/create-update-delete-deployment:all-srcs", <ins> "//staging/src/k8s.io/client-go/examples/dynamic-create-update-delete-deployment:all-srcs", </ins> "//staging/src/k8s.io/client-go/examples/fake-client:all-srcs", "//staging/src/k8s.io/client-go/examples/in-cluster-client-configuration:all-srcs", "//staging/src/k8s.io/client-go/examples/leader-election:all-srcs",

Discussion:
What would you like to be : Add documentation/example showing the usage of dynamic package in the client-go repo. /sig api-machinery
Change:
if [[ "${s3_bucket_location}" == "None" ]]; then # "US Classic" does not follow the pattern s3_url_base=https://s3.amazonaws.com <ins> s3_bucket_location=us-east-1 </ins> fi local -r staging_path="devel"

Discussion:
When I run: I get the following error: Waiting a bit and running got past this point because the bucket was ready the second time around, but the getting-started process should be more robust.
I experienced the same issue
We do try to query for the bucket existing, but perhaps S3 is even more eventually consistent than I thought! I did observe that we were very trusting about the user providing the correct S3 region, and have tried to fix this in . I don't think that was the problem here though (if you make_bucket, you can't have a region mismatch...) I guess we could retry the sync a few times; might help with e.g. a network interruption during the sync also.
I believe this to have been fixed by . I'm going to close, but if it happens again please do reopen.
FYI I got this with the latest k8s as of 10/13/15: I believe this is k8s 1.0.6 but I just tore down my AWS cluster and apparently kubectl needs to talk to the now-terminated master instance. I ran to get k8s. Waiting and running again doesn't show the issue since the bucket is fully created and accessible. I just provisioned a Vagrant cluster in hopes that would help show what version I'm using. Here's the output of :
Change:
# --output-base    because this script should also be able to run inside the vendor dir of #                  k8s.io/kubernetes. The output-base is needed for the generators to output into the vendor dir #                  instead of the $GOPATH directly. For normal projects this can be dropped. <del> "${CODEGEN_PKG}/generate-groups.sh" all  </del> <ins> bash "${CODEGEN_PKG}/generate-groups.sh" all  </ins> k8s.io/sample-apiserver/pkg/generated k8s.io/sample-apiserver/pkg/apis  "wardle:v1alpha1,v1beta1"  --output-base "$(dirname "${BASH_SOURCE[0]}")/../../.."  --go-header-file "${SCRIPT_ROOT}"/hack/boilerplate.go.txt <del> "${CODEGEN_PKG}/generate-internal-groups.sh" "deepcopy,defaulter,conversion"  </del> <ins> bash "${CODEGEN_PKG}/generate-internal-groups.sh" "deepcopy,defaulter,conversion"  </ins> k8s.io/sample-apiserver/pkg/generated k8s.io/sample-apiserver/pkg/apis k8s.io/sample-apiserver/pkg/apis  "wardle:v1alpha1,v1beta1"  --output-base "$(dirname "${BASH_SOURCE[0]}")/../../.." 

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: I wanted to test the latest version of the sample-apiserver. I still did not find instructions or a script for building it. I found the script, but that relies on the directory produced when building k/k. What you expected to happen: I expected this sample to have standalone build instructions or scripting. 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:
I created a script of my own to build it:
Also: since the file has a fixed image reference, only someone who pushes to that image can use that file unmodified. The README should say something about this.
Also, the existing is not designed to be invoked by a developer who has done but rather is designed to work only in the context of a full build of k/k.
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 Being addressed by
Change:
- replaceCoreV1PersistentVolume - replaceCoreV1PersistentVolumeStatus - replaceStorageV1CSINode <del> - replaceStorageV1StorageClass </del> - replaceStorageV1VolumeAttachment - replaceStorageV1VolumeAttachmentStatus

Discussion:
[X] test approval issue : [X] test pr : [X] two weeks soak end date : 22 Sept 2023 [X] test promotion pr : [X] remove endpoint from According to following APIsnoop query, there are three StorageClass endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 7 endpoints. The e2e logs for this test are listed below. This query shows the following StorageClass 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 7 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted /cc
/sig storage
/reopen For tracking the rest of the steps to Promotion
Reopened this issue. <detailsIn response to : /reopen For tracking the rest of the steps to Promotion 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:
errors := []error{} if s.BindPort < 0 || s.BindPort > 65535 { <del> errors = append(errors, fmt.Errorf("--insecure-port %v must be between 0 and 65535, inclusive. 0 for turning off insecure (HTTP) port.", s.BindPort)) </del> <ins> errors = append(errors, fmt.Errorf("--insecure-port %v must be between 0 and 65535, inclusive. 0 for turning off insecure (HTTP) port", s.BindPort)) </ins> } return errors

Discussion:
Currently as authentication and authorization are both standard config for all clusters, the kubeapiserver insecure http handler is unsecure, which means the cluster is vulnerable to the attack. So it should be deprecated, even removed totally.
/sig api-machinery
I think removing the insecure option is a good idea. Can you send an email the sig-apimachinery mailing list with a proposed timeline? I think this should be like other GA features and have a one year clock.
Sure, I will send it ASAP.
:+1:
Change:
"k8s.io/client-go/util/workqueue/parallelizer.go", "k8s.io/client-go/util/workqueue/queue.go", "k8s.io/client-go/util/workqueue/rate_limitting_queue.go", <del> "k8s.io/client-go/util/workqueue/timed_queue.go", </del> ], tags = ["automanaged"], deps = [

Discussion:
The TimedWorkQueue object appears to lack a critical feature of the original WorkOueue, namely that similar items are aggregated together. By adding the time member to to the key type, it ensures that (time, item) pairs are unique-- you can add the same item multiple times as long as the time differs. This removes the guarantee that two goroutines wouldn't process the same item at the same time.
Iirc, the timed queue feeds a regular queue, so the guarantee still holds
Sorry, I was thinking of the delaying queue, which does key correctly
I'm going to remove timed workqueue. It's used to gather metrics for queues used in the garbage collector. This feature is supported by a regular workqueue now.
Change:
runtimeApi "k8s.io/kubernetes/pkg/kubelet/api/v1alpha1/runtime" kubecontainer "k8s.io/kubernetes/pkg/kubelet/container" <ins> "k8s.io/kubernetes/pkg/kubelet/dockertools" </ins> "k8s.io/kubernetes/pkg/kubelet/qos" "k8s.io/kubernetes/pkg/kubelet/types" )

Discussion:
What happened: Latest kubelet + Windows Docker version 1.14.0-dev refused to start any containers, error output: "invalid option: Windows does not support MemorySwap" How to reproduce it (as minimally and precisely as possible): It's always reproducible with Windows Docker 1.14.0-dev + latest kubelet code base. Anything else do we need to know: It didn't happen for Windows Docker 1.12.2-cs2-ws-beta. The reason behind the issue was because new code was for Windows Docker to check Resources parameters, it doesn't accept a non-zero value for MemorySwap: But kubelet was default to set an unlimited (-1) value. The issue was gone in my setup after applied a private fix to disable MemorySwap by set it to zero for Windows.
Change:
QOSReserved featuregate.Feature = "QOSReserved" // owner: @chrishenzie <ins> // kep: https://kep.k8s.io/2485 </ins> // alpha: v1.22 <ins> // beta: v1.27 </ins> // // Enables usage of the ReadWriteOncePod PersistentVolume access mode. ReadWriteOncePod featuregate.Feature = "ReadWriteOncePod"

Discussion:
For 1.27 we should graduate the ReadWriteOncePod feature to beta. This is needed to rollout the feature to GA. In beta this feature will support preemption of pods using PVCs. See:
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 /sig scheduling
Change:
} if in.HostIP != "" { <del> out.Status.Addresses = append(out.Status.Addresses, </del> <ins> newer.AddToNodeAddresses(&out.Status.Addresses, </ins> newer.NodeAddress{Type: newer.NodeLegacyHostIP, Address: in.HostIP}) } out.Spec.PodCIDR = in.PodCIDR

Discussion:
Since we append hostips to the list on every node controller run invocation which happens at 10s intervals, this list grows pretty large pretty soon: Maybe: would still satisfy the requirements?
Fix is here I think we generally use list instead of map
This could have been P1, but I just merged a fix so I'll leave at P2. Remaining work to do: Add to validation something that limits the number of IP addresses. (and maybe checks dups?)
Yeah, I'll add validation later.
Change:
// using host based configurations. func NewDenyEscalatingExec() *DenyExec { return &DenyExec{ <del> Handler:    admission.NewHandler(admission.Connect), hostIPC:    true, hostPID:    true, privileged: true, </del> <ins> Handler:     admission.NewHandler(admission.Connect), hostNetwork: true, hostIPC:     true, hostPID:     true, privileged:  true, </ins> } } // NewDenyExecOnPrivileged creates a new admission controller that is only checking the privileged <del> // option.  This is for legacy support of the DenyExecOnPrivileged admission controller.  Most // of the time NewDenyEscalatingExec should be preferred. </del> <ins> // option. This is for legacy support of the DenyExecOnPrivileged admission controller. // Most of the time NewDenyEscalatingExec should be preferred. </ins> func NewDenyExecOnPrivileged() *DenyExec { return &DenyExec{ <del> Handler:    admission.NewHandler(admission.Connect), hostIPC:    false, hostPID:    false, privileged: true, </del> <ins> Handler:     admission.NewHandler(admission.Connect), hostNetwork: false, hostIPC:     false, hostPID:     false, privileged:  true, </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 bug What happened: currently only are checked in admission controller What you expected to happen: hostNetwork should also be checked to deny exec /attach 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:
/kind bug /sig auth
cc
Change:
import ( "fmt" <del> "reflect" </del> <ins> apiequality "k8s.io/apimachinery/pkg/api/equality" </ins> "k8s.io/apimachinery/pkg/fields" "k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/runtime"

Discussion:
Kubernetes version (use ): Environment: Cloud provider or hardware configuration: DigitalOcean OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools:Others: What happened: when I do: it will run rolling update ONLY if there is a change. In case I do: Each time I run it - it will execute rolling update, which is misleading. What you expected to happen: I would like to have consistent behavior for Deployment and DaemonSet How to reproduce it (as minimally and precisely as possible): Create any DaemonSet with following:
Hmm, it shouldn't happen. TemplateGeneration is updated only when something changed. I will debug it.
I can reproduce this, and the DaemonSet is updated after every , even when nothing is changed. In , old/new DaemonSet template are seen as different with . I tried to change this part to use instead (needed to update code in validation as well), and the DaemonSet templates were then seen as the same, and thus the issue was gone. We used everywhere in the controllers. Is the right way to compare stuffs?
It's very strange. I tried to use pretty.Diff to print the differences but it returns empty slice. apiequality.Semantic.DeepEqual uses forked version of reflect.DeepEqual and it's little different from version in 1.7. will you prepare the patch?
The key of the reported DaemonSet config is its . Note that in the config file, (empty list); however, in the live DaemonSet object (created from the config file), (null list). That's why thinks they're different. If we use in the config file instead, won't change. From the field description, empty list and null list are different. Feel it's api machinery related
protobuf storage isn't able to store , so the object has that field set to when read back from storage. that is causing problems for that field in particular (where and have different meanings) see
cc for behavior of namespaces field
so it's not a DaemonSet bug
Well, still not sure whether Semantic.DeepEqual should be used or not. I'm still concerned with the behavior of the controller for other fields that can be populated with non-null empty lists by users, but serialize back out to null (or set omitempty)
deployments are using Maybe we should also switch?

If empty lists should be treated differently from null list, we should replace with in controller code.
that distinction is going away in all the fields I know of... I'm not super happy with Semantic.DeepEqual masking the difference between those two things, but that's probably the right thing for you to be using
Special meaning of [] was removed in I think a switch to Semantic.DeepEqual is still needed here
Filed
Change:
kubeclientset "k8s.io/kubernetes/pkg/client/clientset_generated/release_1_5" fake_kubeclientset "k8s.io/kubernetes/pkg/client/clientset_generated/release_1_5/fake" "k8s.io/kubernetes/pkg/runtime" <ins> "k8s.io/kubernetes/pkg/util/wait" </ins> "github.com/stretchr/testify/assert" )

Discussion:
https://k8s- Failed: TestNamespaceController {namespace} Previous issues for this test:
GetObjectFromChan() is timing out (20s) and returning nil causing the panic. Happens in TestSecretController (and probably TestIngressController) controller as well. https://k8s-
https://k8s- Failed: TestNamespaceController {namespace}
https://k8s- Failed: TestNamespaceController {namespace}
https://k8s- Failed: TestNamespaceController {namespace}
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: TestNamespaceController {namespace}
https://k8s- Failed: TestNamespaceController {namespace}
I have a fix for this in
https://k8s- Failed: TestNamespaceController {namespace}
https://k8s- Failed: TestNamespaceController {namespace}
https://k8s- Failed: TestNamespaceController {namespace}
/cc OWNERS of :
I think this is also related to Issue .
fix is pending