jiebi/CodeConvo huggingface dataset:
Change:
// referenced by the pod spec. If visitor returns false, visiting is short-circuited. // Transitive references (e.g. pod -> pvc -> pv -> secret) are not visited. // Returns true if visiting completed, false if visiting was short-circuited. <del> func VisitPodSecretNames(pod *api.Pod, visitor Visitor) bool { </del> <ins> func VisitPodSecretNames(pod *api.Pod, visitor Visitor, containerType ContainerType) bool { </ins> for _, reference := range pod.Spec.ImagePullSecrets { if !visitor(reference.Name) { return false } } <del> VisitContainers(&pod.Spec, AllContainers, func(c *api.Container, containerType ContainerType) bool { </del> <ins> VisitContainers(&pod.Spec, containerType, func(c *api.Container, containerType ContainerType) bool { </ins> return visitContainerSecretNames(c, visitor) }) var source *api.VolumeSource

Discussion:
Fully described in , and will visit these fields for all containers, regardless of whether they're hidden behind a feature gate (e.g. ). This is usually correct, these methods are often used to drop fields and in this case should visit all containers that are persisted regardless of whether they're disabled, but the callers of these methods should signal that explicitly rather than relying on the implicit behavior. /cc /priority important-longterm /kind bug /sig node
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : Fully described in , and will visit these fields for all containers, regardless of whether they're hidden behind a feature gate (e.g. ). /priority important/long-term /kind bug /sig node 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
are you interested in taking this one, too?
VisitPodSecretNames and VisitPodConfigmapNames already specify AllContainers for VisitContainers Can you let me know what else needs to be done?
Callers should specify whether they want to visit all containers or not. There are valid reasons for each, so we shouldn't assume the desired behavior, even if 100% of the current users want to visit all containers. Jordan's original comment in has some examples of current uses. I don't think this needs to be as configurable as , so my naive first attempt to implement this would probably just be a new to and
Change:
.PHONY:	build push PREFIX=gcr.io/google_containers <del> TAG = 1.34 </del> <ins> TAG = 1.35 </ins> build: docker build --pull -t $(PREFIX)/fluentd-gcp:$(TAG) .

Discussion:
<!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): no What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): fluentd timezone timeformat Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): What happened: Log lines from docker have the wrong timestamp. Anything else do we need to know: We are building a custom Docker Image for fluentd/td-agent which is based on your Dockerfile but with some slight changes. One of which is that we set the timezone to something else than UTC. In this case fluentd will produce wrong timestamps for log lines since the string only includes a simple Z in the end. Changing the time_format to fixed the problem for us. Of course this is not really a bug in kubernetes but changing the default to the above will probably help others in the future.
Thanks for reporting! It seems to be a bug
Change:
// Setup expectations. const ( <del> kb = 1000 mb = 1000 * kb gb = 1000 * mb tb = 1000 * gb </del> <ins> kb int64 = 1000 mb int64 = 1000 * kb gb int64 = 1000 * mb tb int64 = 1000 * gb </ins> maxStartAge = time.Hour * 24 * 365 // 1 year maxStatsAge = time.Minute

