jiebi/CodeConvo huggingface dataset:
Change:
const ( hostRootFsPath     = "/rootfs" hostProcMountsPath = "/rootfs/proc/mounts" <del> nsenterPath        = "/nsenter" </del> <ins> nsenterPath        = "nsenter" </ins> ) // Mount runs mount(8) in the host's root mount namespace.  Aside from this // aspect, Mount has the same semantics as the mounter returned by mount.New() <del> func (*NsenterMounter) Mount(source string, target string, fstype string, options []string) error { </del> <ins> func (n *NsenterMounter) Mount(source string, target string, fstype string, options []string) error { </ins> bind, bindRemountOpts := isBind(options) if bind { <del> err := doNsenterMount(source, target, fstype, []string{"bind"}) </del> <ins> err := n.doNsenterMount(source, target, fstype, []string{"bind"}) </ins> if err != nil { return err } <del> return doNsenterMount(source, target, fstype, bindRemountOpts) </del> <ins> return n.doNsenterMount(source, target, fstype, bindRemountOpts) </ins> } <del> return doNsenterMount(source, target, fstype, options) </del> <ins> return n.doNsenterMount(source, target, fstype, options) </ins> } // doNsenterMount nsenters the host's mount namespace and performs the // requested mount. <del> func doNsenterMount(source, target, fstype string, options []string) error { </del> <ins> func (n *NsenterMounter) doNsenterMount(source, target, fstype string, options []string) error { </ins> glog.V(5).Infof("nsenter Mounting %s %s %s %v", source, target, fstype, options) <del> args := makeNsenterArgs(source, target, fstype, options) </del> <ins> args := n.makeNsenterArgs(source, target, fstype, options) </ins> glog.V(5).Infof("Mount command: %v %v", nsenterPath, args) exec := exec.New()

Discussion:
What happened: Windows documentation claims: V1.VolumeMount.mountPropagation - only MountPropagationHostToContainer is available. However, the internals suggest otherwise; is always returned on Windows: Either the docs should be corrected, or the Kubelet should be updated, or we should have a comment on why this does in fact enable MountPropagationHostToContainer on Windows. /cc /sig windows
/cc
/cc
I think the doc is not accurate. The doc claims the same thing. For MountPropagationHostToContainer option, we can test it whether it is working or not.
i created two PRs to address the documentation gap. we will also test this and get back to this thread.
For 1.15 we may need to update Kubelet code to allow HostToContainer.
Change:
// Remove any cgroups in the hierarchy for pods that are no longer running. if kl.cgroupsPerQOS { <del> kl.cleanupOrphanedPodCgroups(cgroupPods, runningPods) </del> <ins> kl.cleanupOrphanedPodCgroups(cgroupPods, activePods) </ins> } kl.backOff.GC()

Discussion:
https://k8s- Only one green run out of the past 11 runs. Potential offenders: /cc (saw you guys discussed this on sig-node slack)
Related test failures: , ,
assigning this to you. and I can help out if necessary.
Still not sure what's going on. In 1 downward api modification failure, I saw a pod created, container started, container killed 1 second later by the kubelet, when it's supposed to run for 120s. Very strange.
See e.g.
So far I've only found the volume tests failing in the ubuntu trusty docker 1.10 vms. Not sure if that's 100% of them or just what I've looked at so far.
One idea is that cgroups are cleaned up before the pod is started, and that somehow causes the pod to fail. See . I'll try to verify my theory later...
That's consistent with my observation. Ubuntu+docker 1.10 seems to be the only one failing. If anyone wants to try reproducing this locally, this would be the image to use.
I noticed that too. The "pod ran to completion" is "pod started and immediately exited". I've tried to reproduce locally and can't find a commit around last Wednesday that obviously would have caused this. I'll post any information I find here.
I tried to reproduce locally (not on GCE) with trusty & docker 1.10 but the tests are all passing so far. Either I didn't wait long enough or it's something specific to the GCE trusty image being used.
-- i am not sure how that is possible. the odd bit to me is we ran w/ pod cgroups on in node e2e since 1.5 if i am not mistaken.
-- ignore my previous comment as previously we only deleted the cgroup when the pod was removed from the api server, and not just terminated. so yeah, its possible something is happening here...
maybe we need to pass in both activePods and runningPods to get a more accurate listing?
see from . Search for pod , which has cgroups cleaned up within 2 seconds of starting. May not be the culplit, but its worth looking into.

