jiebi/CodeConvo huggingface dataset:
Change:
store.BeginCreate = genericStore.beginCreate store.BeginUpdate = genericStore.beginUpdate <ins> // users can patch the status to remove the finalizer, // hence statusStore must participate on the AfterDelete // hook to release the allocated resources statusStore.AfterDelete = genericStore.afterDelete </ins> return genericStore, &StatusREST{store: &statusStore}, &svcreg.ProxyREST{Redirector: genericStore, ProxyTransport: proxyTransport}, nil }

Discussion:
Why PatchService method is used for deleting finalizers in cloud-controller-manager, This method updates with service/status, It seems to go unnoticed by the API server, resulting in the API server being unaware when the finalizer field on the service is deleted, leading to a delay in the release of service-related NodePorts. service nodeport be released promptly when service is deleted. create a loadblancer service with nodeport seted,then delete it and recreate. cloud-controller-manager add a finalizer on service. delete this service and then cloud-controller remove finalizer. but nodeport is not released when service deleted. ref i change like this, it seems like releasing nodeport when service is deleted : No response <details</details<details</details<details</details<details</details<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 cloud-provider
Are you sure? that method updates the status and remove the finalizer ... otherwise , who removes the finalizer?
I apologize for any confusion. What I meant was that the update of the status and the removal of the finalizer are performed through updating service/status. Therefore, removing the finalizer does not release resources.It seems like removal of the finalizer by service/status, store.AfterDelete is nil. i think remove the finalizer should by patch servcie and updates the status should by patch service/status.Now we patch both by servcie/status.
no need to apologize, let me see if I can reproduce this locally first, Services api allocation is complex , it overrides the standard AfterDelete and release all allocated resources there /assign
/sig network ack the problem
will look for a possibly-related past cloud provider issue.
this will be fixed by , it is a problem in the apiserver logic
Cool! I forgot that you can patch finalizers thru /status. I repro'ed it on both ClusterIP and NodePort.

Saw this in the logs: So the repair loop, yet again, saves our butt but also hides a bug.
we need metrics here about to have visibility of the repairs
I also found this problem in versions 1.23 and 1.27
yep, I started the backports , but we can only backport to the supported versions, 1.23 and 1.24 are EOL
Change:
for _, pv := range item.pvs { client.CoreV1().PersistentVolumes().Create(ctx, pv, metav1.CreateOptions{}) } <del> caches := informerFactory.WaitForCacheSync(ctx.Done()) for _, synced := range caches { if !synced { t.Errorf("error waiting for informer cache sync") } } // Verify </del> <ins> t.Log("Start informer factory after initialization") informerFactory.Start(ctx.Done()) t.Log("Wait for all started informers' cache were synced") informerFactory.WaitForCacheSync(ctx.Done()) t.Log("Verify") </ins> p := pl.(*VolumeBinding) nodeInfo := framework.NewNodeInfo() nodeInfo.SetNode(item.node) state := framework.NewCycleState() <del> t.Logf("call PreFilter and check status") </del> <ins> t.Logf("Verify: call PreFilter and check status") </ins> gotPreFilterStatus := p.PreFilter(ctx, state, item.pod) if !reflect.DeepEqual(gotPreFilterStatus, item.wantPreFilterStatus) { t.Errorf("filter prefilter status does not match: %v, want: %v", gotPreFilterStatus, item.wantPreFilterStatus)

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: The unit test Which test(s) are flaking: Testgrid link: Reason for failure: In volume scheduling, we maintain internal caches that watch for PV/PVC events. However, we don't have a method to wait for them to be synced in UT. When the cache in the informer factory is synced but the execution of registered handlers may not finish. <!-- In production, this is not a problem. Even if the scheduler marks the pod uncacheable due to the stale cache in PVAssumeCache/PVCAssumeCache, the pod will be moved to the active queue later as the scheduler . related: --Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated
/sig scheduling /sig storage
Even if I check the PV/PVC assume cache and wait for PV/PVC objects to be into the cache, the PV/PVC objects may not be . It seems that the shared informer with the fake client has a bug that registered event handlers may not be called (or handlers are not registered successfully).
The share informer with the fake client may miss events of objects which are created before caches are synced. it's better to create testing objects before starting the informers
Although the event handlers may not finish when the caches were synced in theory, however, it seems it's not necessary to wait for PV/PVC assume cache to be synced practically. I've run a thousand times (parallel: 10) with locally and no failures.
Change:
expected: &dockercontainer.HostConfig{ NetworkMode: dockercontainer.NetworkMode(sandboxNSMode), IpcMode:     dockercontainer.IpcMode(sandboxNSMode), <ins> PidMode:     namespaceModeHost, </ins> }, }, }