Discussion:
Bug report. Kubernetes version (use ): Build of master branch commit Environment: Ubuntu 16.04, 24GB memory, 8 cores (parallel compilation used as 11GB memory) Linux gbhc1 4.4.0-38-generic -Ubuntu SMP Tue Sep 6 15:42:33 UTC 2016 x8664 x8664 x8664 GNU/Linux What happened: Following the build-from-source directions, I cloned kubernetes; cd &lt;dir&gt;; make release This fails with : +++ [0929 09:16:04] linux/amd64: go build started +++ [0929 09:17:42] linux/amd64: go build finished +++ [0929 09:16:04] linux/arm: go build started # constant overflows int constant overflows int constant overflows int constant overflows int constant overflows int constant overflows int constant overflows int constant overflows int +++ [0929 09:16:04] linux/arm64: go build started +++ [0929 09:18:06] linux/arm64: go build finished Makefile:79: recipe for target 'all' failed make[1]:  [all] Error 1 Makefile:255: recipe for target 'cross' failed make:  [cross] Error 1 Makefile:239: recipe for target 'release' failed make:  [release] Error 1 What you expected to happen: A successful build How to reproduce it (as minimally and precisely as possible): make release Anything else do we need to know: gavin awk '(NR==57 NR==183) {print}' < fsCapacityBounds := bounded(100mb, 100gb) "AvailableBytes": bounded(100mb, 100gb), "UsageBytes": bounded(10mb, 10gb), "WorkingSetBytes": bounded(10mb, 10gb), "RxBytes": bounded(1mb, 100gb), "TxBytes": bounded(10kb, 10gb), "UsedBytes": bounded(kb, 10gb),
can you look into this build failure please?
oh, this was broken by a PR that went in yesterday, .
Change:
FEATURE_GATES: $(yaml-quote ${FEATURE_GATES}) EOF fi <ins> if [[ "${master}" == "true" && "${MASTER_OS_DISTRIBUTION}" == "gci" ]] || [[ "${master}" == "false" && "${NODE_OS_DISTRIBUTION}" == "gci" ]]; then cat >>$file <<EOF VOLUME_PLUGIN_DIR: $(yaml-quote ${VOLUME_PLUGIN_DIR:-/home/kubernetes/flexvolume}) EOF fi </ins> if [ -n "${PROVIDER_VARS:-}" ]; then local var_name

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?: Feature Default FlexVolume driver directory is , which is not writable on COS images. Should have a different default directory to enable FlexVolume on COS. /kind feature /assign
/sig storage
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <bre.g., for API Machinery<br(2) specifying the label manually: <bre.g., for sig/scalability<br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list
Change:
) (string, error) { klog.V(4).Infof(log("blockMapper.publishVolumeForBlock called")) <del> publishVolumeInfo := attachment.Status.AttachmentMetadata </del> <ins> publishVolumeInfo := map[string]string{} if attachment != nil { publishVolumeInfo = attachment.Status.AttachmentMetadata } </ins> nodePublishSecrets := map[string]string{} var err error

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: During I develop a driver that supports raw block devices but do not need to be attached to nodes, I found it would fail when a pod mount a raw block device. PS: I use cluster-driver register and make requiredAttach as false. kubectl get csidriver csi-xxx -o yaml ! What you expected to happen: Mount a raw block device successfully. How to reproduce it (as minimally and precisely as possible): driver that supports raw block devices but do not need to be attached to nodes, I found it would fail when a pod mount a raw block device. cluster-driver register and make requiredAttach as false. a pod with raw block devices Anything else we need to know?: Environment: Kubernetes version (use ): 1.15 Cloud provider or hardware configuration: BaiduCloud OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig storage /assign
I would send a PR later
Change:
return expectNodes[i].ID() < expectNodes[j].ID() }) startNodes := c.start.graph.Nodes() <del> sort.Slice(expectNodes, func(i, j int) bool { </del> <ins> sort.Slice(startNodes, func(i, j int) bool { </ins> return startNodes[i].ID() < startNodes[j].ID() }) assert.Equal(t, expectNodes, startNodes)

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: Pulled master and ran: $ make test I get test failure for TestDeleteEdges_locked in What you expected to happen: I expected all tests to run successfully How to reproduce it (as minimally and precisely as possible): Run $ make test, using the most recent version of master (head at commit ), observe that test fails. Anything else we need to know?: This is my first issue, so please let me know if I need to provide any other information! Environment: Kubernetes version (use ): upstream/master (head at commit ) OS (e.g. from /etc/os-release): macOs 10.13.3
/sig testing
/assign
/priority failing-test
This looks like a flaky test. I wonder if the ordering is no longer guaranteed stable in go1.10?
nope, typo in the sorting the test did. fix incoming
/assign
Change:
APIListChunking: {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.32 <del> APIPriorityAndFairness: {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.31 </del> APIResponseCompression: {Default: true, PreRelease: featuregate.Beta}, APIServerIdentity: {Default: true, PreRelease: featuregate.Beta},

Discussion:
Priority and Fairness is going GA in 1.29, the feature has been marked stable and the feature gate has been locked to default. See In 1.31, we need to remove the feature gate.
/kind bug /sig api-machinery /cc
/assign
/triage accepted
Change:
Email    string } <ins> const ( readURLTimeout = time.Second * 20 ) </ins> var ( preferredPathLock sync.Mutex preferredPath     = ""

Discussion:
http://pr-
Something holding the port already?
The previous masterless case just barely passed with a 12.5 second timeout (25 tries at 0.5 second interval) I think we just need to increase the timeout.
I randomly sampled 5 green builds and they all have this test (starting kubelet in masterful/less mode) finished in 3s or less. Judging for the successful masterless mode startup before the failure, kubelet spent the most time trying to register credential providers (a 10s gap in the log). The same roughly applies to the failed "masterful mode", based on where the log message stopped. From , the registering process basically tries to access the metadata url to see if the credential provider is enabled. I think this may just be the slow response from the metadata server.
I am wondering even if this issue might be related to a slow response from the metadata server, why it does not show "Registering credential provider: .dockercfg" always in failed logs?
If there is a possibility that ReadUrl in may take longer than expected, would it be preferred to use a Timeout (0) with the http client to not get stuck longer than expected?
I am unsure why it didn't show that, but even in the passing round we see a 10 second gap, which almost maxed out the timeout. I think adding a timeout is reasonable, but I am not sure what value is reasonable given that the previous request took 10s. do you have any idea?
Even I am not sure exactly what should be a reasonable value. My guess would be that if in normal cases, average response time is x seconds (perhaps a guestimate could be computed based on "normal" successful tests), then x could be a starting point, or otherwise another option is choosing something randomly (like 5s). And I think that if at some point, the server is responding in 10s, and even though the test passes, its not normal and something is going wrong.
uses a 10 second timeout, but the request will be retried. Given that we don't retry this request, a short timeout is worrisome. Maybe we should add both retry and timeout in this case.
SGTM.
I reopen this one since pr was reverted.

Noticed a similar hang in: The logs are a bit different from those observed in
if kubelet couldn't start up properly, the test itself should've timed out and logged "Timed out waiting for kubelet to answer at http://127.0.0.1:/healthz; tried 25 waiting 0.5 between each". I am not sure if this failure is related.
failure is not relevant to this issue. The most recent report of such flake was over a week ago. I think the cause is the slow metadata url response in GCE, and that should've been fixed by the recent rollout. I am going to close this issue. Feel free to reopen if there is another occurrence.
Change:
testCases := []struct { name string <ins> isIPv6Primary          bool </ins> enableDualStack        bool specExpctPrimary       bool clusterIPExpectPrimary bool

Discussion:
What happened: When K8s is started in dual-stack mode with IPv6 as the "main" (or base) family services specified with ipFamily:IPv4 still get a ipv6 ; The is expicitly set to "10.0.0.0" using . What you expected to happen: Services with ipFamily:IPv4 shall get ipv4 ClusterIP addresses. How to reproduce it (as minimally and precisely as possible): Setup a K8s cluster in dual-stack mode with family IPv6 as base Define a service with ipFamily: IPv4 To make K8s think IPv6 is the main family the cue is to define ipv6 addresses to K8s binaries. Below are my settings as an example. I do not use but install "from scratch"; Master processes; is accessed with ipv4 which does not affect the K8s family. Worker processes; Anything else we need to know?: There are other problems with dual-stack/ipv6-base but may be caused by this one. For example does not work and some processes does not become "ready". Ipv6 traffic to ipv6 services and DNS works; Environment: Kubernetes version (use ):Cloud provider or hardware configuration: - OS (e.g: ): BusyBox based own setup. Kernel (e.g. ):Install tools: "from scratch" Network plugin and version (if this is a network-related bug): Others:
/sig network /cc
The problem seem to be; The problem occurs when an ipv6 range is specified first, even in an ipv4-based dual-stack cluster. But the ipv6 range must be specified first otherwise the "kubernetes" service gets an ipv4 address but an ipv6 backend; ~Perhaps the way to fix this problem is to make sure the service address is from the right family and require that the order to is "ipv4,ipv6".~ Bad idea!
There seem to be a option; But I can't see it in the help printout. I will try to use it...
:disappointed:
Here it where the kubernetes service address is set;
/assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
Change:
}, Spec: storage.VolumeAttachmentSpec{ NodeName: node, <del> Attacher: csiPluginName, </del> <ins> Attacher: csiSource.Driver, </ins> Source: storage.VolumeAttachmentSource{ PersistentVolumeName: &pvName, },

Discussion:
Internal volume plugin for CSI creates VolumeAttachment with (= the plugin name). It should be CSI driver name instead, as the external attacher must know which CSI driver to call. /sig storage /kind bug please prioritize PTAL. It should be one-line change in
[MILESTONENOTIFIER] Milestone Issue Current 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
ACK. In progress
Change:
}, "bound-pvc,pv-not-exists": { podPVCs:    []*v1.PersistentVolumeClaim{boundPVC}, <del> shouldFail: true, </del> <ins> shouldFail: false, reasons:    ConflictReasons{ErrReasonPVNotExist}, </ins> }, "prebound-pvc": { podPVCs:    []*v1.PersistentVolumeClaim{preboundPVC},

Discussion:
What would you like to be : Scheduler VolumeBinding plugin reports error when a PVC doesn't exist for example: We need to take a second look at the VolumeBinding plugin and make sure that errors are returned only when there is a system error, not a user error. Why is this needed: To fix the scheduler's error reporting metrics. /sig scheduling /sig storage /cc
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 I'll take a look.
If the PVC object does not exist, the plugin will return status. I guess you mean the plugin will return an error when a referenced PV does not exist? I've created a PR for this:
Thanks! The errors I am seeing are on 1.18 clusters, can we look at 1.18 and try to patch? This is still throwing the scheduler's error metrics off.
sure
I've submitted a patch for the 1.18 release branch:
I guess on the master branch should be reviewed and merged too? cc
hello! the fix you made only apply for 1.18? how about 1.19 and 1.17? thanks!
after the fix on the master branch () is merged, I'll cherry-pick it into the 1.19 branch (the code are almost the same). I'm not sure if it's necessary to fix the 1.17 branch. It's 3 versions behind 1.20.
hi, This is because of this patch: Do you think this fix needs to be cherry-picked into 1.19 and 1.18 branch too?
can you send a patch for 1.19?
ah, here it is
to sum up: master: 1.19: 1.18: and I think this change should be backported to 1.19/1.18 too: I'll send PRs soon.

summary of the issue that an error will be reported instead of UnschedulableAndUnresolvable when PVC not found: master: already implemented, see 1.19: 1.18: can't backport as it does not implement the PreFilter extension point
Change:
), }, expected: &DeviceRunContainerOptions{ <del> Annotations: []kubecontainer.Annotation{ {Name: "cdi.k8s.io/devicemanager_pod-container", Value: "vendor1.com/class1=device1,vendor2.com/class2=device2,vendor3.com/class3=device3"}, }, </del> CDIDevices: []kubecontainer.CDIDevice{ {Name: "vendor1.com/class1=device1"}, {Name: "vendor2.com/class2=device2"},

Discussion:
Kubelet should stop using annotations to pass CDI device IDs to CRI runtimes. CDIDevices CRI field should be used for this purpose. This should be done when Kubelet that doesn't support CRI field reaches EOL and two major CRI runtimes support CRI field. Here is a PR comment that gives more details about this: Kubelet started using CDIDevices CRI field in . Previous version 1.27 will reach EOL .CRI-O started using it in . Previous version 1.27 will reach EOL together with Kubernetes 1.27.Containerd started using it in . Version 1.7 will reach EOL in a 6 months after Containerd 2.0 release Previous version 1.6 doesn't support CDI injections and should not be considered. So, safer option would be to wait until Containerd 1.7 reaches EOL. However it's relatively safe to do it earlier when 1.7.0 and 1.7.1 have little chances to be in real use. Containerd v1.7.0 and v1.7.1 is not used by the Linux distributions from , so it's safe to remove annotations support from the Kubelet in 1.31 in my opinion.
/sig node
/triage accepted /priority important-longterm
/assign
Change:
Namespace:        foo Address: Ingress Class:    test <del> Default backend:  default-http-backend:80 (<error: endpoints "default-http-backend" not found>) </del> <ins> Default backend:  <default> </ins> Rules: Host         Path  Backends ----         ----  --------

Discussion:
I ran on a fresh minikube with no other services in it and saw this output. Which suggests there is a service in the cluster called (there isn't), and further suggests there is something wrong (there isn't) because there are no endpoints found. I expected to provide me with an accurate description of my Ingress object. This behaviour appears to be hardcoded into the kubectl describe command. Which contains a comment suggesting that this is default behaviour, but no logic to check if the service actually exists before attempting to default to it. <details</details<details</details<details</details<details</details<details</details<details</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
/sig cli
See also do you know the history here?
not beyond what shows: Looks like an (incorrect) assumption in the describer that the only implementation would behave in this way
/assign
work in progress...
when you get the PR up please link this issue and in it and ping me directly on slack to get a fast review. I agree with what was stated here and in the other issue, that this seems like an unnecessary assumption that should've not been there, we probably should just leave it empty or per print as the value.
Change:
--disk name="${MASTER_NAME}-pd" device-name=master-pd mode=rw boot=no auto-delete=no } <ins> # TODO(mbforbes): Make $1 required. # TODO(mbforbes): Document required vars (for this and call chain). # $1 version </ins> function create-node-instance-template { <del> create-node-template "${NODE_INSTANCE_PREFIX}-template" "${scope_flags[*]}"  </del> <ins> local suffix="" if [[ -n ${1:-} ]]; then suffix="-${1}" fi create-node-template "${NODE_INSTANCE_PREFIX}-template${suffix}" "${scope_flags[*]}"  </ins> "startup-script=${KUBE_ROOT}/cluster/gce/configure-vm.sh"  "kube-env=${KUBE_TEMP}/node-kube-env.yaml" }

Discussion:
See issue as the roll-up for node upgrades. tl;dr: Update MIG template, then call a MIG rollingupdate. More details: When upgrading nodes, an in-place upgrade must worry about leftover state on the boot disk, VM configuration like IP tables, and the idempotency of salt. Getting a fresh VM instead would remove these concerns and provide a clean state for a new node. Furthermore, a versioned node spec () includes the tuple of (kubelet, kube-proxy, docker, kernel/OS). In the general case, changing docker or the kernel/OS means we have to stop the running pods. Once know we have to stop the pods, the simplest upgrade mechanism is to totally down the node and provision a new one. Provisioning a new node is also a great backup to have for node repairs. To be clear, though, this issue is entirely separate from node repairs; once we have the capability to grow the cluster by adding new nodes, this mechanism, and other repair mechanisms, will build on top of that capability. This was blocked by: nodes joining a running cluster (template-only metadata) References: The most relevant discussion regarding the worries of complications with state while doing in-place upgrades is .
FWIW, I think we need this as a fallback to repair completely borked nodes? That is, it may not be necessary for upgrades per se, but could end up being independently useful.
Thanks for the comment, I updated the description to be clear about what this issue is addressing. Having the ability to add new nodes to a cluster will both enable this upgrade path as well as give us a great "hammer" to use for repairs.
Working on this now.