jiebi/CodeConvo huggingface dataset:
Change:
schedulerlisters "k8s.io/kubernetes/pkg/scheduler/listers" ) <ins> const ( // ErrReasonConstraintsNotMatch is used for PodTopologySpread filter error. ErrReasonConstraintsNotMatch = "node(s) didn't match pod topology spread constraints" ) </ins> // PodTopologySpread is a plugin that ensures pod's topologySpreadConstraints is satisfied. type PodTopologySpread struct { sharedLister schedulerlisters.SharedLister

Discussion:
Part of /priority important-soon See example /sig scheduling /kind cleanup
/help
/assign
/remove-help
Change:
{ "SelectorRegexp": "k8s[.]io/kubernetes/third_party/", "AllowedPrefixes": [ <del> "k8s.io/kubernetes/third_party/forked/golang/expansion" </del> <ins> "k8s.io/kubernetes/third_party/forked/golang/expansion" </ins> ], "ForbiddenPrefixes": [] },

Discussion:
What happened: There is to manage import ways under but that doesn't work at our upstream CI. We can enable it by But if doing that, we will face the following error with What you expected to happen: I hope the check is always running to block invalid import ways at upstream CI system. How to reproduce it (as minimally and precisely as possible): As line into arguments.InputDirs of
/sig testing /area e2e-test-framework
Change:
"k8s.io/apiserver/pkg/endpoints/handlers/responsewriters" endpointmetrics "k8s.io/apiserver/pkg/endpoints/metrics" genericapirequest "k8s.io/apiserver/pkg/endpoints/request" <ins> genericfeatures "k8s.io/apiserver/pkg/features" utilfeature "k8s.io/apiserver/pkg/util/feature" </ins> utilflowcontrol "k8s.io/apiserver/pkg/util/flowcontrol" apiserverproxyutil "k8s.io/apiserver/pkg/util/proxy" "k8s.io/apiserver/pkg/util/x509metrics" "k8s.io/client-go/transport" <ins> "k8s.io/component-base/tracing" </ins> "k8s.io/klog/v2" apiregistrationv1api "k8s.io/kube-aggregator/pkg/apis/apiregistration/v1" apiregistrationv1apihelper "k8s.io/kube-aggregator/pkg/apis/apiregistration/v1/helper"

Discussion:
Extension API servers do not currently receive the header when requests are proxied through kube-aggregator, so spans are not linked properly. Traces from the extension API sever should be linked to the parent in kube-aggregator. tracing for kube-apiserver tracing for sample-apiserver and aggregate it to kube-apiserver a request to kube-apiserver for one of the resources from sample-apiserver sample-apiserver traces will not be linked to the kube-apiserver traces No response <detailsThis problem currently exists on . </details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/cc /triage accepted
Change:
} func MakeFakeEtcdClient(t *testing.T) *FakeEtcdClient { <del> return &FakeEtcdClient{ </del> <ins> ret := &FakeEtcdClient{ </ins> t:    t, Data: map[string]EtcdResponseWithError{}, } <ins> // There are three publicly accessible channels in FakeEtcdClient: //  - WatchResponse //  - WatchInjectError //  - WatchStop // They are only available when Watch() is called.  If users of // FakeEtcdClient want to use any of these channels, they have to call // WaitForWatchCompletion before any operation on these channels. // Internally, FakeEtcdClient use condWatchCompleted to indicate if the // Watch() method has been called. WaitForWatchCompletion() will wait // on condWatchCompleted. By the end of the Watch() method, it will // call Broadcast() on condWatchCompleted, which will awake any // goroutine waiting on this condition. ret.condWatchCompleted = sync.NewCond(&ret.condLock) return ret </ins> } func (f *FakeEtcdClient) AddChild(key, data string, ttl uint64) (*etcd.Response, error) {

Discussion:
Detected by
Create a Pod as follows: Name: jenkins Using image: jenkins In a new Kubenetes namespace named website-frontend kubectl create ns website-frontend apiVersion: v1 kind: Pod metadata: name: jenkins namespace: website-frontend spec: containers: name: jenkins image: jenkins kubectl create -f
Change:
} } <ins> // TODO(phase1+) this we are missing args from the help text, there should be a way to tell cobra about it if len(args) == 0 && len(cfg.MasterAddresses) == 0 { return nil, fmt.Errorf("must specify master IP address (see --help)") } cfg.MasterAddresses = append(cfg.MasterAddresses, args...) </ins> if !skipPreFlight { fmt.Println("Running pre-flight checks") <del> err := preflight.RunJoinNodeChecks() </del> <ins> err := preflight.RunJoinNodeChecks(cfg) </ins> if err != nil { return nil, &preflight.PreFlightError{Msg: err.Error()} }

