jiebi/CodeConvo huggingface dataset:
Change:
// mountPropagation determines how mounts are propagated from the host // to container and the other way around. // When not set, MountPropagationHostToContainer is used. <del> // This field is alpha in 1.8 and can be reworked or removed in a future // release. </del> <ins> // This field is beta in 1.10. </ins> // +optional MountPropagation *MountPropagationMode `json:"mountPropagation,omitempty" protobuf:"bytes,5,opt,name=mountPropagation,casttype=MountPropagationMode"` }

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: Mount propagation feature was moved to beta in PR However the was not updated to reflect that it is now beta: What you expected to happen: Comment reflects feature is beta. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: /assign 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 add a sig label. <detailsA sig label can be by either: 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. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals 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 push a PR for it.
Oops, sorry. thanks for the PR.
oops, missing priority was my fault, moving back into milestone: /priority critical-urgent /remove-priority important-soon
Update to make bot happy: PR is approved and ready to merge
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Change:
} watchCache := newWatchCache( <del> config.KeyFunc, cacher.processEvent, config.GetAttrsFunc, config.Versioner, config.Indexers, objType) </del> <ins> config.CacheCapacity, config.KeyFunc, cacher.processEvent, config.GetAttrsFunc, config.Versioner, config.Indexers, objType) </ins> listerWatcher := NewCacherListerWatcher(config.Storage, config.ResourcePrefix, config.NewListFunc) reflectorName := "storage/cacher.go:" + config.ResourcePrefix

Discussion:
<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Which test(s) are failing: Since when has it been failing: Testgrid link: Reason for failure: Anything else we need to know: /cc /priority critical-urgent /milestone v1.19
/sig api-machinery
Suspect it has to do with cc /assign (for CI signal ownership)
Seems unlikely since multiple kind e2e tests passed on the PR itself
I was thinking that as well, but I don't see any other relevant changes
Actually, I take that back. Looks like the same failure was encountered as a flake on some of the PR runs. Looking at the test, it appears to assume the resource version of the kubernetes service will always be in the watch window, which is a bad assumption. I'd expect us to fix that assumption in the test, but also make sure we didn't unintentionally shrink the watch window for resources.
/assign
Note: this also appears to be breaking
Failure seems to be timeout related as well shows the runtime ~tripled after merged
revert open in can investigate test failure and timeouts and bring the change back in
I take it back, the test tolerates an expired error explicitly.
showed 17 of the 22 runs since merged took ~1 hour. The first run after the revert at returned to less than 30 minutes for the run. Will keep an eye on that to see if subsequent runs match.
- thanks a lot for looking into it. I don't think my PR changed anything that anyone should rely on. I will take a deeper look into it and try to fix that (hopefully later this week).
contains the explanation and describes the bug (in fact this bug still exists in the codebase, that PR was only increasing the probability of this particular test hitting it)
Change:
// parseACRLoginServerFromImage takes image as parameter and returns login server of it. // Parameter `image` is expected in following format: foo.azurecr.io/bar/imageName:version // If the provided image is not an acr image, this function will return an empty string. <del> func parseACRLoginServerFromImage(image string) string { </del> <ins> func (a *acrProvider) parseACRLoginServerFromImage(image string) string { </ins> match := acrRE.FindAllString(image, -1) if len(match) == 1 { return match[0] } <ins> // handle the custom cloud case if a != nil && a.environment != nil { cloudAcrSuffix := a.environment.ContainerRegistryDNSSuffix cloudAcrSuffixLength := len(cloudAcrSuffix) if cloudAcrSuffixLength > 0 { customAcrSuffixIndex := strings.Index(image, cloudAcrSuffix) if customAcrSuffixIndex != -1 { endIndex := customAcrSuffixIndex + cloudAcrSuffixLength return image[0:endIndex] } } } </ins> return "" }

Discussion:
What happened: An aks-engine cluster with a user assigned managed service cluster identity fails to authenticate to azure container registries in private clouds when the proper (acrpull) azure role assignments are in place and when there are no image pull secrets. What you expected to happen: The cluster should be able to authenticate and pull from an ACR hosted in the same azure cloud without needing additional pull secrets when the cluster identity has the proper acrpull azure role assignment, no matter which azure cloud it is operating in. How to reproduce it (as minimally and precisely as possible): Assume you have a private azure cloud where every url ends with "". That would mean the ACR suffix would be . Let's pretend you have an ACR at and you try to deploy a pod in your cluster referencing the image . This will fail to pull when you have no image pull secrets. Anything else we need to know?: The problem stems from the following lines where expected ACR suffix domains are hardcoded: Environment: Kubernetes version (use ): 1.16.9 Cloud provider or hardware configuration: Azure private OS: ubuntu 16.0.4 Network plugin and version: Azure CNI
/sig provider-azure
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig provider-azure 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/azure /sig cloud-provider
It looks like we may be able to obtain the acr suffix from the azure environment:
there is a security issue here: if we support self defined ACR domain, e.g. , then service principal secret could be sent to that remote server. The reason why we use hardcoded domains is that we could always make sure the following 4 domains are owned by Azure:
Change:
} // DEPRECATED 1.9 - This group version of IPBlock is deprecated by networking/v1/IPBlock. <del> // IPBlock describes a particular CIDR (Ex. "192.168.1.1/24") that is allowed to the pods // matched by a NetworkPolicySpec's podSelector. The except entry describes CIDRs that should // not be included within this rule. </del> <ins> // IPBlock describes a particular CIDR (Ex. "192.168.1.1/24","2001:db9::/64") that is allowed // to the pods matched by a NetworkPolicySpec's podSelector. The except entry describes CIDRs // that should not be included within this rule. </ins> type IPBlock struct { // CIDR is a string representing the IP Block <del> // Valid examples are "192.168.1.1/24" </del> <ins> // Valid examples are "192.168.1.1/24" or "2001:db9::/64" </ins> CIDR string `json:"cidr" protobuf:"bytes,1,name=cidr"` // Except is a slice of CIDRs that should not be included within an IP Block <del> // Valid examples are "192.168.1.1/24" </del> <ins> // Valid examples are "192.168.1.1/24" or "2001:db9::/64" </ins> // Except values will be rejected if they are outside the CIDR range // +optional Except []string `json:"except,omitempty" protobuf:"bytes,2,rep,name=except"`

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : mentions an IPBlock with only IPv4 examples. Add a comment or example to clarify that IPv6 network blocks are (or possibly aren't) valid here. Why is this needed: Cluster operators who use IPv6 networking want to understand how to isolate different workloads inside their cluster network (and without reading source code). Logged against kubernetes/kubernetes rather than the website repo because this is generated documentation. Kubernetes already has single-stack support for IPv6 clusters KEP for dual-stack support is /sig docs /sig network /priority backlog
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign /remove-triage unresolved can you guide me on what steps are needed to publish the examples?
I via the pull request. (Although I want these examples , it's not a task I'm familiar with).
Change:
volType := pattern.VolType if r.pvc != nil || r.pv != nil { <del> By("Deleting pv and pvc") if errs := framework.PVPVCCleanup(f.ClientSet, f.Namespace.Name, r.pv, r.pvc); len(errs) != 0 { framework.Failf("Failed to delete PVC or PV: %v", utilerrors.NewAggregate(errs)) </del> <ins> switch volType { case testpatterns.PreprovisionedPV: By("Deleting pv and pvc") if errs := framework.PVPVCCleanup(f.ClientSet, f.Namespace.Name, r.pv, r.pvc); len(errs) != 0 { framework.Failf("Failed to delete PVC or PV: %v", utilerrors.NewAggregate(errs)) } case testpatterns.DynamicPV: By("Deleting pvc") // We only delete the PVC so that PV (and disk) can be cleaned up by dynamic provisioner if r.pv.Spec.PersistentVolumeReclaimPolicy != v1.PersistentVolumeReclaimDelete { framework.Failf("Test framework does not currently support Dynamically Provisioned Persistent Volume %v specified with reclaim policy that isnt %v", r.pv.Name, v1.PersistentVolumeReclaimDelete) } err := framework.DeletePersistentVolumeClaim(f.ClientSet, r.pvc.Name, f.Namespace.Name) framework.ExpectNoError(err, "Failed to delete PVC %v", r.pvc.Name) err = framework.WaitForPersistentVolumeDeleted(f.ClientSet, r.pv.Name, 5*time.Second, 5*time.Minute) framework.ExpectNoError(err, "Persistent Volume %v not deleted by dynamic provisioner", r.pv.Name) default: framework.Failf("Found PVC (%v) or PV (%v) but not running Preprovisioned or Dynamic test pattern", r.pvc, r.pv) </ins> } }

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?: What happened: https://k8s- https://k8s-
/assign /priority critical-urgent /kind failing-test cc
/cc this is the symptom you said had an internal fix coming by end of week (ie: today)?
No this is purely oss
cc
Change:
return nil, err } <ins> subnetworkURL := g.SubnetworkURL() if g.AlphaFeatureGate.Enabled(AlphaFeatureILBCustomSubnet) { // If this feature is enabled, changes to subnet annotation will be // picked up and reflected in the forwarding rule. // Removing the annotation will set the forwarding rule to use the default subnet. if options.SubnetName != "" { subnetworkURL = gceSubnetworkURL("", g.networkProjectID, g.region, options.SubnetName) } } else { // TODO(84885) remove this once ILBCustomSubnet goes beta. if existingFwdRule != nil && existingFwdRule.Subnetwork != "" { // If the ILB already exists, continue using the subnet that it's already using. // This is to support existing ILBs that were setup using the wrong subnet - https://github.com/kubernetes/kubernetes/pull/57861 subnetworkURL = existingFwdRule.Subnetwork } } </ins> // Determine IP which will be used for this LB. If no forwarding rule has been established // or specified in the Service spec, then requestedIP = "". <del> requestedIP := determineRequestedIP(svc, existingFwdRule) ipToUse := requestedIP </del> <ins> ipToUse := ilbIPToUse(svc, existingFwdRule, subnetworkURL) </ins> <del> // If the ILB already exists, continue using the subnet that it's already using. // This is to support existing ILBs that were setup using the wrong subnet. subnetworkURL := g.SubnetworkURL() if existingFwdRule != nil && existingFwdRule.Subnetwork != "" { // external LBs have an empty Subnetwork field. subnetworkURL = existingFwdRule.Subnetwork } </del> <ins> klog.V(2).Infof("ensureInternalLoadBalancer(%v): Using subnet %s for LoadBalancer IP %s", loadBalancerName, options.SubnetName, ipToUse) </ins> var addrMgr *addressManager // If the network is not a legacy network, use the address manager if !g.IsLegacyNetwork() { <del> addrMgr = newAddressManager(g, nm.String(), g.Region(), subnetworkURL, loadBalancerName, requestedIP, cloud.SchemeInternal) </del> <ins> addrMgr = newAddressManager(g, nm.String(), g.Region(), subnetworkURL, loadBalancerName, ipToUse, cloud.SchemeInternal) </ins> ipToUse, err = addrMgr.HoldAddress() if err != nil { return nil, 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: ILB ip addresses come from the subnet that the K8s cluster uses. There is no ability to specify a different subnet. What you expected to happen: ILB ip addresses should be allocated from a different subnet if specified. 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: GCE OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/area platform/gce /assign
/sig network
Change:
klog.Errorf("Failed to delete destination: %v, error: %v", uniqueRS, err) } } <del> // make sure it does not fall within an excluded CIDR range. for _, excludedCIDR := range proxier.excludeCIDRs { // Any validation of this CIDR already should have occurred. _, n, _ := net.ParseCIDR(excludedCIDR) if n.Contains(svc.Address) { okayToDelete = false break } </del> <ins> klog.V(4).Infof("Delete service %s", svc.String()) if err := proxier.ipvs.DeleteVirtualServer(svc); err != nil { klog.Errorf("Failed to delete service %s, error: %v", svc.String(), err) </ins> } <del> if okayToDelete { klog.V(4).Infof("Delete service %s", svc.String()) if err := proxier.ipvs.DeleteVirtualServer(svc); err != nil { klog.Errorf("Failed to delete service %s, error: %v", svc.String(), err) } addr := svc.Address.String() if _, ok := legacyBindAddrs[addr]; ok { klog.V(4).Infof("Unbinding address %s", addr) if err := proxier.netlinkHandle.UnbindAddress(addr, DefaultDummyDevice); err != nil { klog.Errorf("Failed to unbind service addr %s from dummy interface %s: %v", addr, DefaultDummyDevice, err) } else { // In case we delete a multi-port service, avoid trying to unbind multiple times delete(legacyBindAddrs, addr) } </del> <ins> addr := svc.Address.String() if _, ok := legacyBindAddrs[addr]; ok { klog.V(4).Infof("Unbinding address %s", addr) if err := proxier.netlinkHandle.UnbindAddress(addr, DefaultDummyDevice); err != nil { klog.Errorf("Failed to unbind service addr %s from dummy interface %s: %v", addr, DefaultDummyDevice, err) } else { // In case we delete a multi-port service, avoid trying to unbind multiple times delete(legacyBindAddrs, addr) </ins> } } } } } <ins> func (proxier *Proxier) isIPInExcludeCIDRs(ip net.IP) bool { // make sure it does not fall within an excluded CIDR range. for _, excludedCIDR := range proxier.excludeCIDRs { // Any validation of this CIDR already should have occurred. _, n, _ := net.ParseCIDR(excludedCIDR) if n.Contains(ip) { return true } } return false } </ins> func (proxier *Proxier) getLegacyBindAddr(activeBindAddrs map[string]bool, currentBindAddrs []string) map[string]bool { legacyAddrs := make(map[string]bool) isIpv6 := utilnet.IsIPv6(proxier.nodeIP)

Discussion:
What happened: When I config kube-proxy with excludeCIDRs, kube-proxy still try to delete my ipvs rules. What you expected to happen: kube-proxy not delete excludeCIDRs virturl server. How to reproduce it (as minimally and precisely as possible): kubeadm init --config=kubeadm- --experimental-upload-certs Then add a ipvs on node: Then join the node, you can see kube-proxy log: If don't have an active connection, the ipvs will removed. Environment: Kubernetes version (use ): v1.14.0 OS (e.g: ): centos7.4 Kernel (e.g. ): 10 Install tools: kubeadm
/sig network
/triage unresolved I am a bot run by ‍
Kube-proxy delete RS from VIP, even if VIP in excludeCIDRs Because RS are the same with RS from Service VIP's Expected: But kube-proxy make that: - -
I think this is not we expected. I want using ipvs as a local porxy for kubernetes HA.
I've raised the pr
/remove-triage unresolved
Change:
} if redirect := resp.Header.Get("Location"); redirect != "" { <del> resp.Header.Set("Location", t.rewriteURL(redirect, req.URL)) </del> <ins> resp.Header.Set("Location", t.rewriteURL(redirect, req.URL, req.Host)) </ins> return resp, 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?: What happened: When accessing a service (e.g., ) by using the Apiserver proxy feature and the service returns with header, such as The returned header does not preserve the path if the service sent a redirect with an absolute path. Depending on the cluster, the header written by the service itself might have been and the apiserver proxy did rewrite the host:port to match the correct values. Unfortunately, it did not rewrite the path segment. What you expected to happen: I would expect the apiserver to rewrite the path segment of the response header so that it reflects the fact that it's proxied under the path: How to reproduce it (as minimally and precisely as possible): The path was not preserved. Anything else we need to know?: To work around this issue, a service may return strictly a relative url in the header such as: The feature to rewrite headers is quite common. For instance, Apache Httpd does it thanks to: Environment: Kubernetes version (use ):Cloud provider or hardware configuration**: custom_ OS (e.g. from /etc/os-release): Kernel (e.g. ):
/sig api-machinery /sig network
/assign
Thanks for the bug report!
GitHub didn't allow me to assign the following users: roycaihw. Note that only can be assigned. <detailsIn response to : /assign 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:
typ reflect.Type } <ins> // unexportedTypePanic is thrown when you use this DeepEqual on something that has an // unexported type. It indicates a programmer error, so should not occur at runtime, // which is why it's not public and thus impossible to catch. type unexportedTypePanic []reflect.Type func (u unexportedTypePanic) Error() string { return u.String() } func (u unexportedTypePanic) String() string { strs := make([]string, len(u)) for i, t := range u { strs[i] = fmt.Sprintf("%v", t) } return "an unexported field was encountered, nested like this: " + strings.Join(strs, " -> ") } func makeUsefulPanic(v reflect.Value) { if x := recover(); x != nil { if u, ok := x.(unexportedTypePanic); ok { u = append(unexportedTypePanic{v.Type()}, u...) x = u } panic(x) } } </ins> // Tests for deep equality using reflected types. The map argument tracks // comparisons that have already been seen, which allows short circuiting on // recursive types. func (e Equalities) deepValueEqual(v1, v2 reflect.Value, visited map[visit]bool, depth int) bool { <ins> defer makeUsefulPanic(v1) </ins> if !v1.IsValid() || !v2.IsValid() { return v1.IsValid() == v2.IsValid() }

Discussion:
This tree has a commit that demonstrates two obviously different objects that should not pass the semantic DeepEqual but do.
What shall we do with this issue for triage? Labels? Priority?
P2 for when he returns , Satnam Singh wrote:
OK I am now sufficiently worried about this. Fixes incoming.
Change:
"authentication_test.go", "authn_audit_test.go", "authorization_test.go", <ins> "cachecontrol_test.go", </ins> "impersonation_test.go", "requestinfo_test.go", ],

Discussion:
The kube-apiserver is protected, so it's responses should not be cached. The only known exception is for openapi data which is not sensitive, which is large, and which has etags. /assign
/sig api-machinery
Change:
t.Fatalf("metadata.resourceVersion not found") } <del> // this call waits for the resourceVersion to be reached in the cache before returning. // We need to do this because the patch gets its initial object from the storage, and the cache serves that. // If it is out of date, then our initial patch is applied to an old resource version, which conflicts // and then the updated object shows a conflicting diff, which permanently fails the patch. // This gives expected stability in the patch without retrying on an known number of conflicts below in the test. // See https://issue.k8s.io/42644 _, err = noxuResourceClient.Get(context.TODO(), "foo", metav1.GetOptions{ResourceVersion: patchedNoxuInstance.GetResourceVersion()}) if err != nil { t.Fatalf("unexpected error: %v", err) } </del> // Scale.Spec.Replicas = 7 but Scale.Status.Replicas should remain 0 gottenScale, err := scaleClient.Scales("not-the-default").Get(context.TODO(), groupResource, "foo", metav1.GetOptions{}) if err != nil {

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-integration Which test(s) are flaking: TestSubresourcePatch Testgrid link: Reason for failure: Unknown. A diff with the original object would be helpful. Anything else we need to know: /sig api-machinery
OK Trying to reproduce, see what's going on.
Clearly this is because SSA is updating the tracked entry's time. It happens when the two request don't happen in the same second. Having a between the two requests makes this into a definitive error.
/wg apply
This seems to be because of . A repeated patch like will always trigger a new managedFields entry to be created, since it's always going to change the object (status or spec will be wiped depending on the endpoint), so the patch will always cause the object to change, which will always cause the entry to be created.
/assign
/assign
/assign
Still seeing this, bumped into it over in
deflake in while the underlying issue is being worked on in
Change:
{ input: watch.Event{Object: nil}, pods:  []api.BoundPod{}, <del> fail:  true, </del> <ins> fail:  false, </ins> }, { input: watch.Event{Object: &api.BoundPods{}},

Discussion:
To reproduce: Start a cluster via hack/local-up- Start some pods Kill the cluster "docker ps -a" should show the pod containers running still Start the cluster again "etcdctl ls /registry" should show that there is no boundpods directory -- only minions and services "docker ps -a" should show the old pod containers still running Start a new pod After, say, 10s, "docker ps -a" should show the old containers dead /cc
I suspect the cause of this might be : which guarantees that the pod sync logic is never called if is nil. Need to get a repro to confirm.