jiebi/CodeConvo huggingface dataset:
Change:
glog.V(4).Infof("ensureExternalLoadBalancer(%s): Service needs local traffic health checks on: %d%s.", lbRefStr, healthCheckNodePort, path) if hcLocalTrafficExisting == nil { // This logic exists to detect a transition for non-OnlyLocal to OnlyLocal service <del> // turn on the tpNeedsUpdate flag to delete/recreate fwdrule/tpool updating the </del> <ins> // turn on the tpNeedsRecreation flag to delete/recreate fwdrule/tpool updating the </ins> // target pool to use local traffic health check. glog.V(2).Infof("ensureExternalLoadBalancer(%s): Updating from nodes health checks to local traffic health checks.", lbRefStr) if supportsNodesHealthCheck { hcToDelete = makeHttpHealthCheck(MakeNodesHealthCheckName(clusterID), GetNodesHealthCheckPath(), GetNodesHealthCheckPort()) } <del> tpNeedsUpdate = true </del> <ins> tpNeedsRecreation = true </ins> } hcToCreate = makeHttpHealthCheck(loadBalancerName, path, healthCheckNodePort) } else { glog.V(4).Infof("ensureExternalLoadBalancer(%s): Service needs nodes health checks.", lbRefStr) if hcLocalTrafficExisting != nil { // This logic exists to detect a transition from OnlyLocal to non-OnlyLocal service <del> // and turn on the tpNeedsUpdate flag to delete/recreate fwdrule/tpool updating the </del> <ins> // and turn on the tpNeedsRecreation flag to delete/recreate fwdrule/tpool updating the </ins> // target pool to use nodes health check. glog.V(2).Infof("ensureExternalLoadBalancer(%s): Updating from local traffic health checks to nodes health checks.", lbRefStr) hcToDelete = hcLocalTrafficExisting <del> tpNeedsUpdate = true </del> <ins> tpNeedsRecreation = true </ins> } if supportsNodesHealthCheck { hcToCreate = makeHttpHealthCheck(MakeNodesHealthCheckName(clusterID), GetNodesHealthCheckPath(), GetNodesHealthCheckPort())

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 /sig network /area cloudprovider What happened: The cloud provider interface that should . The GCE provider does this for but not for . Every other in-tree provider implements by fully updating the load balancer including updated backend nodes: , , , And the following out-of-tree providers do as well and Oracle (not oss yet). What you expected to happen: I expect that all cloud providers implement by creating or fully updating the load balancer if it already exists. Related discussion: /cc
/assign Make sense to make implementation in GCE consistent with others for the ease of up-coming service controller enhancement. This sounds like a 1.10 task.
is this task blocking you on another attempt at refactoring the service controller sync logic?
yup
Change:
<ins> { "kind": "ConfigMapList", "apiVersion": "v1", "metadata": { "selfLink": "/api/v1/namespaces/edit-test/configmaps", "resourceVersion": "252" }, "items": [] } </ins>

Discussion:
Try running and adding an ingress object, or an empty list, then exit the editor – it will panic like this: I've also tried , and for the sake of experiment tried adding a Pod, then it failed rather gracefully with this message: But when I tried to add a DaemonSet, it paniced. I am not sure how we should fix, perhaps editing of lists isn't something a normal user is expected to do... Let's discuss.
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 cli
So I wanted to test how it would behave if I take an item out of my list, so I've create and ingress object and tried . To my surprise I've found only one ingress object without a list. When I a second object, gave me a list to edit. So I must say that flattening of the list in case there is only one object was a bit surprising. Now that I have a list of two items, I've decided to try deleting one by removing it from the list, and it turns that's not possible.
It feels like the problem is complicated, and I'd rather see disallowed unless users passed a name of a specific resource. If we belive some folks rely on to work when there is only one resource to edit, maybe we can keep that... If we cannot disallow this, I'd rather see it fixed in a way where removing items results in deletion and editing a single item list is actually about editing a list. At the very least, of course, we should fix the panic, but I still want to hear what people think about this before I open a PR (presumably fixing that panic should be trivial).
I'm working on this. Already submitted a PR in . PTAL.
I think at the very beginning, at least v1.5.0 the logic is already like this, I'm not sure why this bothering you I use this lot of time, I'd prefer keep it.

also cc
I don't think edit should open with an empty list. should open a list if there are multiple items, a single item if there is only one, and error if there are none of that type. should open a single item if it is found, and error if it is not found
that sounds good to me. I was just a bit surprised, that's all.
Change:
- user: root - name: /opt/cni - makedirs: True <del> - source: https://storage.googleapis.com/kubernetes-release/network-plugins/cni-8a936732094c0941e1543ef5d292a1f4fffa1ac5.tar.gz </del> <ins> - source: https://storage.googleapis.com/kubernetes-release/network-plugins/cni-9d5e6e60e79491207834ae8439e80c943db65a69.tar.gz </ins> - tar_options: v <del> - source_hash: md5=ae7ec24d2ffc0fd14a15f527744ba2c3 </del> <ins> - source_hash: md5=1ac2f8c72244f0188b8ba3d6052f9fc1 </ins> - archive_format: tar - if_missing: /opt/cni/bin

Discussion:
We should update cni binaries to containernetworking/cni and release binaries for all arches. I do not have push access to the repo, so I guess some googler have to do it.
Thanks. I have this on my plate.
Change:
} if sgNeedsUpdate { glog.V(3).Infof("delete(%s): sg(%s) - updating", serviceName, az.SecurityGroupName) <ins> // azure-sdk-for-go introduced contraint validation which breaks the updating here if we don't set these // to nil. This is a workaround until https://github.com/Azure/go-autorest/issues/112 is fixed sg.SecurityGroupPropertiesFormat.NetworkInterfaces = nil sg.SecurityGroupPropertiesFormat.Subnets = nil </ins> _, err := az.SecurityGroupsClient.CreateOrUpdate(az.ResourceGroup, *reconciledSg.Name, reconciledSg, nil) if err != nil { return err

Discussion:
Kubernetes version (use ): Environment: Cloud provider or hardware configuration: Azure / Azure Container Service OS (e.g. from /etc/os-release): Xenial Kernel (e.g. ): latest lts Install tools: kubelet + static manifests Others: n/a What happened: I created a Service (type=LoadBalancer). The load balancer did not complete provisioning and security group was not updated, so the LB that is there doesn't work. What you expected to happen: Azure load balancer is created, external IP field is populated (doesn't show as "Pending") How to reproduce it (as minimally and precisely as possible): Try it. Anything else do we need to know: No. There is an issue opened against the repo that caused this problem: This was reported here: CC:
Should we do a fix that simply sets the 2 properties to nil before a real fix comes into go-autorest?
I'd prefer to fix it properly in but as of yet, it's unclear what the timeframe is. Let me ask for a timeline.
I agree that a proper fix in go-autorest would be preferable. But as long as it's not fixed, LBs are broken on k8s=1.5.2. That's why I would like to do a workaround until the real fix comes in.
Is there a workaround? Is there a way I can manually intervene to make the LoadBalancer work?
No. Not currently, other than building your own copy of with patch applied. I'm testing a more proper fix today or tomorrow - hope to have it in for 1.5.3.
Change:
import ( "fmt" mathrand "math/rand" <del> "os/exec" </del> "strings" "time"

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 /sig storage What happened: Offshoot of . Let's change the tests to use the programmatic API instead of gcloud CLI.
Just confirming that this issue is referring only to the 3 gcloud CLI calls in
yup
PR:
Change:
{Name: "containerA"}, {Name: "containerB"}, }, <del> } currentState := api.PodStatus{ Host: "machine", </del> <ins> RestartPolicy: api.RestartPolicy{Always: &api.RestartPolicyAlways{}}, </ins> } runningState := api.ContainerStatus{ State: api.ContainerState{

Discussion:
I'm actually not sure if it's by design. But certainly replication controller doesn't behave like it expects this.
If restart policy is to restart always, they should be restarted, but in that case they shouldn't be reported as failed.
This is a known issue, and by design based on upper-level will observe the status reported from kubelet, but not check with RestartPolicy and generate PodCondition / PodStatus. When RestartPolicy is Always, even Kubelet reports all containers are at failed state, apiserver shouldn't mark Pod as failed state. This is why initially I want kubelet report Pod state / status / condiction.
As a quick fix, we could let apiserver populate the right state / status based on containerStatus and RestartPolicy for now. In a long term, I still think we should make kubelet smarter and atomic and self-contained component, not just a wrapper around docker.
Short term fix should be P1 then we can de-prio for a "realer" fix.
Yes, I am working on the short term fix, and should have it included in 0.6 cut.
are you still working on this?
Yes, I am working on this. Should finish it today.
Change:
wm[number] = w } <del> func (wm watchersMap) deleteWatcher(number int) { delete(wm, number) </del> <ins> func (wm watchersMap) deleteWatcher(number int, done func(*cacheWatcher)) { if watcher, ok := wm[number]; ok { delete(wm, number) done(watcher) } </ins> } func (wm watchersMap) terminateAll(done func(*cacheWatcher)) {

Discussion:
A data race manifested in job link: NA NA No response No response No response /sig api-machinery
/cc
/assign
ack, fixing ...
/triage accepted
Change:
class:         makeClass(nil, topologyLackOfValues), shouldSucceed: false, }, <ins> "duplicate TopologySelectorRequirement values": { class:         makeClass(nil, topologyDupValues), shouldSucceed: false, }, "multiple TopologySelectorRequirement values": { class:         makeClass(nil, topologyMultiValues), shouldSucceed: true, }, "empty MatchLabelExpressions": { class:         makeClass(nil, topologyEmptyMatchLabelExpressions), shouldSucceed: false, }, "duplicate MatchLabelExpression keys": { class:         makeClass(nil, topologyDupKeys), shouldSucceed: false, }, "duplicate MatchLabelExpression keys but across separate terms": { class:         makeClass(nil, topologyMultiTerm), shouldSucceed: true, }, "duplicate AllowedTopologies terms - identical": { class:         makeClass(nil, topologyDupTermsIdentical), shouldSucceed: false, }, "two AllowedTopologies terms, with a pair of the same MatchLabelExpressions and a pair of different ones": { class:         makeClass(nil, topologyExprsOneSameOneDiff), shouldSucceed: true, }, "two AllowedTopologies terms, with a pair of the same Values and a pair of different ones": { class:         makeClass(nil, topologyValuesOneSameOneDiff), shouldSucceed: true, }, "duplicate AllowedTopologies terms - different MatchLabelExpressions order": { class:         makeClass(nil, topologyDupTermsDiffExprOrder), shouldSucceed: false, }, "duplicate AllowedTopologies terms - different TopologySelectorRequirement values order": { class:         makeClass(nil, topologyDupTermsDiffValueOrder), shouldSucceed: false, }, } // Disable VolumeScheduling so nil VolumeBindingMode doesn't fail to validate. err := utilfeature.DefaultFeatureGate.Set("VolumeScheduling=false") if err != nil { t.Fatalf("Failed to disable feature gate for VolumeScheduling: %v", err) </ins> } // TODO: remove when feature gate not required <del> err := utilfeature.DefaultFeatureGate.Set("DynamicProvisioningScheduling=true") </del> <ins> err = utilfeature.DefaultFeatureGate.Set("DynamicProvisioningScheduling=true") </ins> if err != nil { t.Fatalf("Failed to enable feature gate for DynamicProvisioningScheduling: %v", err) }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --/kind feature The field essentially has the type , but currently there is no validation for set and map semantics, i.e. unique elements / keys. Having this validation at API level removes logic to validate at the volume plugin level. edit: this check will not be in cases where this makes it difficult to add other fields and make this field optional. /sig api-machinery /sig storage
/assign
Thanks for catching this. Would you be able to implement this for this release? We want to try to go beta if we can, and we won't be able to strengthen validation once that happens.
Yes will do!
Change:
return cmdutil.AddSourceToErr("creating", info.Source, err) } info.Refresh(obj, true) <del> metadata, err := meta.Accessor(info.Object) if err != nil { return err } visitedUids.Insert(string(metadata.GetUID())) </del> } <ins> metadata, err := meta.Accessor(info.Object) if err != nil { return err } visitedUids.Insert(string(metadata.GetUID())) </ins> count++ if printObject {

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The dry run output listed all the resources that would be configured: deployments, HPAs, services, and an ingress: This was expected. However, it then listed all resources again (except for the HPAs) as being pruned: The config was then applied with: As expected, no resources were actually pruned. What you expected to happen: should actually display which resources are going to be pruned. How to reproduce it (as minimally and precisely as possible): a YAML file to with it: run + prune: should be listed as both configured and pruned it again with pruning: that the deployment is configured but not pruned, even though the dry run said it would be. Anything else we need to know?: Was trying to write a devops script that gave a warning before any resources would be pruned. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): (Lubuntu 18.04) Kernel (e.g. ):Install tools: Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : 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
I can reproduce it, and i will try to fix it.
Change:
type VolumeOptions struct { CapacityGB int <del> Tags       *map[string]string </del> <ins> Tags       map[string]string </ins> } // Volumes is an interface for managing cloud-provisioned volumes