Discussion:
Kubernetes version (use ): 1, 1.6.0 (both run into this issue) Environment: Cloud provider or hardware configuration: VirtualBox 5.1.18 VM OS: 16.04.2 LTS (Xenial Xerus) Kernel: Install tools: kubeadm What happened: A pod scheduled using hostPID wasn't using the host's PID namespace. I've investigated this issue together with What you expected to happen: I expected in the Docker container's config. Instead, the scheduled pod's container had How to reproduce it: Use this config to get a pod running a Docker container: Use on the running container and check whether PidMode is set to host or not. Anything else we need to know*: This was working properly on Kubernetes 1.5.3.
doesn't look like you've specified Docker version, it may be crucial here.
I've tested this with Docker 17.03.1-ce and can confirm that it's the case for pods.
It was Docker 1.12.6 from what I know. I'll check again to be sure it was 1.12.6 and update the post.
Is this with the CRI? If you disable the CRI do you get the desired outcome?
I don't know if that's enabled by default. I've noticed that hostPID doesn't work as it should with Docker. I'm not familiar with CRI.
I'll test with .
With CRI disabled it doesn't work on Docker 17.03, simply because it doesn't like the new versioning scheme. it'd be really great if you can try setting in your , e.g. by modifying (will need to do , and after that you either reinitialise the cluster or kill all the pods).
Seems a bug of kuberuntime, will file a PR to fix this.
Filed for this.
Reoppened this issue to ensure we cherrypick the fix to the 1.6 branch
has been merged to the release-1.6 branch. From what has been discussed so far, this will make it to Kubernetes 1.6.2. I'll close this issue now.
Can anyone help how this issue is fixed? I tried with pidMode: host but it is failing. I am using i.11 version.
I found it --hostPID: true
Change:
"fmt" "math" "reflect" <del> "sync" </del> "testing" "github.com/google/go-cmp/cmp" dto "github.com/prometheus/client_model/go" "k8s.io/component-base/metrics" <del> "k8s.io/component-base/metrics/legacyregistry" </del> "k8s.io/utils/pointer" )

Discussion:
TestRecordOperation TestRecordOperation TestGetHistogramVecFromGatherer /kind failing-test <!-- If this is a flake, please add: /kind flake --<!-- Please assign a SIG using: /sig SIG-NAME --/sig testing This may be related with 
/assign I will do some initial researches on this. is similar
/sig instrument
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig instrument 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
/sig instrumentation
/triage accepted /assign cc
To fix it gracefully, we may refactor the code in like The refactor would change a lot and need some confirmations or demo.(I prefer) A temporary workaround before refactoring it: is another try to ignore the dup error in but it is odd as should panic as designed if one register failed.
Three testings failed due to . Haven't found package promauto () being used in these testings. It might be other issues. These testings are: /filterwithonelabel
What are you guys doing here? What test is this? You cannot change the component-base metrics code base it is doing what it is supposed to be doing. Does this test suite involve multiple sequential runs of the same test?
I think this is odd to change the component-base metrics code base. But the refactor to use is another approach. You can try to reproduce it with is with
Oh, yes. This involves multiple sequential runs of the same test to . It uses 
You can use to register the registry only once. It is important to reset the metrics, or next iteration in the test will fail
Thanks I other fixes in
Change:
"github.com/spf13/pflag" "k8s.io/apimachinery/pkg/util/duration" <ins> "k8s.io/klog/v2" </ins> kubeadmapi "k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm" kubeadmscheme "k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/scheme"

