jiebi/CodeConvo huggingface dataset:
Change:
config.createTestPods() epCount := len(config.EndpointPods) <ins> // Note that this is not O(n^2) in practice, because epCount SHOULD be < 10.  In cases that epCount is > 10, this would be prohibitively large. // Check maxNetProxyPodsCount for details. </ins> config.MaxTries = epCount*epCount + testTries framework.Logf("Setting MaxTries for pod polling to %v for networking test based on endpoint count %v", config.MaxTries, epCount) }

Discussion:
What happened: In CAPA clusters, NodePorts are disabled for UDP but not for TCP, so when testing, we see a small hole in coverage that was luckily caught by the tests.... So, I noticed that we thus don't have a targetted ginkgo test for UDP + nodeports, but we do seem to have the Contract one, which I guess tests two things at once: UDP NodePort service works Conntrack can persist the service We do have but this test is obviously testing many other things as well. So, would like to have a test.... What you expected to happen: running the sig-network test suite, while skipping with UDP not working would result in a test failure specific to UDP and NodePorts. How to reproduce it (as minimally and precisely as possible): Run the test suite, skip , with a UDP firewall up - you'll see no relevant failures. Anything else we need to know?: Environment: Kubernetes version (use ): master
/sig network
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
/assign
There is already one testing NodePort UDP in
However, the more tests the better :+1:
Hiya Antonio. I think the one your talking about in granular checks is also tagged as "Slow"..... Is there a FAST one? If so I'll close this issue don't want to make a redundant test . :)
I honestly don't know the history of the Slow tag and I don't see it consistently applied, but if you think that you can improve the Granular check and have an additional faster test, then just go for it :muscle:
ok cool
Change:
// set because it cannot be automatically converted. optional string apiVersion = 3; <del> // Time is timestamp of when these fields were set. It should always be empty if Operation is 'Apply' </del> <ins> // Time is the timestamp of when the ManagedFields entry was added. The // timestamp will also be updated if a field is added, the manager // changes any of the owned fields value or removes a field. The // timestamp does not update when a field is removed from the entry // because another manager took it over. </ins> // +optional optional Time time = 4;

Discussion:
Godoc says that Time should be empty on mangedFields entry created by "Apply" operation, but kubernetes populates time on apply. Godoc consistent with kubernetes behaviour Godoc: Kubernetes: No response <details</details<details</details<details</details<details</details<details</details<details</details
/wg api-expression /sig api-machinery
/cc
/cc /triage accepted
Yeah, good catch. The comment matches the behavior from alpha, which we changed later on. Thanks for letting us now :-) I think we could do a better job describing how this value is changed now.
Change:
safe-bind-mount "${ephemeral_mountpoint}/log_pods" "/var/log/pods" } <ins> # set journald configuration function setup-journald() { if [[ "${SET_JOURNALD_CONFIGURATION:-true}" = "true" ]]; then cat <<EOF > /etc/systemd/journald.conf [Journal] Storage=persistent SystemMaxUse=1G SystemMaxFileSize=100M RuntimeMaxUse=100M EOF systemctl restart systemd-journald.service fi } </ins> # Installs logrotate configuration files function setup-logrotate() { mkdir -p /etc/logrotate.d/

Discussion:
Example using a random PR for , take a look at: in this set of logs, at least 4 files are empty kube-container-runtime- kube-node- kube- kubelet- The reason tracked down using was that the journald configuration was defaulting to something that wipes the logs quickly!
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
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
Change:
// Extract the paths handled using mux handler. handledPaths = append(handledPaths, muxHelper.RegisteredPaths...) sort.Strings(handledPaths) <del> writeRawJSON(http.StatusOK, api.RootPaths{Paths: handledPaths}, w) </del> <ins> writeRawJSON(status, api.RootPaths{Paths: handledPaths}, w) </ins> } }