Discussion:
Environment: VMware CentOS Linux release 7.2.1511 (Core) kernel: 3.10.0-327.36.1.el7.x8664 Installed packages: kubeadm.x8664 1.5.0-0.alpha.0.1534.gcf7301f kubectl.x8664 1.4.0-0 kubelet.x8664 1.4.0-0 kubernetes-cni.x8664 0.3.0.1-0. docker-engine.x8664 1.11.2- docker-engine- 1.12.1- What happened: kubeadm init hangs indefintely after: kubeadm init <master/tokensgenerated token: "." <master/pkicreated keys and certificates in "/etc/kubernetes/pki" <util/kubeconfigcreated "" <util/kubeconfigcreated "" <master/apiclientcreated API client configuration <master/apiclientcreated API client, waiting for the control plane to become readykubeadm init What you expected to happen: Master node initialize Anything else do we need to know: Only the kubeadm and kublet processes are running. When I do docker ps no containers are running. If i type docker images the only image that has been downloaded are: I've also tried: kubeadm init --api-advertise-addresses but with the same outcome (followed the clean-up at ) Im behind a firewall so I'm using proxy settings for docker. I have confirmed I can reach images on docker hub and google cloud registry
will download the required binaries viz etcd. When you are behind firewall kubeadm will hang/wait forever to download the binaries. I dont know whether it is addressed correctly in kubeadm implementation. I am also facing the same issue and waiting for the resolution.
Thx, I suspected it to be some firewall issue. Do you know if there's a way to add httpsproxy & httpproxy settings to kubeadm?
Kubeadm doesn't seem to pick proxy environment variables. I am looking at recompiling with proxy support may work. But I dont know how to do that. Waiting for updates about proxy
This issue same as Lets join there. The solution mentioned there may work.