Discussion:
We should tag EBS volumes created by k8s with our tags, just like we (should) tag everything else we create/own.
Is there any documentation yet on automatic EBS volume creation?
from a user perspective, they are not AWS specific. That said, I don't know that we have clear user-facing docs. Here's an example though, from my (very) WIP Ubernetes-Lite docs: ... The PV is also tagged with the zone & region is is in (us-central1-a): Create a pod that uses the PVC:
It doesn't seem to cleanup the volume when the PV is deleted... probably intended behavior. Any way to tell it to automatically delete the volume on PV delete?
- I'm not sure about foo - hopefully that'll be resolved with docs. I think the failure to delete the volume is actually pretty important. Do you want to open an issue? It's not AWS specific (and this particular issue was auto-closed when the PR merged)
yeah I will open an issue later today. Issue seems to still be happening - the PV is never deleted. On Sat, Mar 12, 2016, 6:24 AM Justin Santa Barbara wrote:
Change:
"github.com/spf13/cobra" <ins> utilflag "k8s.io/apiserver/pkg/util/flag" </ins> kubeadmapi "k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm" kubeadmapiext "k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1alpha1" "k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/validation"

Discussion:
/kind feature What happened: When calling , there is no way to override default flag values for the different components of the controlplane. This is surprising, as in the config structure (and in controlplane phase codebase itself), there are explicit settings for doing that (APIServerExtraArgs, ControllerManagerExtraArgs, SchedulerExtraArgs). What you expected to happen: Those config fields should be exposed as flags on and How to reproduce it (as minimally and precisely as possible): Try to deploy K8s using Kubeadm with a custom Admission Control setting (I'll follow up on this issue with a PR)
btw, I am not sure which sig owns kubeadm.
it's sig-cluster-lifecycle.
/sig sig-cluster-lifecycle
/sig cluster-lifecycle
Change:
closeChan   chan bool dataStream  *fakeStream errorStream *fakeStream <ins> streamCount int </ins> } func newFakeConnection() *fakeConnection {

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:
csiNodeResource   = storageapi.Resource("csinodes") ) <ins> func (r *NodeAuthorizer) RulesFor(user user.Info, namespace string) ([]authorizer.ResourceRuleInfo, []authorizer.NonResourceRuleInfo, bool, error) { if _, isNode := r.identifier.NodeIdentity(user); isNode { // indicate nodes do not have fully enumerated permissions return nil, nil, true, fmt.Errorf("node authorizer does not support user rule resolution") } return nil, nil, false, nil } </ins> func (r *NodeAuthorizer) Authorize(ctx context.Context, attrs authorizer.Attributes) (authorizer.Decision, string, error) { nodeName, isNode := r.identifier.NodeIdentity(attrs.GetUser()) if !isNode {

Discussion:
What happened: I checked if kubelet () has permissions for with SelfsubjectAccessReviews and I saw that it has. But when I checked its permissions with SelfsubjectRulesReviews it didn't show it. What you expected to happen: I expected that the API SelfsubjectRulesReviews will show that has permssions for . How to reproduce it (as minimally and precisely as possible): You can check it on the master or the worker. Test SelfsubjectAccessReviews: You will get answer that it has permissions: Test SelfsubjectRulesReviews: It won't show the permissions. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: AWS OS (e.g: ):Kernel (e.g. ):Install tools: kubeadm /area/api /kind/bug /sig api-machinery
/sig api-machinery
This is a more clean display that show the bug: I think the problem is related to the fact that the file contain the kubelet certificate which is part of the group :
/sig auth
What is the SelfSubjectRulesReview response from the server ()? Note that not all authorizers support enumerating permissions, and the API object status includes an attribute which explicitly indicates the result is incomplete. See
It has Details:
I noticed that it also doesn't show that it has permissions to view and . It probably related to the Node authorizer: Because I assume that these rules doesn't appear in RBAC.
The node authorizer does not enumerate permissions, so it does not contribute to SelfSubjectRulesReview results
fixes setting correctly when the API is requested with a kubelet's credentials
Change:
postTimeoutFn := func() { cancel() <del> metrics.Record(req, requestInfo, metrics.APIServerComponent, "", http.StatusGatewayTimeout, 0, 0) </del> <ins> metrics.RecordRequestTermination(req, requestInfo, metrics.APIServerComponent, http.StatusGatewayTimeout) </ins> } return req, time.After(timeout), postTimeoutFn, apierrors.NewTimeoutError(fmt.Sprintf("request did not complete within %s", timeout), 0) }

Discussion:
What happened: When the kube-apiserver timeouts on a request, we end up doubling the counts measured in : apiserverrequestcounts apiserverrequesttotal apiserverrequestlatencies apiserverrequestlatenciessummary apiserverrequestdurationseconds apiserverresponsesizes What you expected to happen: We only count our requests a single time in our metrics. How to reproduce it (as minimally and precisely as possible): Add a 60 second sleep in the func . You may want to filter by resource (like pods or something) and verb for testing (otherwise this will be quite annoying). Manually hit that endpoint and look at the metric output. /assign
/sig api-machinery instrumentation /cc
Thanks for filing. Can we, while fixing this, add a metric counting timed-out requests? You can't tell from the latency distribution, even if we made the buckets more useful.
Yeah, that's the current plan. I've relayed the idea to offline and he has concurred.
Change:
glog.Errorf("Could not mark device is mounted to actual state of world: %v", err) continue } <ins> glog.Infof("Volume: %v is mounted", volume.volumeName) </ins> } _, err = rc.desiredStateOfWorld.AddPodToVolume(volume.podName, volume.pod, volume.volumeSpec,

Discussion:
/kind bug What happened: Volumes used by pod are not getting mounted after rebooting a node. Effects Flexvolume/FC/ISCSI volume types. Pod goes into running state using local file system path. What you expected to happen Volume should be mounted and pod should not go into running state if the volume fails to attach. How to reproduce it (as minimally and precisely as possible): Create a RS with Flexvolume/FC/ISCSI. Reboot the node. Volume would not be mounted after reboot. Anything else we need to know?: Kubelet on a process restart avoids remounting the volume. The same code path is used on a node reboot and it avoids remounting the volume. GCE, AWS etc seems to be working by chance as the SPEC reconstruction fails when a volume is not mounted on reboot. Environment: Kubernetes version (use ): 1.6.9 Cloud provider or hardware configuration**: Baremetal OS (e.g. from /etc/os-release): Centos 7.2 Kernel (e.g. ): 3.10.0-327.el7.x86_64
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
/cc