Discussion:
When is set to a value other than the default value (/etc/kubernetes/pki/), and run on the working kubernetes controller node, the cert is not renewed as expected. This impacts the as well. or work as expected. Here is an example which show cert renew doesn't work, create a cert,and then renew the cert,check if the cert is renewed, It actually renewed the cert in the default path(/etc/kubernetes/pki/), The issue can be revealed by the test as well, NOTE This issue only exist with a working cluster since the code will fall back to use the cluster configuration when config file is not specified. And if the cluster cannot be connected with the , the will be honored, this is why the test can pass with the CI jobs. Check the log printed by this test pr: No response <details</details<detailslocal </details<details</details<details</details<details</details<details</details
/assign
/sig cluster-lifecycle
/area kubeadm
/triage accepted
Change:
# Disable prompts from apt. ENV DEBIAN_FRONTEND noninteractive <del> # Install prerequisites. RUN apt-get update &&  apt-get install -y -q curl make g++ &&  apt-get clean &&  rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* # Install Fluentd. RUN /usr/bin/curl -L https://td-toolbelt.herokuapp.com/sh/install-ubuntu-trusty-td-agent2.sh | sh # Change the default user and group to root. # Needed to allow access to /var/log/docker/... files. RUN sed -i -e "s/USER=td-agent/USER=root/" -e "s/GROUP=td-agent/GROUP=root/" /etc/init.d/td-agent # Install the Elasticsearch Fluentd plug-in. RUN td-agent-gem install fluent-plugin-kubernetes_metadata_filter fluent-plugin-elasticsearch </del> # Copy the Fluentd configuration file. COPY td-agent.conf /etc/td-agent/td-agent.conf <ins> COPY build.sh /tmp/build.sh RUN /tmp/build.sh </ins> # Run the Fluentd service. ENTRYPOINT ["td-agent"]

Discussion:
It's 400+mb and we need to pull it on every node. This leads to a lot of image pulling flake (), and also gets very expensive in some countries where bandwidth is sold at a premium. We took a stab at halving the size with: , but then realized that we were using an unsupported base image We tried to optimize to ~300Mb by building a smaller ubuntu:15 base, but that's still huge. Every other mandatory system daemon is built on busybox and so takes ~10Mb.
I can try again now that the agent supports
Newer Docker images using the spec from the official repository are based on AlpineLinux and are around ~38MB:
Change:
continue fi <del> echo "Deleting security group: ${sg_id}" $AWS_CMD delete-security-group --group-id ${sg_id} > $LOG </del> <ins> delete_security_group ${sg_id} </ins> done subnet_ids=$($AWS_CMD describe-subnets 

Discussion:
See example log below. I'm pretty sure the SG in question was from an ELB, but we should just auto-retry anyway.
Change:
namespace := nsObj.(*api.Namespace) <ins> // Ensure we have a UID precondition if options == nil { options = api.NewDeleteOptions(0) } if options.Preconditions == nil { options.Preconditions = &api.Preconditions{} } if options.Preconditions.UID == nil { options.Preconditions.UID = &namespace.UID } else if *options.Preconditions.UID != namespace.UID { err = apierrors.NewConflict( api.Resource("namespaces"), name, fmt.Errorf("Precondition failed: UID in precondition: %v, UID in object meta: %v", *options.Preconditions.UID, namespace.UID), ) return nil, err } </ins> // upon first request to delete, we switch the phase to start namespace termination <ins> // TODO: enhance graceful deletion's calls to DeleteStrategy to allow phase change and finalizer patterns </ins> if namespace.DeletionTimestamp.IsZero() { <del> now := unversioned.Now() namespace.DeletionTimestamp = &now namespace.Status.Phase = api.NamespaceTerminating result, _, err := r.status.Update(ctx, namespace) return result, err </del> <ins> key, err := r.Store.KeyFunc(ctx, name) if err != nil { return nil, err } preconditions := storage.Preconditions{UID: options.Preconditions.UID} out := r.Store.NewFunc() err = r.Store.Storage.GuaranteedUpdate( ctx, key, out, false, &preconditions, storage.SimpleUpdate(func(existing runtime.Object) (runtime.Object, error) { existingNamespace, ok := existing.(*api.Namespace) if !ok { // wrong type return nil, fmt.Errorf("expected *api.Namespace, got %v", existing) } // Set the deletion timestamp if needed if existingNamespace.DeletionTimestamp.IsZero() { now := unversioned.Now() existingNamespace.DeletionTimestamp = &now } // Set the namespace phase to terminating, if needed if existingNamespace.Status.Phase != api.NamespaceTerminating { existingNamespace.Status.Phase = api.NamespaceTerminating } return existingNamespace, nil }), ) if err != nil { err = storageerr.InterpretGetError(err, api.Resource("namespaces"), name) err = storageerr.InterpretUpdateError(err, api.Resource("namespaces"), name) if _, ok := err.(*apierrors.StatusError); !ok { err = apierrors.NewInternalError(err) } return nil, err } return out, nil </ins> } // prior to final deletion, we must ensure that finalizers is empty

Discussion:
Honestly I'm not sure if this is a bug or a feature, but didn't expect it. Filing this to track.
I think it's a bug. Nothing in the code base depends on it that I can see (edit: namespace deletion does, but only via an in-server call which I'd like to see fixed), and we don't let other delete-related fields mutate during update (deleteGracePeriodSeconds)
Change:
} s.AddUnversionedTypes(gv, &InternalSimple{}) <ins> s.AddUnversionedTypes(gv, &InternalSimple{}) </ins> if len(s.KnownTypes(gv)) != 1 { t.Errorf("expected only one %v type after double registration with custom name", gv) }

Discussion:
We have moved to non-global schema in a number of places in 1.6 and 1.7. It is easy to forget registering the unversioned types like , leading to encoding errors in error cases. The registration of the unversioned types should be automatic as for the types, i.e. in .
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
do we need to close out this issue? (since referenced PR has merged)
Fixed by
Change:
}) /* <del> Testname: var-expansion-subpath-with-absolute-path Description: Make sure a container's subpath can not be set using an expansion of environment variables when absolute path is supplied. </del> <ins> Release : v1.19 Testname: VolumeSubpathEnvExpansion, subpath with absolute path Description: Make sure a container's subpath can not be set using an expansion of environment variables when absolute path is supplied. </ins> */ <del> ginkgo.It("should fail substituting values in a volume subpath with absolute path [sig-storage][Slow]", func() { </del> <ins> framework.ConformanceIt("should fail substituting values in a volume subpath with absolute path [sig-storage][Slow]", func() { </ins> podName := "var-expansion-" + string(uuid.NewUUID()) pod := &v1.Pod{

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind api-change /sig storage /sig node /sig testing Description: Promote e2e tests for VolumeSubpathEnvExpansion to Conformance as it is GA approved. Related Issues: GA Upgrade: Feature Request: KEP:
/assign
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 (detacher *fcDetacher) UnmountDevice(deviceMountPath string) error { <del> return volumeutil.UnmountPath(deviceMountPath, detacher.mounter) </del> <ins> // Specify device name for DetachDisk later devName, _, err := mount.GetDeviceNameFromMount(detacher.mounter, deviceMountPath) if err != nil { glog.Errorf("fc: failed to get device from mnt: %snError: %v", deviceMountPath, err) return err } // Unmount for deviceMountPath(=globalPDPath) err = volumeutil.UnmountPath(deviceMountPath, detacher.mounter) if err != nil { return fmt.Errorf("fc: failed to unmount: %snError: %v", deviceMountPath, err) } unMounter := volumeSpecToUnmounter(detacher.mounter) err = detacher.manager.DetachDisk(*unMounter, devName) if err != nil { return fmt.Errorf("fc: failed to detach disk: %snError: %v", devName, err) } glog.V(4).Infof("fc: successfully detached disk: %s", devName) return nil </ins> } func volumeSpecToMounter(spec *volume.Spec, host volume.VolumeHost) (*fcDiskMounter, error) {

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: When user uses fc volume plugin, device file on operating system such as /dev/sdX remains after deleting a Pod. After deleting the Pod, PVC and PV, cluster admin or external-provisioner might delete the disk from the storage, therefore the block device on the worker node should be cleaned up. The photon volume plugin already has this functionality in the removeFromScsiSubsystem(). Also the gce volume plugin has similar functionality in the udevadmChangeToDrive() too. photon: echo 1 /sys/block/<dev name/device/delete gce: udevadm trigger --action=change --property-match=DEVNAME=%s Also os-brick library in the OpenStack Cinder component uses same way with photon driver. What you expected to happen: The device file on operating system such as /dev/sdX will be cleaned up after deleting PVs. Environment: Kubernetes version (use ):Cloud provider or hardware configuration**: KVM OS (e.g. from /etc/os-release): Fedora 25 Kernel (e.g. ):Install tools: local-up- Others:
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 storage
I'll work on this.
Reiterating the mentions to trigger a notification: <detailsIn response to : I'll work on this. 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:
dbus = utildbus.New() iptInterface = utiliptables.New(execer, dbus, protocol) <del> ipvsInterface = utilipvs.New(execer) </del> kernelHandler = ipvs.NewLinuxKernelHandler() ipsetInterface = utilipset.New(execer) <ins> if canUse, _ := ipvs.CanUseIPVSProxier(kernelHandler, ipsetInterface); canUse { ipvsInterface = utilipvs.New(execer) } </ins> // We omit creation of pretty much everything if we run in cleanup mode if cleanupAndExit {

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?: What happened: kube proxy report following error even if ipvs not enabled. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Install kubernetes and start proxy. Anything else we need to know?: Environment: Kubernetes version (use ): We are using 1.9.1 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /cc comments?
/sig network
It's a noise, but it's thrown by libnetwork/ipvs util. Is that a big deal?
please take a look when you have a chance :)
Yes, it always bring noise for production when customer got warning messages. Why printing some ipvs message even it was not enabled?
/area ipvs
Change:
) func newTestDockerSevice() (*dockerService, *dockertools.FakeDockerClient, *clock.FakeClock) { <del> c := dockertools.NewFakeDockerClient() </del> fakeClock := clock.NewFakeClock(time.Time{}) <ins> c := dockertools.NewFakeDockerClientWithClock(fakeClock) </ins> return &dockerService{client: c}, c, fakeClock }

Discussion:
Another flake i found earlier yesterday, just linking to it for posterity, not blocking me right now. TestContainerStatus
Could you post some error log here? I can't reproduce it with stress test
Hm, got one reproduce:
Change:
<ins> package(default_visibility = ["//visibility:public"]) load( "@io_bazel_rules_go//go:def.bzl", "go_library", ) go_library( name = "go_default_library", srcs = ["metrics.go"], importpath = "k8s.io/kubernetes/pkg/kubelet/server/metrics", deps = [ "//vendor/github.com/prometheus/client_golang/prometheus:go_default_library", ], ) filegroup( name = "package-srcs", srcs = glob(["**"]), tags = ["automanaged"], visibility = ["//visibility:private"], ) filegroup( name = "all-srcs", srcs = [":package-srcs"], tags = ["automanaged"], ) </ins>

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : 1) add metrics into kubelet to monitor ; 2) add throttling to . Why is this needed: Kubelet provides lots of its functionalities through its http server, and currently there is no server-side monitoring and throttling mechanisms. Adding metrics into kubelet to monitor its http server will improve its observability and debuggability; adding throttling will prevent kubelet being overloaded from serving too many http requests.
/sig node