You can try kubeadm with patch applied from PR : It works at least in my environment behind restrictive proxy.
thanks, I will look into it
Change:
"k8s.io/kubernetes/pkg/volume/util/volumepathhandler" ) <ins> const ( unknownVolumePlugin string = "UnknownVolumePlugin" ) </ins> var _ OperationGenerator = &operationGenerator{} type operationGenerator struct {

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!--What happened: In this test, volume mount failed because the driver-registrar took a minute to come up. However, it seems like volume mount operation is retrying without any sort of backoff. This message appears in 400+ times in less than a minute. What you expected to happen: Operation executor should not be retrying operations so frequently. <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
I'll take a look at this. /assign
Problem is that reconciler depends on operation executor to do backoff. In the normal case operation executor returns a method that does the actual work. Any errors by that method result in exponential backoff. But in this case, the error is coming from the code creating the mount method which is not handled by the back off logic, and is called again and again by the reconciler resulting in log and event spam. This didn't use to be a problem because initialization errors were uncommon (plugins were built in), but with CSI the driver may not exist and these initialization errors are expected. I'll look in to cleaning this up.
Is this something that will affect users in 1.13 and needs CPing?
This will result in kubelet log spam and possibly kubernetes event spam. It happens when someone creates a pod referencing a CSI volume before the CSI driver for that volume is installed. Which happens frequently in E2E tests because they install/remove driver with every test. But should be rare in real world usage since most users are likely to install a driver first before using it.
If release team is worried about this, we could create a quick PR to suppress logging/event generation of this these errors. Otherwise we plan to address this more holistically for 1.14 and 1.13.1.
Change:
{ name:     "hpa-priority", arg:      "hpa", <del> expected: schema.GroupVersionResource{Resource: "superhorizontalpodautoscalers"}, </del> <ins> expected: schema.GroupVersionResource{Resource: "superhorizontalpodautoscalers", Group: "autoscaling"}, </ins> srvRes: []*metav1.APIResourceList{ { GroupVersion: "autoscaling/v1",

Discussion:
Copying the issue from Here is my CRD CRD Data Outputs Expected to see the resource list when kubectl get dpl Versions
/sig api-machinery /area custom-resources /kind bug
Can you check if the title is right for this case?
/cc
If you collide with another short name, you have to qualify with a group. It should follows normal resolution rules for priority
this isn't CRD-specific. isn't a colliding shortname. it expanded dpl -deployments, then resolved deployments against preferred group order, instead of limiting resolution to the group(s) that had the shortname
updated description to narrow the report to the case which is a bug
Did a little research, turn out kubectl will take as it's short name: I can give a shot to solve this problem, unless it's by design... : )
FYI. PR .
/assign
Change:
# Network Policy plugin specific settings. NETWORK_POLICY_PROVIDER="${NETWORK_POLICY_PROVIDER:-none}" # calico <ins> # Should the kubelet configure egress masquerade (old way) or let a daemonset do it? NON_MASQUERADE_CIDR="0.0.0.0/0" </ins> # How should the kubelet configure hairpin mode? HAIRPIN_MODE="${HAIRPIN_MODE:-promiscuous-bridge}" # promiscuous-bridge, hairpin-veth, none

Discussion:
https://k8s- is failing to run the follow up e2es because the ip-masq-agent daemonset is scheduling pods that get stuck in a pending state on 1.5 nodes. This short-circuits the logic for the skewed e2es, and they never run. from https://k8s-
So I see that in 1.7.0 we start setting the non-masq-cidr to 0/0 gce/config-"0.0.0.0/0" We set the addon if non-masq-cidr is 0/0 if [[ "${NONMASQUERADECIDR:-}" == "0.0.0.0/0" ]]; then setup-addon-manifests "addons" "ip-masq-agent" fi Also the agent cannot run on nodes prior to 1.7 so this seems to be correct. Once the nodes are upgraded to 1.7 then the ip-masq agent should be running and should get out of the pending state. I think this is just a general problem with the way addons are handled. I may want to enable a new addon when a master is upgraded to 1.7 by default. That addon may be a DaemonSet that wants to run on nodes meeting a certain criteria. That criteria may not be met in 1.5 but may be met when they are updated to 1.7. A few things that come to mind to fix this: -Fix the test's expectations to allow this until the nodes are updated to 1.7. -rollback the PR that made this the default: -set NONMASQUERADECIDR=10.0.0.0/8 in the test properties so that the ip-masq-agent doesn't get .
It seems like the most conservative way forward is to revert the PR (). Customers who want to use the feature can set the variable () during to be able to get the feature. What do you guys think?
I think I asked the similar question related to ip-masq-agent, but my question was dropped. At this stage, I think reverting the preferred fix.

ip-masq-agent was a daemonset introduced in 1.7 which I questioned at The problem is that after master is upgraded to 1.7, addons is trying to schedule ip-masq-agent daemonset to every node no matter which Kubelet version the node is on. The problem is that ip-masq-agent can only run on node with 1.7 release.
Even if we fix the test it doesn't fix GKE or any other environment where the master is upgraded to 1.7 and the nodes are < 1.7. I think the real problem here is that there is no distinction between staging an addon and enabling an addon. Essentially staging = running. So we end up adding labels to nodes as a way of keeping the DaemonSet disabled until those labels are to nodes. While that works fine for addons that are DaemonDets, it doesn't work for deployments and replica sets. I feel like this is going to happen again regardless of what we do here with ip-masq-agent. It also creates a secondary step. Who applies those addons? What if they forget? what if it's deleted?
Fixed by (the formatting wasn't quite right in the IR to auto-close this issue).
got reverted as it broke tests.
Change:
package etcd import ( <ins> "fmt" </ins> "github.com/GoogleCloudPlatform/kubernetes/pkg/api" kubeerr "github.com/GoogleCloudPlatform/kubernetes/pkg/api/errors" etcderr "github.com/GoogleCloudPlatform/kubernetes/pkg/api/errors/etcd"

Discussion:
The use of AtomicUpdate by genericetcd doesn't handle conflicting writes by rejecting that to a user. It should. Eventually, we may want to hide write conflicts to /pods when status has changed, and to spec when /pods/status changes, but that requires us to have two version counters and that's not worth the effort. Fix incoming.
Also we need a unit/integration test for this.
Change:
func (ts *fakeTokenSource) Token() (*azureToken, error) { return &azureToken{ token:       newFackeAzureToken(ts.accessToken, ts.expiresOn), <ins> environment: "testenv", </ins> clientID:    "fake", tenantID:    "fake", apiserverID: "fake",

Discussion:
What happened: AAD support in kubectl does not work for sovereign cloud The 'environment' parameter was introduced to support sovereign cloud, but it works in first round. The 'environment' value is not persisted, so follow-up requests will fail. What you expected to happen: 'environment' parameter persisted in kubectl config file. How to reproduce it (as minimally and precisely as possible): Use kubectl to connect to Azure sovereign cloud, make the token expire, and do auth. Anything else we need to know?: Environment: Kubernetes version (use ): 1.11 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
There are no sig labels on this issue. Please add a sig label 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. <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
Change:
.:53 { errors health <ins> ready </ins> kubernetes __PILLAR__DNS__DOMAIN__ in-addr.arpa ip6.arpa { pods insecure <del> upstream </del> fallthrough in-addr.arpa ip6.arpa ttl 30 }

Discussion:
Which jobs are failing: Multiple jobs on . Which test(s) are failing: on the following jobs: Since when has it been failing: Since 5/17. Testgrid links: See above. Reason for failure: All the failures mentioned above seem to have to have the same root cause, namely failure while waiting for CoreDNS to be ready. Example: /sig testing /priority critical-urgent /kind failing test /milestone v1.15 /cc
Some of this (possible all of it) is due to , which is dependent on being merged.
/sig cluster-lifecycle
Not the gce jobs thoght. Only the kinder job. So the gce jobs are failing with a problem outside of kubeadm/kinder but possibly still related to the corefile plugin change
/assign (At kubecon this week)
The gce failures appear to show the same behavior, but with kube-up instead of kubeadm. I.e. it appears that kube-up may also be retaining old configs when upgrading/downgrading. If thats true, then we may need to integrate the migration tools into kube-up as well.
I have opened which aims to fix all the failing tests except , which will be fixed via
Great job so far and Would it be possible to ask for the open PRs to be merged and/or a solution found soon? We have these tests failing for quite some time and code freeze coming up in the next days. Thank you in advance for your efforts!
thanks for the heads up. let me know if you don't have the time for the refactor that i requested and i can try to take over there. the alternative is to rollback the coredns version which i assume is not ideal, due to a variety of fixes in the new version.
is there any more work planned for this issue? I see that some of the kinder jobs are still failing after merged:
merging and will resolve and close this issue.
Thank you for the update !
updates: kinder tests were fixed via
/unassign i was here for: it's a bit flaky (which is due to the tooling), but green.
Since and we're moved to 1.16, and we're waiting for to merge, can we move this issue to 1.16?
? is that the right PR?

Good catch, I meant
The GCE test failures were fixed by and /close
Closing this issue. <detailsIn response to : The GCE test failures were fixed by and /close 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:
} func getPhysicallyInstalledSystemMemoryBytes() (uint64, error) { <del> var physicalMemoryKiloBytes uint64 if ok := getPhysicallyInstalledSystemMemory(&physicalMemoryKiloBytes); !ok { </del> <ins> // We use GlobalMemoryStatusEx instead of GetPhysicallyInstalledSystemMemory // on Windows node for the following reasons: // 1. GetPhysicallyInstalledSystemMemory retrieves the amount of physically // installed RAM from the computer's SMBIOS firmware tables. // https://msdn.microsoft.com/en-us/library/windows/desktop/cc300158(v=vs.85).aspx // On some VM, it is unable to read data from SMBIOS and fails with ERROR_INVALID_DATA. // 2. On Linux node, total physical memory is read from MemTotal in /proc/meminfo. // GlobalMemoryStatusEx returns the amount of physical memory that is available // for the operating system to use. The amount returned by GlobalMemoryStatusEx // is closer in parity with Linux // https://www.kernel.org/doc/Documentation/filesystems/proc.txt var statex MemoryStatusEx statex.Length = uint32(unsafe.Sizeof(statex)) ret, _, _ := procGlobalMemoryStatusEx.Call(uintptr(unsafe.Pointer(&statex))) if ret == 0 { </ins> return 0, errors.New("unable to read physical memory") } <del> return physicalMemoryKiloBytes * 1024, nil // convert kilobytes to bytes } func getPhysicallyInstalledSystemMemory(totalMemoryInKilobytes *uint64) bool { ret, _, _ := syscall.Syscall(procGetPhysicallyInstalledSystemMemory.Addr(), 1, uintptr(unsafe.Pointer(totalMemoryInKilobytes)), 0, 0) return ret != 0 </del> <ins> return statex.TotalPhys, nil </ins> }

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: Windows uses GetPhysicallyInstalledSystemMemory to get physical memory installed on Windows machine and reports it as part of node metrics to heapster, etc. On VMWare Fusion, GetPhysicallyInstalledSystemMemory fails to read data from SMBIOS firmware tables and returns error code 0x0d. That causes on Windows to bail out. It is also reported on Virtualbox. What you expected to happen: Windows should be able read to physical memory on the system and shouldn't exit. How to reproduce it (as minimally and precisely as possible): Run on VMWare Fusion or Virtualbox . Anything else we need to know?: Environment: Kubernetes version (use ): latest Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Windows Kernel (e.g. ): Install tools: Others: VMWare Fusion or Virtualbox
/sig windows /sig node
this will likely get fixed after 1.9 is released
Sure, I am fixing it. Unfortunately it missed the 1.9 train.
Hi, any idea on when this might get fixed? Thanks!
It is fixed in Got test failure in pull-kubernetes-e2e-kops-aws yesterday but not before. I will look into it shortly.
thanks for the swift reply! I need to learn some new (for me) github skills to get that PR.
i just approved the PR again. we should be good to go. can you please check
Change:
attribute.Stringer("client", &lazyClientIP{req: req}), attribute.String("protocol", req.Proto), attribute.Stringer("resource", &lazyResource{req: req}), <ins> attribute.Stringer("scope", &lazyScope{req: req}), </ins> attribute.String("url", req.URL.Path), attribute.Stringer("user-agent", &lazyTruncatedUserAgent{req: req}), attribute.Stringer("verb", &lazyVerb{req: req}),

Discussion:
One of the use-cases for APIServer tracing would be to try and debug SLO-violating requests served by the API Server. Right now, it adds just some basic attributes: For API Server , SLO-related metrics have the following labels: "verb", "dryrun", "group", "version", "resource", "subresource", "scope", "component", "code" We should add those labels to at least one of the spans created by API Server requests. It isn't a graduation requirement for , but would make the feature more helpful.
/sig instrumentation
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
We might be able to do something using RequestInfo, similar to how the dropped request metric is recorded:
Change:
} return false } <ins> //GetQuotaServiceType returns ServiceType if the service type is eligible to track against a quota, nor return "" func GetQuotaServiceType(service *api.Service) api.ServiceType { switch service.Spec.Type { case api.ServiceTypeNodePort: return api.ServiceTypeNodePort case api.ServiceTypeLoadBalancer: return api.ServiceTypeLoadBalancer } return api.ServiceType("") } </ins>

Discussion:
master-informing: capz-windows-containerd-master capz-e2e.[It] Conformance Tests conformance-tests ! 2023-03-10 04:56:51 +0000 UTC No response /sig testing
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : ### Which jobs are failing? ### Since when has it been failing? /sig testing Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig windows /triage accepted
no major change between passing test on 3/9 17:55 PST and failing test on 3/9 20:56 PST
containerd logs have error about failing to unpack azure-cloud-manager on both nodes:
kubelet logs confirm this:
looks to be related to bumping capz to 1.8 which uses the cloud-provider oot image: caused by upgrading to 1.8 capz in combination with using OOT
This looks to be affecting our release jobs as well:
looks like the image being built is linux only () and is being pulled by windows. When setting up the snapshot in containerd it is failing (as it is missing files required by windows)
For the passing test the image is multi-arch manifest, so the windows image pulls properly (azure-cloud-node-manager:)
There is a missing env in the see