the runningPods cache appears like it could have a 2 second latency before updating its cache so it could be related and could be helped by passing in activePods as well...
see:
That is possible. I am also not sure when a pod is considered running, and in what order pods are created. Do we create cgroups before starting the container? Would a pod be returned by GetPods (from above comment) if it had cgroups set up, but the container wasn't running yet? It could also simply be that we are cleaning up a pod's cgroups before it is ever running (if that is possible based on above questions).
-- we create the cgroup before the container is started, so I think we need to pass activePods. see:
Change:
filepath.Join("pod1", "volumes", "fake-plugin", "pvc-abcdef"), filepath.Join("pod2", "volumes", "fake-plugin", "pvc-abcdef"), }, <del> expectedVolumesNeedReportedInUse:    []string{"fake-plugin/pvc-abcdef", "fake-plugin/pvc-abcdef"}, </del> expectedVolumesNeedDevicePath:       []string{"fake-plugin/pvc-abcdef", "fake-plugin/pvc-abcdef"}, expectedVolumesFailedReconstruction: []string{}, verifyFunc: func(rcInstance *reconciler, fakePlugin *volumetesting.FakeVolumePlugin) error {

Discussion:
remove and was introduced in to fix This is to overcome the situation that volume is to DSW at first and then deleted before it is to ASW, which causes mounted volume neither in DSW nor ASW and won't execute unmount/detach: The reason the volume cannot be to ASW in time is , which is . However, there is another PR also solved the issue. What it did is to check whether ASW already has the volume before deleting it from DSW, this makes sure that volume can be detached/unmounted after it is deleted from DSW. I suggest that we can keep the second solution and remove related code to make the reconstruction process and reconcile loop cleaner?
/sig storage
cc
Should I proceed with this issue? Your guidance is appreciated.
I think we'd better wait for the feedback from
cc
Sorry for a late reply. This is how behind we are with reviews :-(. Reading Now that is on by default, it reconstructs volumes first and always puts them to ASW, it should never happen that a reconstructed volume is in DSW and not in ASW, right? So we can remove easily. I would not be so sure without , because the code is 5 years old and who knows all the implications. You could be right though, it may not be necessary there too.
/triage accepted
/assign
Change:
} // UnstructuredContent returns a map contain an overlay of the Items field onto <del> // the Object field. Items always overwrites overlay. Changing "items" in the // returned object will affect items in the underlying Items field, but changing // the "items" slice itself will have no effect. // TODO: expose SetUnstructuredContent on runtime.Unstructured that allows // items to be changed. </del> <ins> // the Object field. Items always overwrites overlay. </ins> func (u *UnstructuredList) UnstructuredContent() map[string]interface{} { <del> out := u.Object if out == nil { out = make(map[string]interface{}) </del> <ins> out := make(map[string]interface{}, len(u.Object)+1) // shallow copy every property for k, v := range u.Object { out[k] = v </ins> } items := make([]interface{}, len(u.Items)) for i, item := range u.Items { <del> items[i] = item.Object </del> <ins> items[i] = item.UnstructuredContent() </ins> } out["items"] = items return out

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:
func (c *fakeConnection) CreateStream(headers http.Header) (httpstream.Stream, error) { switch headers.Get(v1.StreamType) { case v1.StreamTypeData: <ins> c.streamCount++ </ins> return c.dataStream, nil case v1.StreamTypeError: <ins> c.streamCount++ </ins> return c.errorStream, nil default: return nil, fmt.Errorf("fakeStream creation not supported for stream type %s", headers.Get(v1.StreamType))

Discussion:
The port forwarding client leaks memory when a port forwarding session is reused over time. The port forwarder client should not leak memory. forwarding a port with kubectl. and close many connections to the forwarded port. The amount of memory leaked for each connection is quite small, so many connections are needed to observe the leak. This is related to , which was reported for the kubelet and fixed in . However, the same problem happens to the client. The client needs to call on the , otherwise the streams created by will be kept in memory until the port forwarder itself is closed, even if the streams themselves closed long before. <details</details<detailsN/A </details<details</details<details</details<details</details<details</details
/sig api-machinery
/cc /triage accepted
/cc
Change:
}, { name: "The pod has a toleration that key and value don't match the taint on the node, " + <del> "but the effect of taint on node is PreferNochedule. Pod can be scheduled onto the node", </del> <ins> "but the effect of taint on node is PreferNoSchedule. Pod can be scheduled onto the node", </ins> pod:  podWithTolerations("pod1", []v1.Toleration{{Key: "dedicated", Operator: "Equal", Value: "user2", Effect: "NoSchedule"}}), node: nodeWithTaints("nodeA", []v1.Taint{{Key: "dedicated", Value: "user1", Effect: "PreferNoSchedule"}}), }, { name: "The pod has no toleration, " + <del> "but the effect of taint on node is PreferNochedule. Pod can be scheduled onto the node", </del> <ins> "but the effect of taint on node is PreferNoSchedule. Pod can be scheduled onto the node", </ins> pod:  podWithTolerations("pod1", []v1.Toleration{}), node: nodeWithTaints("nodeA", []v1.Taint{{Key: "dedicated", Value: "user1", Effect: "PreferNoSchedule"}}), },

Discussion:
When trying to see why pods don't start using either kubectl get events or kubectl describe pod , the base message is not detailed enough. Warning FailedScheduling 5s (x4 over 65s) default-scheduler 0/1 nodes are available: 1 node(s) had taints that the pod didn't tolerate. What would you like to be : Details of the taint and details of what it didn't tolerate Why is this needed: To get much much better debug information by default when trying to understand why pods can't launch.
/sig cli
/sig scheduling /priority important-longterm
/cc
/remove-sig cli
Those labels are not set on the issue: <detailsIn response to : /remove-sig cli </details
/good-first-issue
/assign starizard
Can I get an idea of what this would involve? I might be able to put some work on it.
I assume is taking this already. The error message is produced in We probably also require changes in to get the name of the missing toleration.
/remove-help
Change:
framework.Logf("Namespace %q now has labels, %#v", ns, updatedNamespace.Labels) }) <del> ginkgo.It("should apply a finalizer to a Namespace", func() { </del> <ins> /* Release: v1.26 Testname: Namespace, apply finalizer to a namespace Description: Attempt to create a Namespace which MUST be succeed. Updating the namespace with a fake finalizer MUST succeed. The fake finalizer MUST be found. Removing the fake finalizer from the namespace MUST succeed and MUST NOT be found. */ framework.ConformanceIt("should apply a finalizer to a Namespace", func() { </ins> fakeFinalizer := v1.FinalizerName("e2e.example.com/fakeFinalizer") var updatedNamespace *v1.Namespace

Discussion:
[X] Test approval issue: [X] Test PR: 15 Oct 2022 [X] Two weeks soak end date: 28 Oct 2022 [X] Test promotion PR: According to this APIsnoop query, there are still one remaining Namespace endpoint which is untested. replaceCoreV1NamespaceFinalize Note: The test also removes the fake finalize from before calling the finalize action on the test namespace a second time. This will allow the test framework to clean up all namespaces when the e2e finishes, else the test namespace will be stuck in the state. Using a number of existing e2e test practices a new has been created for one Namespace endpoint. The e2e logs for this test are listed below. This query shows that the Finalize endpoint is hit within a short period of running this e2e test If a test with these calls gets merged, test coverage will go up by 1 point This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
return &cinderVolumeMounter{ cinderVolume: &cinderVolume{ <del> podUID:  podUID, volName: spec.Name(), pdName:  pdName, mounter: mounter, manager: manager, plugin:  plugin, </del> <ins> podUID:          podUID, volName:         spec.Name(), pdName:          pdName, mounter:         mounter, manager:         manager, plugin:          plugin, MetricsProvider: volume.NewMetricsStatFS(getPath(podUID, spec.Name(), plugin.host)), </ins> }, fsType:             fsType, readOnly:           readOnly,

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: BUG /kind bug What happened: I am trying to get metrics working. According this there should be support after 1.8 kube. However, I am now using kube 1.10.1 and still I cannot see anything in ? Should these be there or not? What you expected to happen: I except that kubelet should expose prometheus metrics to /metrics path as well. Then it is easy to read with prometheus. How to reproduce it (as minimally and precisely as possible): Create new cinder volume, attach it to pod and try to query result from in kubelet Environment: Kubernetes version (use ): 1.10.1 Cloud provider or hardware configuration: openstack OS (e.g. from /etc/os-release): centos 7 Kernel (e.g. ): Install tools: Others:
cc
/sig storage
Prometheus metrics should be available on default port of Kubelet. Can you try ? If you are on a RBAC enabled cluster (such as openshift) you may have to use token or key to authenticate for fetching metrics.
returns many metrics but there is not things. There is one pod which have cinder volume attached running in that node. So there should be some metrics right?
It appears that Cinder volume plugin does not implement metric interface necessary for getting those stat metrics - This seems like an oversight and is fairly easy to fix. I can help getting the PR merged if you can open it.
/sig openstack
Kubernetes v1.19.16 there is no kubelet_volume* metrics in //metrics how to fix it???
Change:
rm -rf "${release_stage}" mkdir -p "${release_stage}" <del> cp -R "${LOCAL_OUTPUT_BINPATH}" "${release_stage}/platforms" </del> <ins> # Copy all of the client binaries in here, but not test or server binaries. # The server binaries are included with the server binary tarball. local platform for platform in "${KUBE_CLIENT_PLATFORMS[@]}"; do mkdir -p "${release_stage}/platforms/${platform}" cp "${KUBE_CLIENT_BINARIES[@]/#/${LOCAL_OUTPUT_BINPATH}/${platform}/}"  "${release_stage}/platforms/${platform}" done </ins> # We want everything in /cluster except saltbase.  That is only needed on the # server.

Discussion:
Currently the master VM specified by the Vagrantfile does not have the built kubecfg binary in the vagrant user's path. This request is to have this binary present on the host system and in the vagrant user's path so I can Vagrant ssh into the machine and do 'kubecfg list pods'.
I'm going to generalize this a little so that kubecfg is available in our general cluster install scripts. This should be easier as we move to binary installs.
Should be kubectl, not kubecfg, but otherwise is a good idea. etcd tools would be useful, too:
I'll take this on if no one else wants to do it. May take me a day or two to get to it.
Thinking out loud here... do we really want to encourage people to do admin and/or job runny stuff on their master?
I see it as a debugging tool.
Change:
newCustomResource := newCustomResourceObject.UnstructuredContent() status, ok := newCustomResource["status"] <ins> // managedFields must be preserved since it's been modified to // track changed fields in the status update. managedFields := newCustomResourceObject.GetManagedFields() </ins> // copy old object into new object oldCustomResourceObject := old.(*unstructured.Unstructured) // overridding the resourceVersion in metadata is safe here, we have already checked that

Discussion:
What happened: I've performed server-side apply on the subresource. e.g. The request body is the following for example: The CRD itself has status commonly defined as: in the resulting openAPIv3 validation the correct object annotations are set for listType & listMapKey (thanks to controler-gen v0.2.5) What you expected to happen: The patch is applied to the status subresource, and the is properly set. However, one of two things happens: if the status subfield conditions don't exist the request passes through and properly sets the field. But the isn't set if the specific status condition type exits the request fails with 409 Conflict. It conflicts with other managers, e.g. since the is empty. if the exist beforehand for the status subresource, they are cleared after server-side apply on the subresource and become empty. Anything else we need to know?: This is similar to Also somewhat related to Environment: Kubernetes version (use ):
/wg apply
/sig api-machinery
thanks for the detailed post, you're absolutely right that this is related to the two issues that you mentioned. I don't see how we would be able to fix this in 1.18 or any version before that, we're planning on fixing it in 1.19. We should probably update the documentation to mention that this doesn't work for sub-resources, and maybe even disable it altogether for sub-resources.
I'd rather have it working...buggily(that is via ) than having it disabled altogether.
We trying to find out what this doesn’t work and see if we can back port the fix. We’ll keep you posted, thanks!
I can't reproduce this bug right now, would you mind sharing the CRD and exact reproduction steps?
Sure. The server-side application I've investigated in This is the CRD definition: my experimentations are in on line I've changed whether I've used force or not. The raw HTTP req/resp should be written to the output due to
Let me know if there's anything more I can do to help.
The strategy overriding the metadata in status updates of CRD and CR objects seems like it would definitely cause this. were you able to follow the steps at
Change:
<ins> Copyright (c) 2012 The Go Authors. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither the name of Google Inc. nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. </ins>

Discussion:
we have one in k/k and one in k/utils, both need to be in LICENSES /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
/area code-organization
I think we should include anything matching the LICENSE/COPYRIGHT/COPYING patthers under or subdirs in k/k or dependencies... a quick sweep showed these:
/sig release ?
Change:
} func (ssu *fakeStatefulSetStatusUpdater) UpdateStatefulSetStatus(ctx context.Context, set *apps.StatefulSet, status *apps.StatefulSetStatus) error { <del> defer ssu.updateStatusTracker.inc() if ssu.updateStatusTracker.errorReady() { defer ssu.updateStatusTracker.reset() return ssu.updateStatusTracker.err </del> <ins> defer ssu.updateStatusTracker.trackParallelRequests() if err := ssu.updateStatusTracker.incWithOptionalError(); err != nil { return err </ins> } set.Status = *status ssu.setsIndexer.Update(set)

Discussion:
https://prow.ppc64le- TestStatefulSetControl/CreatePodFailure/Burst/ScaleDownOnly/StatefulSetAutoDeletePVCEnabled of Have started observing more flakes recently since last week. No response_ Able to reproduce using stress tool. /sig testing /sig apps
/triage accepted /assign
opened a PR with a fix: