jiebi/CodeConvo huggingface dataset:
Change:
deleteRSTime := time.Now().Sub(startTime) Logf("Deleting RS %s took: %v", name, deleteRSTime) if err == nil { <del> err = waitForReplicaSetPodsGone(clientset, rc) </del> <ins> err = waitForReplicaSetPodsGone(clientset, rs) </ins> } terminatePodTime := time.Now().Sub(startTime) - deleteRSTime Logf("Terminating ReplicaSet %s pods took: %v", name, terminatePodTime)

Discussion:
As the title said, we need update touse server side reaper. xref:
/sig apps
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
/assign
Change:
fi fi <del> KUBE_ROOT_HASH=$(kube::build::short_hash "${HOSTNAME:-}:${KUBE_ROOT}") </del> <ins> KUBE_GIT_BRANCH=$(git symbolic-ref --short -q HEAD 2>/dev/null || true) KUBE_ROOT_HASH=$(kube::build::short_hash "${HOSTNAME:-}:${KUBE_ROOT}:${KUBE_GIT_BRANCH}") </ins> KUBE_BUILD_IMAGE_TAG_BASE="build-${KUBE_ROOT_HASH}" KUBE_BUILD_IMAGE_TAG="${KUBE_BUILD_IMAGE_TAG_BASE}-${KUBE_BUILD_IMAGE_VERSION}" KUBE_BUILD_IMAGE="${KUBE_BUILD_IMAGE_REPO}:${KUBE_BUILD_IMAGE_TAG}"

