jiebi/CodeConvo huggingface dataset:
Change:
}, HostConfig: &dockercontainer.HostConfig{ Binds: generateMountBindings(config.GetMounts()), <ins> RestartPolicy: dockercontainer.RestartPolicy{ Name: "no", }, </ins> }, }

Discussion:
As part of kubernetes/enhancements we encountered a potential bug. Environment: Kubernetes: 1.10 and 1.11 Docker version: from 17.03.1 checked on multiple cloudproviders. When a node restarts, and the kubelet cannot reach the apiserver, dockerd restarts all the containers in the node. the following logs are emitted: dockerd logs shows the following: when inspecting containers created by the kubelet we see that we create containers with the following restart policy: This is a blocker for kubernetes/enhancements as when the node restart the controller-manager cannot assume that it is safe to detach volumes as they might be mounted by the pods. /priority critical-urgent /kind bug /sig node
according to the docker doc, that looks correct: is this a docker bug?
does docker treat a system restart differently? I don't see a restart policy value other than / that would let us tell docker we didn't want containers auto-restarted on reboot
- forcing this to no mitigates the issue.
I couldn't reproduce this on my cluster (kubernets 1.13, GCE, COS image with docker 17.03.2-ce). I tried both methods -- 1) w/ k8s, stop apiserver, and restart the node, and 2) create a docker container with empty restart policy, reboot the node. Since this can be a docker bug, could you get an os image version + docker version, and commands to reproduce this?
- apologies, I double-checked both hosts were on 17.03.1-ce, I tried to reproduce with 17.3.2 but wasn't able to do so. From the nothing seems have fixed the issue. Can you confirm that you are able to reproduce the issue on 17.3.1 ? Also forcing the restartPolicy to mitigates the issue for this version. It seems like isn't treated consistently. - do you have any concern to change dockershim to set explicitly a restart policy to ?
It appears we are depending on the implicit default of "no" currently () If that behaves inconsistently on different docker versions, I think making it explicit is reasonable.
sgtm
Change:
sourcesReady:          sourcesReady, clusterDomain:         clusterDomain, clusterDNS:            clusterDNS, <del> } </del> <ins> }, nil </ins> } type httpGetter interface {

Discussion:
Things like SyncFrequency should have a lower-bound of acceptable, and that really should be 0ns.
The main point of this is now fixed, though we could be better about input checking all over
Change:
func DeepCopyJSONValue(x interface{}) interface{} { switch x := x.(type) { case map[string]interface{}: <ins> if x == nil { // Typed nil - an interface{} that contains a type map[string]interface{} with a value of nil return x } </ins> clone := make(map[string]interface{}, len(x)) for k, v := range x { clone[k] = DeepCopyJSONValue(v) } return clone case []interface{}: <ins> if x == nil { // Typed nil - an interface{} that contains a type []interface{} with a value of nil return x } </ins> clone := make([]interface{}, len(x)) for i, v := range x { clone[i] = DeepCopyJSONValue(v)

Discussion:
What happened: In I introduced an optimization - do a deep copy instead of to and from JSON roundtrip to convert anything that implements . I then discovered that the method that is used there in both and may mutate the original object. This is problematic because previously (before ) there was no mutation and because this is unexpected and may lead to data races - it is bad behaviour to mutate original object when you just want a copy of it. This issue was fixed by . However the underlying issue is not fixed here - is brittle and dangerous. Method name does not imply that it mutates data when you call it. And godoc does not mention that either: Something needs to be done about it IMO. This method is misused in these places (mutation side effect is not intended): Also implementation in does not implement the behaviour required by godoc in . What you expected to happen: There should be a method that returns the current unstructured contents without mutation and perhaps not providing the write-through effect. /kind bug /sig api-machinery
/cc
Is this still required and could I work on it? I'm looking for something to work on as a new contributor :)
Yes and yes! :)
Perfect, I'll get started on it!
I've got out. I'd appreciate a review :)
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:
}, }, { <ins> name:                "PVC does not exist", pod:                 makePod("pod-a", []string{"pvc-a"}), node:                &v1.Node{}, pvcs:                []*v1.PersistentVolumeClaim{}, wantPreFilterStatus: framework.NewStatus(framework.UnschedulableAndUnresolvable, `persistentvolumeclaim "pvc-a" not found`), }, { name: "Part of PVCs do not exist", pod:  makePod("pod-a", []string{"pvc-a", "pvc-b"}), node: &v1.Node{}, pvcs: []*v1.PersistentVolumeClaim{ makePVC("pvc-a", "pv-a", waitSC.Name), }, wantPreFilterStatus: framework.NewStatus(framework.UnschedulableAndUnresolvable, `persistentvolumeclaim "pvc-b" not found`), }, { </ins> name: "immediate claims not bound", pod:  makePod("pod-a", []string{"pvc-a"}), node: &v1.Node{},

Discussion:
What would you like to be : Scheduler VolumeBinding plugin reports error when a PVC doesn't exist for example: We need to take a second look at the VolumeBinding plugin and make sure that errors are returned only when there is a system error, not a user error. Why is this needed: To fix the scheduler's error reporting metrics. /sig scheduling /sig storage /cc
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
/assign I'll take a look.
If the PVC object does not exist, the plugin will return status. I guess you mean the plugin will return an error when a referenced PV does not exist? I've created a PR for this:
Thanks! The errors I am seeing are on 1.18 clusters, can we look at 1.18 and try to patch? This is still throwing the scheduler's error metrics off.
sure
I've submitted a patch for the 1.18 release branch:
I guess on the master branch should be reviewed and merged too? cc
hello! the fix you made only apply for 1.18? how about 1.19 and 1.17? thanks!
after the fix on the master branch () is merged, I'll cherry-pick it into the 1.19 branch (the code are almost the same). I'm not sure if it's necessary to fix the 1.17 branch. It's 3 versions behind 1.20.
hi, This is because of this patch: Do you think this fix needs to be cherry-picked into 1.19 and 1.18 branch too?
can you send a patch for 1.19?
ah, here it is
to sum up: master: 1.19: 1.18: and I think this change should be backported to 1.19/1.18 too: I'll send PRs soon.

summary of the issue that an error will be reported instead of UnschedulableAndUnresolvable when PVC not found: master: already implemented, see 1.19: 1.18: can't backport as it does not implement the PreFilter extension point
Change:
} func (q *graceTerminateRSList) flushList(handler func(rsToDelete *listItem) (bool, error)) bool { <ins> q.lock.Lock() defer q.lock.Unlock() </ins> success := true for name, rs := range q.list { deleted, err := handler(rs)

Discussion:
! no panic Kubernetes version (use ): k8s 1.16
/sig Network
Could you fix this? I think the function needs a lock while being executed.
/triage accepted /good-first-issue todo: add a lock around the body of this function: Similar to
/assign
Oh I see, thank you for letting me know, I'll keep that in mind going forward. :)
Anyone actually on this? It seems like a good fix to have for 23 and maybe backport
I'll have a try.
There is a reproducer here
Oops, I just peeked at the time of the pull request and not realized that you've got such deep conversation.
/remove-good-first-issue /unassign
/assign
hi ! someone work on this now? I would like to try it.
Yes, working on it currently.
are you still planning to give this a shot?
Is there no one working on this? If so, I'd submit a PR for it this week. :)
Change:
t.Errorf("missing watch event") } } <ins> func TestSelfLink(t *testing.T) { stopCh, apiExtensionClient, clientPool, err := testserver.StartDefaultServer() if err != nil { t.Fatal(err) } defer close(stopCh) noxuDefinition := testserver.NewNoxuCustomResourceDefinition() noxuVersionClient, err := testserver.CreateNewCustomResourceDefinition(noxuDefinition, apiExtensionClient, clientPool) if err != nil { t.Fatal(err) } ns := "not-the-default" noxuNamespacedResourceClient := noxuVersionClient.Resource(&metav1.APIResource{ Name:       noxuDefinition.Spec.Names.Plural, Namespaced: true, }, ns) noxuInstanceToCreate := testserver.NewNoxuInstance(ns, "foo") createdNoxuInstance, err := noxuNamespacedResourceClient.Create(noxuInstanceToCreate) if err != nil { t.Fatal(err) } if e, a := "/apis/mygroup.example.com/v1alpha1/namespaces/not-the-default/noxus/foo", createdNoxuInstance.GetSelfLink(); e != a { t.Errorf("expected %v, got %v", e, a) } // TODO add test for cluster scoped self-link when its available } </ins>

Discussion:
as discussed via IRC my understanding is that customResource selfLink is broken. For example for resource created the selfLink is while as far as I understand it should be something like: disregard in case I'm wrong.
Change:
for _, v := range s.XValidations { expressions.rules.Insert(v.Rule) if len(v.MessageExpression) > 0 { <del> expressions.messageExpressions.Insert(v.Rule) </del> <ins> expressions.messageExpressions.Insert(v.MessageExpression) </ins> } } return false

Discussion:
Noticed a copy & paste issue when reading through the CEL code. Basically here: This should be instead of: The impact of this issue should be that messageExpressions are always evaluated with the CEL environment of the compatibility version. But stored (i.e. pre-existing) messageExpressions should be evaluated with a CEL environment with the "max" version instead. For users of Kubernetes this means that messageExpressions deployed with one minor version of Kubernetes might not work anymore if they rollback e.g. by one minor version. messageExpressions should be treated the same way as rules in that regard. Deploy Kubernetes 1.30 Deploy CRD that uses messageExpression that is using Sets (which became available with Kubernetes 1.30 that is using compatibilty version 1.29) Rollback to Kubernetes 1.29 Update something in the CRD =CRD update will fail because messageExpression is evaluated with the wrong CEL environment (it should still work) No response <detailsAt least on Kubernetes main, but I would assume this isuse is there since CEL was implemented </details<details</details
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <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
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
cc Will open a PR in a bit
Change:
newService("s2", "666", true), }, expectedUpdateCalls: []fake_cloud.FakeUpdateBalancerCall{ <del> {Name: lbName("s0"), Region: region, Hosts: []string{"node0", "node1", "node73"}}, {Name: lbName("s1"), Region: region, Hosts: []string{"node0", "node1", "node73"}}, {Name: lbName("s2"), Region: region, Hosts: []string{"node0", "node1", "node73"}}, </del> <ins> {Name: "a444", Region: region, Hosts: []string{"node0", "node1", "node73"}}, {Name: "a555", Region: region, Hosts: []string{"node0", "node1", "node73"}}, {Name: "a666", Region: region, Hosts: []string{"node0", "node1", "node73"}}, </ins> }, }, {

Discussion:
Since this PR got merged, the ELB e2e test, which was consistently succeeding, is now consistently failing: Revert now that is in, and fix the tests that were relying on it. (details) Commit by arob Revert now that is in, and fix the tests that were relying on it. The file was modified The file was modified The file was modified I'm going to roll it back to confirm.
Change:
gvr("flowcontrol.apiserver.k8s.io", "v1beta1", "flowschemas"): { Stub:             `{"metadata": {"name": "va2"}, "spec": {"priorityLevelConfiguration": {"name": "name1"}}}`, ExpectedEtcdPath: "/registry/flowschemas/va2", <del> ExpectedGVK:      gvkP("flowcontrol.apiserver.k8s.io", "v1beta2", "FlowSchema"), </del> <ins> ExpectedGVK:      gvkP("flowcontrol.apiserver.k8s.io", "v1beta3", "FlowSchema"), </ins> }, // --

Discussion:
adds new version for in 1.26. For 1.26, we are setting the storage version to because vN-1 understands that level. In 1.27, we should change the storage version from to .
/sig api-machinery
/cc
/cc
/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]:
Change:
return notMnt, mountPointsErr } for _, mp := range mountPoints { <del> if mounter.IsMountPointMatch(mp, file) { </del> <ins> if mounter.IsMountPointMatch(mp, resolvedFile) { </ins> notMnt = false break }

Discussion:
This is related to and , but these issues contain several different bugs, so I am creating a new one. Steps to reproduce: must be a symlink somewhere else. If you don't have a symlink, then it's a different bug. a pod with ConfigMap volume with SubPath: (the pod should run just fine) -The pod is Terminating forever From the logs: You can see there is no "Unmounting /var/lib/kubelet/pods/-ba83-11e8-983c-/volume-subpaths/vol/busybox/0", so kubelet did not even try to unmount it. Environment: Kubernetes version 1.9.x (and today's master). /kind bug /sig storage another subpath bug :-)
Posted , kubelet gets confused by /var/lib/kubelet being a symlinks and it looks for /var/lib/kubelet/pods/... in /proc/mounts instead of target of the symlink.
Change:
package fieldmanager import ( <ins> "fmt" v1 "k8s.io/apimachinery/pkg/apis/meta/v1" </ins> "reflect" "testing" "time"

Discussion:
I created an object with , and later I updated the same object with another . After that I looked at the object's managedFields, and saw nothing about the update. Here is what I got after the second apply: I expected managedFields to get updated by the second . No response <details</details<detailsnone </details<details</details<detailskubeadm </details<detailsdocker </details<details</details
/cc
I also saw the timestamp not updated when I updated using client-go and typed client stubs, Apply method, patch type .
/assign /triage accepted
/cc
The is not updated because you are not changing the structure of the object (adding or removing fields). According to , the time is updated if and only if the fieldSet is changed. It does not take into account the value of fields. One option would be to not compare the fieldSets but directly compare the liveObject & newObject for differences and update the field accordingly. Is it the desired behavior to update the time of when only the value is updated?
Yes! Look at the first paragraph of .
is that documentation correct? Is this what we intended?
I don't see any mention to the timestamp in that first paragraph. We've clarified recently the exact semantic of the timestamp, as defined here: I think you've identified the wrong code if you want to go ahead and fix it, go ahead, I'll happily review!
Change:
cd "${KUBE_ROOT}" <ins> ret=0 TYPECHECK_SERIAL="${TYPECHECK_SERIAL:-false}" SERVER_PLATFORMS=$(echo "${KUBE_SUPPORTED_SERVER_PLATFORMS[@]}" | tr ' ' ',') CLIENT_PLATFORMS=$(echo "${KUBE_SUPPORTED_CLIENT_PLATFORMS[@]}" | tr ' ' ',') NODE_PLATFORMS=$(echo "${KUBE_SUPPORTED_NODE_PLATFORMS[@]}" | tr ' ' ',') TEST_PLATFORMS=$(echo "${KUBE_SUPPORTED_TEST_PLATFORMS[@]}" | tr ' ' ',') </ins> # As of June, 2020 the typecheck tool is written in terms of go/packages, but # that library doesn't work well with multiple modules.  Until that is done, # force this tooling to run in a fake GOPATH. <del> ret=0 TYPECHECK_SERIAL="${TYPECHECK_SERIAL:-false}" </del> hack/run-in-gopath.sh  <del> go run test/typecheck/main.go "$@" "--serial=$TYPECHECK_SERIAL" || ret=$? </del> <ins> go run test/typecheck/main.go "$@" --serial="${TYPECHECK_SERIAL}" --platform "${SERVER_PLATFORMS}" "${KUBE_SERVER_TARGETS[@]}"  || ret=$? hack/run-in-gopath.sh  go run test/typecheck/main.go "$@" --serial="${TYPECHECK_SERIAL}" --platform "${CLIENT_PLATFORMS}" "${KUBE_CLIENT_TARGETS[@]}"  || ret=$? hack/run-in-gopath.sh  go run test/typecheck/main.go "$@" --serial="${TYPECHECK_SERIAL}" --platform "${NODE_PLATFORMS}" "${KUBE_NODE_TARGETS[@]}"  || ret=$? # $KUBE_TEST_TARGETS doesn't seem to work like the other TARGETS variables... hack/run-in-gopath.sh  go run test/typecheck/main.go "$@" --serial="${TYPECHECK_SERIAL}" --platform "${TEST_PLATFORMS}" test/e2e  || ret=$? </ins> if [[ $ret -ne 0 ]]; then echo "!!! Type Check has failed. This may cause cross platform build failures." >&2 echo "!!! Please see https://git.k8s.io/kubernetes/test/typecheck for more information." >&2

Discussion:
In I tried to reorganize the kube-proxy build a bit, and ran into the problem that verify-typecheck failed because was no longer buildable on darwin/amd64 and darwin/arm64. This was surprising because we don't build kube-proxy on OS X. It seems like verify-typecheck ought to be taking / from into account when deciding what to check. There's no reason to be checking the OS X type compatibility of binaries that we don't build on OS X.
/sig network
/remove-sig network /sig testing Agree, we need to plumb this through. We should also consider plumbing through static vs non-static and cgo enable/disable while we're at it. The goal is to be a low-fidelity cross-build to catch most code errors that would break the full without actually having to run the computationally expensive cross build, but there's some mismatch ...
/triage accepted
Change:
// did we find it? if newDevicePath != "" { <del> // the current sequence k8s uses for unformated disk (check-disk, mount, fail, mkfs.extX) hangs on // Azure Managed disk scsi interface. this is a hack and will be replaced once we identify and solve // the root case on Azure. formatIfNotFormatted(newDevicePath, *volumeSource.FSType, exec) </del> return true, nil }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When use an existing azure disk(also called ) in pod, if that disk has partitions, the disk will be formatted in the pod mounting. What you expected to happen: How to reproduce it (as minimally and precisely as possible): create a disk with source from an os disk, e.g. that disk is already formatted before pod could access it Anything else we need to know?: Root cause: current diskLooksUnformatted func is using command to check whether disk is formatted or not while common k8s code() is using to detect disk format, could detect multiple partitions so if we use common k8s code(), following error will be returned for mulitple partition disks, which is expected: Environment: Kubernetes version (use ): v1.7 - v1.11 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig azure /assign
cc
iirc we don't support partitions on Azure volumes. There was a specific hang long ago. in all cases i think should be safe to based check now via the underlaying api
thanks for the info, I am writing this PR, and also testing carefully. And this issue depends on , could you review it first? Thanks.
Change:
diskName:         diskName, oldSize:          *resource.NewQuantity(1*(1024*1024*1024), resource.BinarySI), newSize:          *resource.NewQuantity(2*(1024*1024*1024), resource.BinarySI), <del> existedDisk:      compute.Disk{Name: to.StringPtr("disk1"), DiskProperties: &compute.DiskProperties{DiskSizeGB: &diskSizeGB}}, </del> <ins> existedDisk:      compute.Disk{Name: to.StringPtr("disk1"), DiskProperties: &compute.DiskProperties{DiskSizeGB: &diskSizeGB, DiskState: compute.Unattached}}, </ins> expectedQuantity: *resource.NewQuantity(2*(1024*1024*1024), resource.BinarySI), expectedErr:      false, },

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: resize Azure disk issue when it's in attached state: 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: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: /priority important-soon /sig cloud-provider /area provider/azure /triage accepted /kind bug /assign
Change:
HardPodAffinitySymmetricWeight: 1, HealthzBindAddress:             "0.0.0.0:10251", MetricsBindAddress:             "0.0.0.0:10251", <ins> DebuggingConfiguration: componentbaseconfig.DebuggingConfiguration{ EnableProfiling:           true, EnableContentionProfiling: true, }, </ins> LeaderElection: kubeschedulerconfig.KubeSchedulerLeaderElectionConfiguration{ LeaderElectionConfiguration: componentbaseconfig.LeaderElectionConfiguration{ LeaderElect:       true,

Discussion:
What would you like to be : Enable profiling by default in the scheduler. We can do this by defaulting the CC flags to true. Why is this needed: It is useful when debugging the performance of a running cluster. API server already enables profiling by default. /sig scheduling /help /milestone v1.17
/assign /remove-help
Change:
export KUBE_CERT="${CERT_DIR}/pki/issued/kubecfg.crt" export KUBE_KEY="${CERT_DIR}/pki/private/kubecfg.key" export CA_CERT="${CERT_DIR}/pki/ca.crt" <del> export CONTEXT="aws_${INSTANCE_PREFIX}" </del> <ins> export CONTEXT="${CONFIG_CONTEXT}" </ins> ( umask 077 create-kubeconfig

Discussion:
I've run to create a cluster, which resulted in a cluster and user being created in kube-config. Now I want to run again with different parameters, to create a second cluster in a different AWS account. I would like to use a different name for the cluster and user for this cluster. From what I can see from the , there seems to be no way to completely override the name used. I understand that I can use a separate kube-config file, but I don't want to do that. I want to use the same kube-config file, with multiple clusters and users, all handled by .
Manually overwriting file to set CONTEXT to a different value works to achieve the effect that I want. This value should be allowed to be set externally so that we don't have to resort to manually editing the file for each cluster.
Fixed in