jiebi/CodeConvo huggingface dataset:
Change:
if isHTTPErrorCode(err, http.StatusNotFound) { return false, true, "", nil } <del> return false, false, "", fmt.Errorf("error getting load balancer's forwarding rule: %v", err) </del> <ins> // Err on the side of caution in case of errors. Caller should notice the error and retry. // We never want to end up recreating resources because gce api flaked. return true, false, "", fmt.Errorf("error getting load balancer's forwarding rule: %v", err) </ins> } <del> if loadBalancerIP != fwd.IPAddress { </del> <ins> // If the user asks for a specific static ip through the Service spec, // check that we're actually using it. // TODO: we report loadbalancer IP through status, so we want to verify if // that matches the forwarding rule as well. if loadBalancerIP != "" && loadBalancerIP != fwd.IPAddress { glog.Infof("LoadBalancer ip for forwarding rule %v was expected to be %v, but was actually %v", fwd.Name, fwd.IPAddress, loadBalancerIP) </ins> return true, true, fwd.IPAddress, nil } portRange, err := loadBalancerPortRange(ports) if err != nil { <del> return false, false, "", err </del> <ins> // Err on the side of caution in case of errors. Caller should notice the error and retry. // We never want to end up recreating resources because gce api flaked. return true, false, "", err </ins> } if portRange != fwd.PortRange { <ins> glog.Infof("LoadBalancer port range for forwarding rule %v was expected to be %v, but was actually %v", fwd.Name, fwd.PortRange, portRange) </ins> return true, true, fwd.IPAddress, nil } // The service controller verified all the protocols match on the ports, just check the first one if string(ports[0].Protocol) != fwd.IPProtocol { <ins> glog.Infof("LoadBalancer protocol for forwarding rule %v was expected to be %v, but was actually %v", fwd.Name, fwd.IPProtocol, string(ports[0].Protocol)) </ins> return true, true, fwd.IPAddress, nil }

Discussion:
Restarting master causes a recreation of fwrule and target pool for type=loadbalancer services. We are saved in the non restart case because we compare a cached verson of the service to decided if we should even call into the cloudprovider and update resources. This is happening because our reconciliation routines are confused about session affintiy and lbip, leading them to recreate, since inplace update isn't allowed. The impact is at best a few seconds of radio silence, at worst who knows? Repro: Create a loadbalanced service, eg: Wait for it to acquire a vip. Try it out Ssh into master and restart kube-controller-manager: Watch the wgets, you'll notice radio silence after a bit. This is because the targetpool and forwarding rule get recreted, for 2 reasons: affinity mismatch So this check fails: Lbip mismatch: So this check fails: (lbip is retrieved here: )
the session affinity fix is trivial. The easiest change for the lb ip fix is to not actually check the ip, but simply backoff as long as the forwarding rule exists. This is "bad" because of the way we allocate a static-ip, assign it to the fwd rule, then de-allocate it. The alternative is to use to reconcile, but that's racy.
cherry pick
Change:
op(queue, test.operands[i]) } <ins> queue.lock.Lock() </ins> for i := 0; i < len(test.expected); i++ { if pInfo, err := queue.activeQ.Pop(); err != nil { t.Errorf("Error while popping the head of the queue: %v", err)

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: pull-kubernetes-bazel-test Which test(s) are flaking: pkg/scheduler/internal/queue Testgrid link: Reason for failure: Anything else we need to know: /sig scheduling /assign
I just sent a pr for it according to the error message, but I'm not very sure if it will make things all right.
/assign
Change:
return validateURL(issuerURL, disallowedIssuers, fldPath) } <del> func validateIssuerDiscoveryURL(issuerURL, issuerDiscoveryURL string, fldPath *field.Path) field.ErrorList { </del> <ins> func validateIssuerDiscoveryURL(issuerURL, issuerDiscoveryURL string, fldPath *field.Path, structuredAuthnFeatureEnabled bool) field.ErrorList { </ins> var allErrs field.ErrorList if len(issuerDiscoveryURL) == 0 { return nil } <ins> if !structuredAuthnFeatureEnabled { allErrs = append(allErrs, field.Invalid(fldPath, issuerDiscoveryURL, "discoveryURL is not supported when StructuredAuthenticationConfiguration feature gate is disabled")) } </ins> if len(issuerURL) > 0 && strings.TrimRight(issuerURL, "/") == strings.TrimRight(issuerDiscoveryURL, "/") { allErrs = append(allErrs, field.Invalid(fldPath, issuerDiscoveryURL, "discoveryURL must be different from URL")) }

Discussion:
For example, should not let you set discovery URL when the feature gate is not enabled. I believe this only impacts library users, as direct usage in KAS requires the file based config, which is feature gated. /assign enj aramase /milestone v1.32
Change:
}, "new serviceaccount with no secrets with resource conflict": { ClientObjects: []runtime.Object{updatedServiceAccount(emptySecretReferences()), createdTokenSecret()}, <ins> IsAsync:       true, MaxRetries:    1, </ins> AddedServiceAccount: serviceAccount(emptySecretReferences()), ExpectedActions: []core.Action{ core.NewGetAction(schema.GroupVersionResource{Version: "v1", Resource: "serviceaccounts"}, metav1.NamespaceDefault, "default"), <ins> core.NewGetAction(schema.GroupVersionResource{Version: "v1", Resource: "serviceaccounts"}, metav1.NamespaceDefault, "default"), </ins> }, }, "updated serviceaccount with no secrets": {

Discussion:
https://k8s- Failed: TestTokenCreation {serviceaccount} Previous issues for this test:
https://k8s- Failed: TestTokenCreation {serviceaccount}
fixed in (same fix as , missed that there was a second test involving resource conflicts)
Change:
case *os.SyscallError: underlyingError = pe.Err } <del> return underlyingError == syscall.ENOTCONN || underlyingError == syscall.ESTALE </del> <ins> return underlyingError == syscall.ENOTCONN || underlyingError == syscall.ESTALE || underlyingError == syscall.EIO </ins> } // GetSecretForPod locates secret by name in the pod's namespace and returns secret map

Discussion:
/kind bug What happened: Kubelet failed to unmount volumes if the backend ISCSI volume is not available. This also applies to other network attached volumes. What you expected to happen: Kubelet should be able to unmount the volumes. A manual unmount works even when the backend network volume is not available. How to reproduce it (as minimally and precisely as possible): Mount an ISCSI/network volume and disconnect/de-provision ISCSI target. Anything else we need to know?: XFS shuts down the filesystem due to I/O errors. Kubelet uses "stat" calls to figure out if it is a valid mount point or it is already unmounted. Stat calls fail with EIO and Kubelet never proceeds to unmount the volume. Environment: Kubernetes version (use ): Kubernetes 1.10.5 Cloud provider or hardware configuration: Bare metal OS (e.g. from /etc/os-release): Centos 7.4 Kernel (e.g. ): Linux appserv37 3.10.0-693.el7.x8664 SMP Tue Aug 22 21:09:27 UTC 2017 x8664 x8664 x8664 GNU/Linux Install tools: Manual bring up Others:
/sig storage
IsLikelyNotMountPoint is using stat call to figure the filesystem is mounted or not. Stat calls are failing with EIO when there are I/O errors on the backend and Kubelet never proceeds to unmount the filesystem. Also, isLikelyNotMountPoint is not looking for "isCorruptedMnt" errors. All other calls have it.
looks like the nfs plugin is calling . Can iscsi use that?
didn't include error "Input/output error" () We should add it. I make a fix, PTAL, Thank you!
Thanks. Trying out the change. Will keep you posted if we need any other changes.
Stock ISCSI driver is working fine with EIO change. But more changes are required for making it work with Flexvolume drivers. I have the change list. I can club your change in or let me know if you want to go ahead and push this fix. I will push another PR to fix flexvolume issues.
Please club my change, I will close my PR. Thanks!
Change:
[]string{"operation"}, ) <ins> var vsphereVersion = metrics.NewDesc( "cloudprovider_vsphere_vcenter_versions", "Versions for connected vSphere vCenters", []string{"hostname", "version", "build"}, nil, metrics.ALPHA, "") </ins> // RegisterMetrics registers all the API and Operation metrics func RegisterMetrics() { legacyregistry.MustRegister(vsphereAPIMetric) legacyregistry.MustRegister(vsphereAPIErrorMetric) legacyregistry.MustRegister(vsphereOperationMetric) legacyregistry.MustRegister(vsphereOperationErrorMetric) <ins> legacyregistry.CustomMustRegister(vCenterMetric) } type vcenterMetric struct { metrics.BaseStableCollector mux          sync.Mutex vCenterInfos map[string]types.AboutInfo } func (collector *vcenterMetric) DescribeWithStability(ch chan<- *metrics.Desc) { ch <- vsphereVersion } func (collector *vcenterMetric) CollectWithStability(ch chan<- metrics.Metric) { collector.mux.Lock() defer collector.mux.Unlock() for vCenter, info := range collector.vCenterInfos { ch <- metrics.NewLazyMetricWithTimestamp(time.Now(), metrics.NewLazyConstMetric(vsphereVersion, metrics.GaugeValue, float64(1), vCenter, info.Version, info.Build)) } } func (collector *vcenterMetric) setAbout(server string, info types.AboutInfo) { collector.mux.Lock() defer collector.mux.Unlock() collector.vCenterInfos[server] = info } func setVCenterInfoMetric(connection *VSphereConnection) { vCenterMetric.setAbout(connection.Hostname, connection.Client.ServiceContent.About) </ins> } // RecordvSphereMetric records the vSphere API and Operation metrics

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : We need reporting of version to be shown in the metrics. Why is this needed: The goal behind this is to add some info about the underlying infrastructure for the kubernetes cluster. Some customers were experiencing issues during the cluster upgrades, but nothing in the upgrades themselves or kubernetes code for provider seemingly could cause those. The issue is storage related, and happening on a variety of releases with a significant delay from any other underlying infrastructure change, to which the kubernetes cluster has no relation and a way to know about. So knowing used hostnames, and versions associated with it over time would be extremely beneficial for debugging in similar circumstances. Some of the use cases we face: 1) A is enabled in a customer environment, and so there occurs a periodic automated vMotion for VMs backing kuberentes . We'd like to know on which host the actual kubernetes was located at any moment, and if any vCenter version transitions happened over time, new hosts /removed/renamed.
/sig cloud-provider /wg provider-vsphere
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig cloud-provider /wg provider-vsphere 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
/area provider/vmware
Change:
kube::release::package_kube_manifests_tarball & kube::util::wait-for-jobs || { kube::log::error "previous tarball phase failed"; return 1; } <del> kube::release::package_full_tarball & # _full depends on all the previous phases </del> <ins> kube::release::package_final_tarball & # _final depends on some of the previous phases </ins> kube::release::package_test_tarball & # _test doesn't depend on anything kube::util::wait-for-jobs || { kube::log::error "previous tarball phase failed"; return 1; } }

Discussion:
Either include non-arch specific stuff in every tar or break that out too. ref cc
interested in helping with this one?
Yes, I may help
OK, I did not actually understand what was in , apparently. Alternate proposal: [ ] update all references that need just server binaries to download the server tarball directly [ ] same for places that just need (related to ) [ ] remove all arch-specific binary artifacts from and replace with a script which downloads the client/server tarballs as necessary. The alternative option, including all of the non-arch-specific code and docs in an arch-specific starts to get very tricky, since we run into a large cross product of client x server platforms/archs.
Change:
plugins       []*TestPlugin wantStatus    *framework.Status wantStatusMap framework.PluginToStatus <del> runAllFilters bool </del> }{ { name: "SuccessFilter",

Discussion:
Since scheduler Policy API was total removed, we don't support any more. Remove unsupported configuration.
/sig scheduling /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
/sig scheduling /cc
/sig scheduling (trying to tell the bots to remove )
The label(s) cannot be applied. These labels are supported: <detailsIn response to : /remove-needs sig /remove-label needs-sig 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
It's true scheduler doesn't quite use this field anymore, but I'm wondering if some other project like ClusterAutoscaler or simulator still consumes this via .
There's no place we can config this field now by configure file(before we can apply the change by policy api, but now it's removed). So it seems like unless we support this feature with CC, or this field is useless. To other projects, it's the same. When they are using legacy policy api, they can configure this field, but once they synced with the latest kubernetes, with the policy api removed, they can not configure this anymore. In this situation, we should add support in CC. I don't quite understand the relationship between k/k with k/autoscaling or others, I think they sync with k/k periodic.
As I mentioned above, it's still accessible via a framework runtime programmatically, and thus may be still useful. For example, upon a scheduling failure, a ClusterAutoscaler's implementation may choose to dryrun through all filter plugins to ensure a new provisioned node can fit the pod, instead of resolving the failure while failing at another latter filter plugin.
Oh, I haven't thought of configuration via programmatically, that saved my concern. But a little strange.
That's exactly what I meant. Given it's a public option in framework, and there is no alternative if we disabled it, it'd be good to check with potential consumers.

For now I can think of CA ( and k-sigs/scheduler-simulator ( If they can confirm it's not needed in their usecases, I'm fine with removing .
To k/autoscaler, at least these codes are still there together with the legacy policy api. , looking forward to the response.
is not used in sigs/kube-scheduler-simulator. ‍
this isn't used by cluster autoscaler, we can remove it.
Change:
glog.Errorf("Unable to extract field %s: %s", fileInfo.FieldRef.FieldPath, err.Error()) errlist = append(errlist, err) } else { <del> fileProjection.Data = []byte(sortLines(values)) </del> <ins> fileProjection.Data = []byte(values) </ins> } } else if fileInfo.ResourceFieldRef != nil { containerName := fileInfo.ResourceFieldRef.ContainerName

Discussion:
/kind bug What happened: When using the downward api to render a file via a volume mount from and annotation that has newlines in it, it appears that the file is rendered with the content sorted by line. A concrete example: Expected is that would contain But it does not The above is obviously contrived, this is creating a problem for my team when we are trying to use the downward api to render a yaml file (which obviously has newlines) Environment: Kubernetes version (use ): 1.9.7 Cloud provider or hardware configuration: aws OS (e.g. from /etc/os-release): centos
/sig apps Not sure about the sig here
/sig node /sig storage
Just tested it on 1.10.5 and this bug still happens.
thanks!
Change:
} } <del> func (kl *Kubelet) generatePodStatus(pod *api.Pod, podStatus *kubecontainer.PodStatus) api.PodStatus { </del> <ins> func (kl *Kubelet) generateAPIPodStatus(pod *api.Pod, podStatus *kubecontainer.PodStatus) api.PodStatus { </ins> glog.V(3).Infof("Generating status for %q", format.Pod(pod)) // TODO: Consider include the container information. if kl.pastActiveDeadline(pod) {

Discussion:
We moved reason cache and status convert function from to by , , and . After this, we should also migrate related old unit test to kubelet level. For we should add test for: [x] Different image pull policy. [x] Pod creation failure. [x] Pod image failure. For we should add test for: [x] ContainerStatuses order. [x] Last termination state. [x] How reason cache will affect the PodPhase: [x] Pull image failure reason [x] Pod creation failure reason
Time to close this issue? :)
Not yet, The last 3 tests are in . :)
Change:
} } <del> func AssertHistogramTotalCount(t *testing.T, name string, labelFilter map[string]string, wantCount int) { </del> <ins> func AssertHistogramTotalCount(t TB, name string, labelFilter map[string]string, wantCount int) { </ins> metrics, err := legacyregistry.DefaultGatherer.Gather() if err != nil { t.Fatalf("Failed to gather metrics: %s", err)

Discussion:
We have many "test only" packages through out the project, containing fixtures, helpers, utilities, etc... These test libraries are not intended for use in production binaries. They often lack rigorous review and sufficient testing for use in production binaries. We should make sure they don't accidentally get pulled in. Strawman proposal, test only packages must import "testing". Blank import is sufficient: Then write a presubmit that fails if we find symbol in the release binary. This approach is trivial and fairly effective although a more sophisticated approach could print a dep chain.
/assign
I hope I will be able to contribute once this gets marked as .
/triage accepted
I think that will be enough a new script or a check in the building scripts /cc since he has experience from the providerless building effort
I got what we want to achieve here but I'm little confused about: If I execute: after adding the import then only it is giving - what do we want to achieve by executing this command exactly? I got what it is doing. I've opened a thread in slack as well:
Hello! Is there anyone working on this issue at the moment? If not and the issue it's still relevant, I would like to work on it if possible. Thank you.
I opened a PR in the meantime, if it's not needed anymore, I can close it.
Change:
} }, "spec": { <del> "replicas": 8, </del> <ins> "replicas": 2, </ins> "selector": { "name": "nettest" },

Discussion:
test panicked: (root)/Kubernetes%%20suite/Monitoringverifymonitoringpodsandallclusternodesareavailableoninfluxdbusingheapster/ cc
Vish please take a look if you have cycles or reassign if there's someone with better context.
I looked at the panic and it was due to the last test (networking) timing out but still running. I think the fix is more in better cleanup between tests.
I just saw this... it's totally due to ginkgo's cleanup when a test times out. I can fix.
I will get this one.
Ugh, the thing ginkgo does when a test times out is totally lame...
Instead of working around this, I've filed I'm going to go back to a manual timeout on this test.
Change:
"reflect" "testing" <ins> "github.com/stretchr/testify/assert" </ins> "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" <ins> "k8s.io/apimachinery/pkg/types" </ins> "k8s.io/kubernetes/pkg/api/legacyscheme" "k8s.io/kubernetes/pkg/api/testapi" <ins> "k8s.io/kubernetes/pkg/apis/core" </ins> api "k8s.io/kubernetes/pkg/apis/core" <ins> "k8s.io/kubernetes/pkg/apis/core/validation" </ins> "k8s.io/kubernetes/pkg/securitycontext" )

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: I created a static pod for etcd as following with vsphere as cloud provider: But the hostname is using upper name, and when kubelet start the etcd static pod, it will report error as follows: I think that the vsphere should not return upper case hostname, but only lower case hostname. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/area cloudprovider
Here is a quick
/sig node
Change:
#   KUBE_USER #   KUBE_PASSWORD function get-password { <del> # templates to extract the username,password for the current-context user # Note: we save dot ('.') to $dot because the 'with' action overrides dot local username='{{$dot := .}}{{with $ctx := index $dot "current-context"}}{{$user := index $dot "contexts" $ctx "user"}}{{index $dot "users" $user "username"}}{{end}}' local password='{{$dot := .}}{{with $ctx := index $dot "current-context"}}{{$user := index $dot "contexts" $ctx "user"}}{{index $dot "users" $user "password"}}{{end}}' KUBE_USER=$("${KUBE_ROOT}/cluster/kubectl.sh" config view -o template --template="${username}") KUBE_PASSWORD=$("${KUBE_ROOT}/cluster/kubectl.sh" config view -o template --template="${password}") </del> <ins> get-kubeconfig-basicauth </ins> if [[ -z "${KUBE_USER}" || -z "${KUBE_PASSWORD}" ]]; then KUBE_USER=admin KUBE_PASSWORD=$(python -c 'import string,random; print "".join(random.SystemRandom().choice(string.ascii_letters + string.digits) for _ in range(16))')

Discussion:
Retrying after gave no joy.
Trying did not help.
will fix it. The problem is that your kubeconfig's current-context doesn't have a corresponding context entry. I'll see if I can make it gce's kube-up little more robust to invalid kubeconfig entries.
Thank you kindly for your help again. My brain is simply not large enough to remember all this.
Change:
if proxier.healthzServer != nil { proxier.healthzServer.Updated() } <del> SyncProxyRulesLastTimestamp.SetToCurrentTime() </del> <ins> metrics.SyncProxyRulesLastTimestamp.SetToCurrentTime() </ins> // Update service healthchecks.  The endpoints list might include services that are // not "OnlyLocal", but the services list will not, and the serviceHealthServer

Discussion:
function on is not being used, and kproxy metrics are not showing on endpoint. See kube-proxy related metrics. Access kube-proxy on and search for kube-proxy specific metrics. No response <detailsKube-proxy build from master </details<details</details<details</details<details</details<details</details<details</details
/sig windows
/triage accepted /priority important-soon
/milestone v1.24