Discussion:
When I change branches, I really want the prior build invalidated. Could we consider the git branch (if this is a git repo) in the short_hash that uniquifies the build?
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 .
/sig testing ?
/remove-sig testing
/sig release (on the presumption that build lands there)
Change:
return instances.InstanceExistsByProviderID(ctx, providerID) } <del> func getNodeAddressesByProviderIDOrName(ctx context.Context, instances cloudprovider.Instances, node *v1.Node) ([]v1.NodeAddress, error) { nodeAddresses, err := instances.NodeAddressesByProviderID(ctx, node.Spec.ProviderID) </del> <ins> func getNodeAddressesByProviderIDOrName(ctx context.Context, instances cloudprovider.Instances, providerID, nodeName string) ([]v1.NodeAddress, error) { nodeAddresses, err := instances.NodeAddressesByProviderID(ctx, providerID) </ins> if err != nil { providerIDErr := err <del> nodeAddresses, err = instances.NodeAddresses(ctx, types.NodeName(node.Name)) </del> <ins> nodeAddresses, err = instances.NodeAddresses(ctx, types.NodeName(nodeName)) </ins> if err != nil { return nil, fmt.Errorf("error fetching node by provider ID: %v, and error by node name: %v", providerIDErr, err) }

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: introduces a regression that func is invoked on a Node obj without , hence it can fail fetching the node addresses when the is not set. What you expected to happen: I would expect cloud-controller-manager to be able to initialize new Node. How to reproduce it (as minimally and precisely as possible): the gcp legacy-cloud-controller v1.18.1 () that the node-controller cannot initialize a new Node. Logs of the cloud-controller-manager repeated multiple times: Ensure that the Node is with the taint. Ensure that the of the Node is not set. The cloud-controller-manager is not running on the host machine and that's why it cannot call the gce matadata. But it was never a hard requirement for cloud-controller-manager to run on the host machine. Anything else we need to know?: The legacy cloud-controller-manager v1.17.x is working perfectly fine. Environment: Kubernetes version (use ):v1.18.1 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:
/sig cloud-provider /kind regression
/cc
can we open a new issue re:
Change:
func AddFlags(options *Options, fs *pflag.FlagSet) { fs.StringVar(&options.ConfigFile, "config", options.ConfigFile, "The path to the configuration file.") fs.StringVar(&options.WriteConfigTo, "write-config-to", options.WriteConfigTo, "If set, write the default configuration values to this file and exit.") <del> fs.BoolVar(&options.CleanupAndExit, "cleanup-iptables", options.CleanupAndExit, "If true cleanup iptables rules and exit.") </del> <ins> fs.BoolVar(&options.CleanupAndExit, "cleanup-iptables", options.CleanupAndExit, "If true, cleanup iptables rules and exit.") </ins> // All flags below here are deprecated and will eventually be removed.

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?: bug What happened: Got panic after running: Panic: What you expected to happen: No panic and exit successfully. How to reproduce it (as minimally and precisely as possible): Run the following command on both CoreOS v1298.7.0(bare metal) and Ubuntu 16.04.2 LTS(OpenStack) Happened with the following versions: v1.7.0-alpha.3 v1.7.0-alpha.4 v1.7.0-beta.0 v1.7.0-beta.1 v1.7.0-beta.2 v1.7.0-rc.1 v1.8.0-alpha.0 v1.8.0-alpha.1 Anything else we need to know?: I guess it caused by . Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Both CoreOS v1298.7.0(bare metal) and Ubuntu 16.04.2 LTS(OpenStack) Kernel (e.g. ): CoreOS v1298.7.0: Linux node- 4.9.16-coreos-r1 SMP Tue Apr 4 19:09:38 UTC 2017 x8664 Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz GenuineIntel GNU/Linux Ubuntu 16.04.2 LTS: Linux ubuntu- 4.4.0-62-generic -Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: Others:
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
/sig network /area kube-proxy
/cc
cc/ Looks like there is a new regression in v1.7. Please triage this to decide if it is a release blocker. If not, please provide the workaround for the users. Thanks!

cc/
Digging into the code, will send a PR.
PR sent. Folks review it please.
Added the release-blocker label. We got a PR for it very fast so it won't delay the release anyway, thanks
Change:
cpus := m.state.GetCPUSetOrDefault(containerID) m.Unlock() <del> err = m.updateContainerCPUSet(containerID, cpus) if err != nil { glog.Errorf("[cpumanager] AddContainer error: %v", err) return err </del> <ins> if !cpus.IsEmpty() { err = m.updateContainerCPUSet(containerID, cpus) if err != nil { glog.Errorf("[cpumanager] AddContainer error: %v", err) return err } } else { glog.V(5).Infof("[cpumanager] update container resources is skipped due to cpu set is empty") </ins> } return nil }

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: There will always be extra UpdateContainerResources CRI call even when cpu set is empty. This is unneeded. What you expected to happen: Only call UpdateContainerResources when cpu set is set. 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:
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 node
Change:
__salt__['cmd.run']( 'ip link set dev {0} up'.format(name)) new_state = get_current_state() <del> if not new_state['iptables_rule_exists']: __salt__['iptables.append'](**iptables_rule) </del> <ins> if not new_state['iptables_rule_1_exists']: __salt__['iptables.append'](**iptables_rule_1) if not new_state['iptables_rule_2_exists']: __salt__['iptables.append'](**iptables_rule_2) </ins> new_state = get_current_state() ret['comment'] = 'The state of "{0}" was changed!'.format(name)

Discussion:
Spin up a cluster. Create a container on each of two machines. Try to ping each other's IPs. No love. It seems we need an extra iptables rule. For example, for a minion with the 10.244.2.0/24 subnet assigned, we need: iptables -t nat -A POSTROUTING -s 10.244.2.0/24 ! -d 10.244.2.0/24 -j MASQUERADE
Hrm, I can't repro this. I tried: ping 10.244.2.1 from a different kubernetes VM and it worked. (or do you mean from inside a container?)
From within a container to another container
repro'ed it for me, too.
Is this just ping? Or is this any network traffic? , Tim Hockin wrote:
Any traffic - the kernel is not masquerading it because our iptables magic doesn't match packets coming from inside a container on a veth. I saw this while trying to do another round of perf tests.
Change:
- [ 'chroot', '{root}', '/bin/sh', '-c', 'DEBIAN_FRONTEND=noninteractive dpkg --install /tmp/docker.deb' ] - [ 'rm', '{root}/tmp/docker.deb' ] <ins> # Fix a cloud-init bug where it uses nobootwait # see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=789884 - [ 'chroot', '{root}', '/bin/sh', '-c', 'echo "mount_default_fields: [~, ~, ''auto'', ''defaults,nofail'', ''0'', ''2'']" > /etc/cloud/cloud.cfg.d/99_kubernetes.cfg' ] </ins> # We perform a full replacement of some grub conf variables: #   GRUB_CMDLINE_LINUX_DEFAULT (add memory cgroup) #   GRUB_TIMEOUT (remove boot delay)

Discussion:
Master failed to restart on Debian Jessie. Console logs showed: I have no idea where nobootwait is coming from though...
Aha... it's a bug in jessie's cloud-init. I have a fix, will produce a PR once verified.
Fix in
Change:
cloud := &fake_cloud.FakeCloud{} cloud.Region = region client := &testclient.Fake{} <del> controller := New(cloud, client, clusterName) </del> <ins> controller := New(cloud, client, "test-cluster") </ins> controller.init() cloud.Calls = nil    // ignore any cloud calls made in init() client.Actions = nil // ignore any client calls made in init()

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:
podsDir string) (volumetypes.GeneratedOperations, error) { var pluginName string <del> if useCSIPlugin(og.volumePluginMgr, volumeToUnmount.VolumeSpec) { </del> <ins> if volumeToUnmount.VolumeSpec != nil && useCSIPlugin(og.volumePluginMgr, volumeToUnmount.VolumeSpec) { </ins> pluginName = csi.CSIPluginName } else { pluginName = volumeToUnmount.PluginName

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce-serial Which test(s) are failing: LocalVolumeType: gce-localssd-scsi-fs Since when has it been failing: 2/20 Testgrid link: Reason for failure: unsure yet /assign
After , there are still two failing tests: For the first one, looks like reconstruction is not correctly implemented for local PVs: to check if it's ok for mounter to be initialized with an empty path the panic in the operation_generator
cc Unsure why it's failing only for this local pv type (real disk vs loopback block) I have not investigated the 2nd test yet
/priority critical-urgent /milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect
/assign
hi, checked , after , "should be mountable" has been fixed. failing test is "should unmount if pod is force deleted while kubelet is down [Disruptive][Slow]" and it fails for all kinds of local volume types
This is because local volume cannot be reconstructed for now (localPlugin.NewMounter requires field is set), so is going to . But uses to , and , so it panics here. I'm not sure how to support reconstruction for local volumes correctly yet. But we can fix this panic first, then reconciler will clean up the existing mount points if the volume is no longer needed. IIUC, this will fix this failing test. After this is fixed, if necessary we can revisit how to reconstruct local volumes correctly.
I see similar failures in and too; are they connected? cc
yes they should be similar
need to keep track of this to see if failures in and also clear up.
The tests are still throwing s in (it's the job there though). I've opened to track the failures in 1.14-blocking. They also seem to not have run since the 24th, I'll look into that in the meantime
Change:
Returns a JSON with the fields `output` (containing the file's name on the server) and `error` containing any potential server side errors. <ins> If `--tls-cert-file` is added (ideally in conjunction with `--tls-private-key-file`, the HTTP server will be upgraded to HTTPS. The image has default, `localhost`-based cert/privkey files at `/localhost.crt` and `/localhost.key` (see: [`porter` subcommand](#porter)) </ins> It will also start a UDP server on the indicated UDP port that responds to the following commands: - `hostname`: Returns the server's hostname

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : The image used in E2E tests is used for testing a wide variety of OS-agnostic features. One of these is , which runs an HTTP server with various endpoints that can be used to validate things like request/response. It would be useful to allow for 's functionality to also support HTTPS so all of that logic can be tested for TLS-based traffic. Currently, can be run like: I'm proposing something along the lines of: The default certificate/private key being basically identical to what provides. Why is this needed: One use case is where the intent is to add HTTPS functionality to lifecycle hooks (postStart/preStop). There is currently no easy way to test this logic because the container which receives the HTTPS request (in this case, ) does not support HTTPS traffic.
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
/sig testing
Change:
} } <ins> func TestResizeController(t *testing.T) { fakeClient := FakeKubeClient{} name := "name" replicas := 17 ResizeController(name, replicas, &fakeClient) if len(fakeClient.actions) != 2 { t.Errorf("Unexpected actions: %#v", fakeClient.actions) } if fakeClient.actions[0].action != "get-controller" || fakeClient.actions[0].value.(string) != name { t.Errorf("Unexpected action: %#v", fakeClient.actions[0]) } controller := fakeClient.actions[1].value.(ReplicationController) if fakeClient.actions[1].action != "update-controller" || controller.DesiredState.Replicas != 17 { t.Errorf("Unexpected action: %#v", fakeClient.actions[1]) } } </ins> func TestCloudCfgDeleteController(t *testing.T) { fakeClient := FakeKubeClient{} name := "name"

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): HEAD (latest) Environment: dind What happened: Enpoints object is constantly getting updated every 2 seconds, even though nothing has changed in the object. It will produce lot of traffic on any informer watching on endpoints. An update event is produced every 2 second per endpoint. What you expected to happen: Endpoints(any object) should be updated only when there is change in either spec or status. How to reproduce it (as minimally and precisely as possible): Just watch on endpoints Also see the logs from federation controller manager, which is watching on endpoints updates from federated cluster Anything else we need to know: Looking at the endpoints controller code . it looks like reflect.DeepEqual is not working for endpoints labels and Subsets (may be need sorting, just a guess). I also see another issue raised by some time back , related but slightly different. I think this is a bug and if fixed will reduce lot of traffic to etcd.
Those two endpoints specifically are used as shared lock objects by controllers. Agree that's a bad object to use because so many things watch them for updating iptables, etc
code in question:
dupe of
Change:
return pv, nil } <ins> func (p *glusterfsVolumeProvisioner) GetClusterNodes(cli *gcli.Client, cluster string) (dynamicHostIps []string, err error) { clusterinfo, err := cli.ClusterInfo(cluster) if err != nil { glog.Errorf("glusterfs: failed to get cluster details: %v", err) return nil, fmt.Errorf("failed to get cluster details: %v", err) } // For the dynamically provisioned volume, we gather the list of node IPs // of the cluster on which provisioned volume belongs to, as there can be multiple // clusters. for _, node := range clusterinfo.Nodes { nodei, err := cli.NodeInfo(string(node)) if err != nil { glog.Errorf("glusterfs: failed to get hostip: %v", err) return nil, fmt.Errorf("failed to get hostip: %v", err) } ipaddr := dstrings.Join(nodei.NodeAddRequest.Hostnames.Storage, "") dynamicHostIps = append(dynamicHostIps, ipaddr) } glog.V(3).Infof("glusterfs: hostlist :%v", dynamicHostIps) if len(dynamicHostIps) == 0 { glog.Errorf("glusterfs: no hosts found: %v", err) return nil, fmt.Errorf("no hosts found: %v", err) } return dynamicHostIps, nil } </ins> func (p *glusterfsVolumeProvisioner) CreateVolume(gid int) (r *v1.GlusterfsVolumeSource, size int, err error) { var clusterIDs []string capacity := p.options.PVC.Spec.Resources.Requests[v1.ResourceName(v1.ResourceStorage)]

Discussion:
several operations to the glusterfs mount operation that nodes are not permitted to perform: looks up arbitrary secrets based on storage class parameters. this will not succeed, as the node authorizer will only allow nodes access to secrets referenced by pods or persistent volumes used by the node attempts to create a service and endpoint using the node's API client. nodes do not have permission to create arbitrary endpoints and services. For both of those reasons, that recreate operation will fail when attempted from the node. The recreate operation should probably move to one of the storage-related controllers (provisioner or attach/detach) cc
Marking this with 1.7 milestone until we have a better idea of whether this is blocking or not for the 1.7 release.
CC Is the endpoint originally created by the user or by the volume plugin creating/deleting Endpoint objects? In addition to the concerns raised, having a volume create new API objects seems like a bad idea (abstraction layer violation?).
From on Slack: Unless there is justification otherwise, I will roll back the PR on Monday.
cc/
revert button doesn't work, have to do it manually
Revert PR is approved and awaiting merge (). Once that merges this issue can be closed.
Opened an E2E pr to catch this kind of behavior in the future. WIP, still exploring a method to reproduce and catch the behavior.
Change:
plugin:          plugin, MetricsProvider: volume.NewMetricsStatFS(getPath(pod.UID, spec.Name(), plugin.host)), }, <del> server:       source.Server, </del> <ins> server:       getServerFromSource(source), </ins> exportPath:   source.Path, readOnly:     readOnly, mountOptions: util.MountOptionFromSpec(spec),

Discussion:
In bare-metal IPv6 environment, any pod consuming storage resource is not able to run. The storage should be consumable, and the pod should become in status. Running the in a bare-metal IPv6 configurations. I have replaced the cloud-based storage resource with a mounted to a folder on my localhost. Steps alongside logs are below :- $kubectl get svc $kubectl describe svc nfs-server $kubectl describe pv nfs $kubectl get pod -w $kubectl get pod -w $kubectl describe pod nfs-busybox-6r96h I have built the master branch to make sure it was not fixed up to this moment.
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 storage /tirage accepted /assign
Change:
func (m *effectiveVersion) Set(binaryVersion, emulationVersion, minCompatibilityVersion *version.Version) { m.binaryVersion.Store(binaryVersion) <ins> m.useDefaultBuildBinaryVersion.Store(false) </ins> m.emulationVersion.Store(majorMinor(emulationVersion)) m.minCompatibilityVersion.Store(majorMinor(minCompatibilityVersion)) }

Discussion:
Starting in 1.31, --version no longer works to modify the build ID of the running components. /kind regression /priority important-soon Running kube-apiserver v1.31.0 with ignores the modified build ID and reports In 1.28, 1.29, and 1.30 (since ), this allowed modifying the build ID of the running server. /sig api-machinery /assign Run v1.31.0 with No response 31.0 n/a <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
I think this broke in DefaultBuildEffectiveVersion() is grabbed in NewAPIServerCommand(), before the flag is parsed, so the GitVersion propagated into the snapshot effectiveVersion doesn't honor
cc