Discussion:
Authenticated requests to master with an invalid URL path should return a non-status 200 response code. Preferably a 404 (not found). Sample output: { "paths": [ "/api", "/api/v1beta1", "/api/v1beta2", "/api/v1beta3", "/healthz", "/healthz/ping", "/logs/", "/metrics", "/static/", "/swagger-ui/", "/swaggerapi/", "/validate", "/version" ] }
Change:
func updatePod(client clientset.Interface, pod *v1.Pod, condition *v1.PodCondition, nominatedNode string) error { klog.V(3).InfoS("Updating pod condition", "pod", klog.KObj(pod), "conditionType", condition.Type, "conditionStatus", condition.Status, "conditionReason", condition.Reason) <del> podCopy := pod.DeepCopy() </del> <ins> podStatusCopy := pod.Status.DeepCopy() </ins> // NominatedNodeName is updated only if we are trying to set it, and the value is // different from the existing one. <del> if !podutil.UpdatePodCondition(&podCopy.Status, condition) && </del> <ins> if !podutil.UpdatePodCondition(podStatusCopy, condition) && </ins> (len(nominatedNode) == 0 || pod.Status.NominatedNodeName == nominatedNode) { return nil } if nominatedNode != "" { <del> podCopy.Status.NominatedNodeName = nominatedNode </del> <ins> podStatusCopy.NominatedNodeName = nominatedNode </ins> } <del> return util.PatchPod(client, pod, podCopy) </del> <ins> return util.PatchPodStatus(client, pod, podStatusCopy) </ins> } // assume signals to the cache that a pod is already in the cache, so that binding can be asynchronous.

Discussion:
I am aware that the following is a corner case that does not occur in day-to-day business, but it took me a long while to debug, so I thought I would raise this issue to save others from the same pain. Deploying the following job with empty imagePullSecrets leads to it being stuck in forever, and status looking the following way: The status should look something like: This would allow my autoscaler to kick in and add the corresponding nodes. Run Kubernetes version (use ):Cloud provider or hardware configuration: AWS EKS OS (e.g: ): MacOSX 11.3 Kernel (e.g. ): Darwin Kernel Version 20.4.0 Install tools: brew
/sig scheduling (I assume)
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig scheduling (I assume) 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
/assign Scheduler log
Should we instead forbid empty items in ? Is there a use case for using as ?
For me personally that would be totally fine I had no use case for it. It was more produced by chance as I wasn't aware that I had to handle the case separately. An error which led to an early failure would have been fine by me and solved all my problems in tracking this down.
/assign as
Forbidding it is the appropriate solution. However, we can't do it for backwards compatibility of the API. /triage accepted
Change:
return false } <ins> func getServiceTags(service *v1.Service) ([]string, error) { if serviceTags, found := service.Annotations[ServiceAnnotationAllowedServiceTag]; found { tags := strings.Split(strings.TrimSpace(serviceTags), ",") for _, tag := range tags { // Storage and Sql service tags support setting regions with suffix ".Region" if strings.HasPrefix(tag, "Storage.") || strings.HasPrefix(tag, "Sql.") { continue } if !supportedServiceTags.Has(tag) { return nil, fmt.Errorf("only %q are allowed in service tags", supportedServiceTags.List()) } } return tags, nil } return nil, nil } </ins>

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind feature What happened: When using the loadBalancerSourceRanges property of a service in a manifest, we are force to use a CIDR block. This was discovered while debugging the following issue. What you expected to happen: Azure allows us to use Service Tags (e.g. VirtualNetwork, Internet, etc) WE should be able to specify them form a k8s service manifest. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.7.11 Cloud provider or hardware configuration: Azure OS (e.g. from /etc/os-release): centOS 7.3 Kernel (e.g. ): 3.10 Install tools: Others:
/sig azure
Here's the requested Feature.
SourceRanges is part of service spec, while serviceTag is azure specific. I think we don't expect to add cloud-specific features into Kubernetes API. What about adding a new annotation for this? e.g.
I believe that at this stage, (no out of tree cloud provider logic), using an annotation would be the only way to go unfortunately.
/priority important-soon
/status approved-for-milestone
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. : New functionality. </details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
Change:
expected: []*v1.Node{nodes[0], nodes[4], nodes[2]}, }, { <del> name: "Remove pod from non-existing node", </del> <ins> name: "Add pod before its node", operations: []operation{ addNode(0), addPod(1), updatePod(1), addNode(1), }, expected: []*v1.Node{nodes[1], nodes[0]}, }, { name: "Remove node before its pods", </ins> operations: []operation{ <del> addNode(0), addPod(0), addNode(2), updateSnapshot(), </del> <ins> addNode(0), addNode(1), addPod(1), addPod(11), removeNode(1), updatePod(1), updatePod(11), removePod(1), removePod(11), </ins> }, <del> expected: []*v1.Node{nodes[2], nodes[0]}, </del> <ins> expected: []*v1.Node{nodes[0]}, </ins> }, { name: "Add Pods with affinity",

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: If we delete node first, then remove pods on this node, the scheduler will crash in function What you expected to happen: Not crashed How to reproduce it (as minimally and precisely as possible): some pods on node A delete node A delete pods on node A Anything else we need to know?: Environment: Kubernetes version (use ): 1.16-1.18, even master Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig scheduling
can you show the core dump please of this crash?
/assign
I patched the unit test shown in into the , and branches. None crashed. I'll await for the crash dump.
Here is the fresh dump.
and which version was this?
This is master branch. And I've tested it from 1.16-1.18, it can be reproduced easily.
Thanks a lot. I was able to finally reproduce in unit tests. The scenario is: a node with at least 2 pods. node. pod1. In unit test, this is first an update to set the termination timestamp. No issues up to this point. pod2. Again, first an update to set the termination timestamp. Here it crashes. I'm working on a fix.
It looks like this is not an issue in 1.17 and below, because we preserved a placeholder node where the operations occur. do you have stacktraces for 1.17 and 1.16?
Yes, it seems only be found at 1.18. :smile:
Change:
listeningPort := "" var l net.Listener <ins> var err error </ins> BeforeEach(func() { <del> l, err := net.Listen("tcp", ":0") </del> <ins> l, err = net.Listen("tcp", ":0") </ins> if err != nil { framework.Failf("Failed to open a new tcp port: %v", err) }

Discussion:
Failure cluster: This is the most prevalent flake for release-blocking postsubmit kubelet builds, eg: (notably, it happens far less often here) ref: we're probably going to need to ignore kubelet-1.8 for cutting a release
/kind flake /priority test-failure
could you take a look? /assign
Looking to the problem
Change:
<del> /* Copyright 2015 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package priorities import ( "fmt" v1 "k8s.io/api/core/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" v1helper "k8s.io/kubernetes/pkg/apis/core/v1/helper" framework "k8s.io/kubernetes/pkg/scheduler/framework/v1alpha1" schedulernodeinfo "k8s.io/kubernetes/pkg/scheduler/nodeinfo" ) // CalculateNodePreferAvoidPodsPriorityMap priorities nodes according to the node annotation // "scheduler.alpha.kubernetes.io/preferAvoidPods". func CalculateNodePreferAvoidPodsPriorityMap(pod *v1.Pod, meta interface{}, nodeInfo *schedulernodeinfo.NodeInfo) (framework.NodeScore, error) { node := nodeInfo.Node() if node == nil { return framework.NodeScore{}, fmt.Errorf("node not found") } var controllerRef *metav1.OwnerReference if priorityMeta, ok := meta.(*priorityMetadata); ok { controllerRef = priorityMeta.controllerRef } else { // We couldn't parse metadata - fallback to the podspec. controllerRef = metav1.GetControllerOf(pod) } if controllerRef != nil { // Ignore pods that are owned by other controller than ReplicationController // or ReplicaSet. if controllerRef.Kind != "ReplicationController" && controllerRef.Kind != "ReplicaSet" { controllerRef = nil } } if controllerRef == nil { return framework.NodeScore{Name: node.Name, Score: framework.MaxNodeScore}, nil } avoids, err := v1helper.GetAvoidPodsFromNodeAnnotations(node.Annotations) if err != nil { // If we cannot get annotation, assume it's schedulable there. return framework.NodeScore{Name: node.Name, Score: framework.MaxNodeScore}, nil } for i := range avoids.PreferAvoidPods { avoid := &avoids.PreferAvoidPods[i] if avoid.PodSignature.PodController.Kind == controllerRef.Kind && avoid.PodSignature.PodController.UID == controllerRef.UID { return framework.NodeScore{Name: node.Name, Score: 0}, nil } } return framework.NodeScore{Name: node.Name, Score: framework.MaxNodeScore}, nil } </del>

Discussion:
/sig scheduling /priority important-soon See as an example. Part of This shouldn't need a PostFilter Plugin, it is not worth caching the result of metav1.GetControllerOf. /assign
Change:
// IsNodeUnmanagedByProviderID returns true if the node is not managed by Azure cloud provider. // All managed node's providerIDs are in format 'azure:///subscriptions/<id>/resourceGroups/<rg>/providers/Microsoft.Compute/.*' func (az *Cloud) IsNodeUnmanagedByProviderID(providerID string) bool { <del> return azureNodeProviderIDRE.Match([]byte(providerID)) </del> <ins> return !azureNodeProviderIDRE.Match([]byte(providerID)) </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?: /kind bug What happened: When creating a Kubernetes 1.12.1 cluster in Azure with Availability Set backed masters and VMSS backed agents, the cloud-controller-manager is unable to parse the ProviderID returned by the Azure SDK. What you expected to happen: The providerID should be split and the cloud-controller-manager should be able to find a kubelet node IP from the cloud provider How to reproduce it (as minimally and precisely as possible): Stand up a master node in Azure within an availability set with the kubelet configured with Run the configured for Azure Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Azure OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig azure
When switching over to vmType the following was encountered;
The fix in resolved the issue that was seen in this issue, closing
Change:
return nil, err } } return cadvisorClient, nil } <ins> func (cc *cadvisorClient) Start() error { return cc.Manager.Start() } </ins> func (cc *cadvisorClient) exportHTTP(port uint) error { mux := http.NewServeMux() err := cadvisorHttp.RegisterHandlers(mux, cc, "", "", "", "", "/metrics")

Discussion:
This is blocking (reboot test). In running a test that reboots all of the nodes and then runs the e2e tests, we saw a failure with the influxdb / heapster monitoring test: The heapster logs, from running (), shows a ton of the following kubelet errors for all containers (this one happens to be for skydns): The shows a bunch of 500 errors, such as: However, the apiserver thinks that all the pods are running ( gives this ) Docker thinks that the pods are running ( on that node gives this ) In summary: apiserver and docker think containers are running but kubelet can't find them this manifested in the influxdb / heapster monitoring e2e test after node reboot I've still got the cluster around if anyone would like to debug. +cc (helped me debug this (thanks!)) +cc (node) +cc (interested in getting in, which this is blocking)
Can I access your test nodes?
Is this an active problem? I'd check if the cAdvisor thinks the containers exist (it is the one returning the error). I'd then scan the logs to see if cAdvisor had any errors related to that container.
Unfortunately during debugging, I restart kubelet service on that node, the issue is gone. The problem could be cadvisor cannot get stats, but I couldn't find any cadvisor related error messages. How easy to reproduce the issue here? Next time we might access cadvisor's page to see if there is no such container information. Thanks!
(and Thanks for looking into this! I believe I can reproduce easily but I'll confirm. Where do I look for cAdvisor info? I don't see a log in or , and I don't see a cAdvisor container running?
cAdvisor is running as part of kubelet now. If you can reproduce the issue, could you please change kubelet's log level to 4 so that we have more cadvisor log here? Thanks!
Yes! How do I do that?

I can reproduce this by doing the following: After this, I got two failures: ... and I have another node with more of the same kubelet errors: (If I need to change the Kubelet log level at compile-time I can do that and repro on a new cluster; otherwise, I've got another cluster with the issue that can be introspected...)
There is a race between cadvisor initialization and docker. cadvisor failed to register docker factory, and bailed out. is going to make cadvisor more resilient to the issue of docker is not available, and have some retry logic. I am going to change kubelet initialization logic a little bit to make sure docker is running before we start cadvisor.
Awesome, thank you Dawn! Are there issues or PRs I can follow to know when this is unblocked?
is one of them. is working on the second.
Change:
// Lookup implements PluginHandler func (h *defaultPluginHandler) Lookup(filename string) (string, error) { <del> // if on Windows, append the "exe" extension // to the filename that we are looking up. if runtime.GOOS == "windows" { filename = filename + ".exe" } </del> return exec.LookPath(filename) }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently, the kubectl plugins system - when running under Windows - will determine that a plugin is executable by looking at the plugin's extension, comparing it to '.exe'. I think we should allow plugins w/ a few more known extensions (.bat, .com, .cmd; for example). Why is this needed: This would give more of a similar experience to plugins under *nix, where shell scripts are often used.
/sig cli
Please see the PR below:
Change:
k8s-app: elasticsearch-logging addonmanager.kubernetes.io/mode: Reconcile subjects: <del> - kind: ServiceAccount name: elasticsearch-logging namespace: kube-system apiGroup: "" </del> <ins> - kind: ServiceAccount name: elasticsearch-logging namespace: kube-system apiGroup: "" </ins> roleRef: kind: ClusterRole name: elasticsearch-logging

Discussion:
What happened: I download fluentd-elasticsearch in addons. The following error occurs then I use "kubectl apply -f es- " Then, i find the elasticsearch-logging pod restart lots of time, and keep status with CrashLoopBackOff. [root ~]# kubectl logs -f elasticsearch-logging-0 -n kube-system export NODENAME=elasticsearch-logging-0 NODENAME=elasticsearch-logging-0 export NODEMASTER=true NODEMASTER=true export NODEDATA=true NODEDATA=true export HTTPPORT=9200 HTTPPORT=9200 export TRANSPORTPORT=9300 TRANSPORTPORT=9300 export MINIMUMMASTERNODES=2 MINIMUMMASTERNODES=2 chown -R elasticsearch:elasticsearch /data ./bin/elasticsearchloggingdiscovery I0902 14:25:06. 9 ] Kubernetes Elasticsearch logging discovery I0902 14:25:06. 9 ] Found [] I0902 14:25:16. 9 ] Found [] I0902 14:25:26. 9 ] Found [] I0902 14:25:36. 9 ] Found [] I0902 14:25:46. 9 ] Found [] I0902 14:25:56. 9 ] Found []
unclear whether the addon is up to date and supported at this point. /sig instrumentation
cc
/assign I will take a look this week.
I have the same problem k8s version:v1.18.8
same
I've pushed a change to the stateful set that should unblock people as there was a 1.18 compatibility problem. however, please make sure you are also creating the service via , the discovery program finds the other elasticsearch nodes via service registration.
please feel free to re-open this issue if the latest version doesn't work for you.
Why was this PR to v1.20?
probably because that is the next release. most people who use this addon do so from master. Do you need this packaged in some other way?