jiebi/CodeConvo huggingface dataset:
Change:
srcs = [ ":package-srcs", "//cmd/kube-apiserver/app/options:all-srcs", <ins> "//cmd/kube-apiserver/app/preflight:all-srcs", </ins> ], tags = ["automanaged"], )

Discussion:
See: This code should make several attempts before ing. Alternatively, we could consider not listening for connections until this code has succeeded.
Feel free to correct me if I'm wrong on any of this since I've never looked at kubernetes code base before. The code for the and the both appear to make multiple attempts before returning an error which leads to a Fatal.
, I think we had waited for to start at . Do we need to wait more or make it configurable?
I would like to work on this if nobody else is.
No need to ask for permission! Just say here that you're working on it, that should be sufficient to prevent duplicate work. :)
Can I have a go at this?
I have a nearly completed solution for this already. Just working on testing/test cases. WIll hopefully sumbit a PR shortly.
Ok.
I wondered why we care about this. After all, kubelet restarts failing pods. For posterity, after talking with the reason is that the apiserver may fail so fast that the kubelet begins to back off on restarts of a failing pod. That backoff may be too aggressive. (Maybe it causes spurious alerts, or maybe it allows too much downtime.) So, let's fix the apiserver. That's fine, but clearly we're not the only user that might encounter this. You may be running a server you don't want to (or can't) modify, and you might wish you could tweak the kubelet's backoff heuristics for your pod. Alternately, maybe the kubelet could choose not to enter the backoff if apiserver exited with a different code. anything like this already in place?
That's a wonderful explanation that hadn't occurred to me. If there isn't a feature request for this already I'll work on something and reference this issue.
AFAIK, the backoff mechanism is there to protect kubelet from being overwhelmed by failed user containers. Trusting the containers with returning a specific exit code sounds like a big "no" to me. Making this configurable per pod might be ok, but it's still not good in general to allow aggressive restarts.
The referred PR () only fixes the issue for kube-apiserver. We still need a generic fix in genericapiserver (Ref ).
Change:
if f.DynamicConfigDir.Provided() && !utilfeature.DefaultFeatureGate.Enabled(features.DynamicKubeletConfig) { return fmt.Errorf("the DynamicKubeletConfig feature gate must be enabled in order to use the --dynamic-config-dir flag") } <del> // ensure that nobody sets InitConfigDir if the dynamic config feature gate is turned off </del> <ins> // ensure that nobody sets InitConfigDir if the KubeletConfigFile feature gate is turned off </ins> if f.InitConfigDir.Provided() && !utilfeature.DefaultFeatureGate.Enabled(features.KubeletConfigFile) { return fmt.Errorf("the KubeletConfigFile feature gate must be enabled in order to use the --init-config-dir flag") }

Discussion:
See:
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
For some reason GitHub didn't close this automatically when the referencing PR merged.
Change:
expectInvocations: []invocation{ {path: "/mutating/1/5s", timeoutSeconds: 3}, // from request }, <del> expectError:   true, errorContains: "the server was unable to return a response in the time allotted", </del> <ins> expectError: true, errorContainsAnyOf: []string{ // refer to https://github.com/kubernetes/kubernetes/issues/98606#issuecomment-774832633 // for the reason for triggering this scenario "stream error", "the server was unable to return a response in the time allotted", }, </ins> }, }

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: Which test(s) are flaking: (regardlessoffailurepolicy)and_fail Testgrid link: Reason for failure: and Anything else we need to know: Spyglass: <!-- Please see the deflaking doc () for more guidance! --
/sig api-machinery /area apiserver
Can confirm this PR:
/assign
/triage accepted
The kube-apiserver processing flow is as follows, (non-critical paths are omitted) ... // other filters parse the http client timeout setting, sets the Ctx with Deadline in the http.Request ...// other filters select the http.Request.Context().Done() Pay attention to the processing logic in . Although the Context of http.Request has been cancelled, the Mutex on baseTimeoutWriter needs to be obtained between entering the function. The inner-handler may have written , ready to write , but the current code flow thinks that it should be Panic quickly, and it is recovered by and sends http2.Reset to the Client. As a result, a appears on the client side.
Currently seeing it in periodic and in presubmit for
Regardless of WithCache or WithoutCache, here is not reasonable.
/priority important-soon /milestone v1.21
PS: There were some recent failures:
/remove-priority important-soon /priority critical-urgent top flake for pull-kubernetes-integration per: triage link: FYI
may be one fix, may also be necessary (thanks for opening these
I believe that can effectively repair the issue, but currently is not the key PR to fix the issue.
Change:
<ins> load("@io_bazel_rules_go//go:def.bzl", "go_binary", "go_library") go_library( name = "go_default_library", srcs = ["check_conformance_test_requirements.go"], importpath = "k8s.io/kubernetes/hack/conformance", visibility = ["//visibility:private"], deps = [ "//vendor/github.com/pkg/errors:go_default_library", "//vendor/github.com/spf13/cobra:go_default_library", ], ) go_binary( name = "conformance", embed = [":go_default_library"], visibility = ["//visibility:public"], ) filegroup( name = "package-srcs", srcs = glob(["**"]), tags = ["automanaged"], visibility = ["//visibility:private"], ) filegroup( name = "all-srcs", srcs = [":package-srcs"], tags = ["automanaged"], visibility = ["//visibility:public"], ) </ins>

Discussion:
There are a number of conformance test requirements and guidelines: We should try to automate enforcement to the degree we can, via a "linting" tool, and/or test framework checks. For instance, conformance tests shouldn't invoke framework.ProviderIs or framework.SkipUnlessProviderIs. Those could actually check whether they are invoked by a conformance test, and then die. cc /area conformance
/sig testing
/cc
Change:
// Initialize CPU manager if utilfeature.DefaultFeatureGate.Enabled(kubefeatures.CPUManager) { <del> cm.cpuManager.Start(cpumanager.ActivePodsFunc(activePods), podStatusProvider, runtimeService) </del> <ins> cm.cpuManager.Start(cpumanager.ActivePodsFunc(activePods), sourcesReady, podStatusProvider, runtimeService) </ins> } // cache the node Info including resource capacity and

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: PR , it will remove "inactive containers" while reconciling. But the cpumanager started very beginning, it will get empty activePods at it first run. This make state file no sense. What you expected to happen: We should wait a moment or notification from podmanager before starting reconcile. Some log may be before remove "inactive containers". How to reproduce it (as minimally and precisely as possible): restart kubelet Anything else we need to know?: Environment: Kubernetes version (use ): 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 node
In reconcileState : You mean the cpu assignments would be wiped for the first reconciliation ?
Yes, you can test it by restarting kubelet.
Do you see any of the following log:
I see this
/assign
Change:
allErrs = append(allErrs, field.Forbidden(field.NewPath("spec", "podCIDR"), "node updates may not change podCIDR except from "" to valid")) } } <ins> // Allow controller manager updating provider ID when not set if len(oldNode.Spec.ProviderID) == 0 { oldNode.Spec.ProviderID = node.Spec.ProviderID } else { if oldNode.Spec.ProviderID != node.Spec.ProviderID { allErrs = append(allErrs, field.Forbidden(field.NewPath("spec", "providerID"), "node updates may not change providerID except from "" to valid")) } } </ins> // TODO: move reset function to its own location // Ignore metadata changes now that they have been tested oldNode.ObjectMeta = node.ObjectMeta

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: Follow up for , With the change for cloud-controller-manager updating providerID, the is to be updated. But it will fail later in node update call: Should also check validation rule: By adding following line will do the trick. But this will also allow users to manually edit node's providerID Shall we enforce that only cloud-controller-manager can update the providerID? What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?:
There are no sig labels on this issue. Please by: 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. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig cluster-lifecycle
cc
/area cloudprovider
being able to update seems pretty reasonable to me. Can you get a PR in for that since we're close to code freeze?
cc
I found this issue when validating against a cluster running azure cloud provider, could you please also check whether it is the same case from you side? serves somewhat like an identity for nodes, thus it wouldn't expect arbitrarily updating. A compromise proposal is to allow updates when the value is not set. This gives controller manager a chance to set it during node register. Created as a fix proposal.
thanks for the patch, I think I'll have some time this weekend to verify this fix!
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/cluster-lifecycle: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</a</details
Change:
// descending order {buildByImageSize(), 0, 2, false}, {buildByImageSize(), 1, 0, true}, <ins> {buildByImageSize(), 3, 2, true}, </ins> } for _, fooTest := range fooTests {

Discussion:
What happened: When two or more images on a given node have the same size, their order inside the field set by the process is not deterministic. This problem has the side effect of continually triggering controllers which assume this list to be always equal on node updates unless images are or removed. What you expected to happen: The order of images should be stable even when two images have the same size, using the image ID as a second sort field would help this. How to reproduce it (as minimally and precisely as possible): Choose a node and run: Run a few times: It should be possible to see and images alternating on the output. Anything else we need to know?: Our particular use case make it really common for multiple images to have the same size on a given node. I came across this problem while debugging slow updates to DaemonSets and finding out that the kube-controller-manager was leaking memory until it eventually dies due to OOM: <img width="800" alt="Screen Shot 2019-06-30 at 20 27 22" src="https://user-"I was able to track this leak to a large number of watched elements in memory and by taking a look at the logs with increased verbosity I figured it was due to too many Node notifications being processed by the DaemonSet controller: <img width="800" alt="Screen Shot 2019-06-30 at 20 36 23" src="https://user-"It's possible that other controllers in the wild that watch nodes and only ignore the conditions timestamps on updates to face the same problem. I'll send a simple PR to fix this shortly. Environment: Kubernetes version (use ): But by taking a look at the code this problem also happens on master.
/sig node
Nice debugging here :)
Change:
} } <del> // And create a configuration source that reads from a local file config.NewConfigSourceFile(*configFile, serviceConfig.Channel("file"), endpointsConfig.Channel("file")) glog.Infof("Using configuration file %s", *configFile) </del> loadBalancer := proxy.NewLoadBalancerRR() proxier := proxy.NewProxier(loadBalancer, net.IP(bindAddress)) // Wire proxier to handle changes to services

Discussion:
It's not well tested nor widely used; so it should either be removed or have tests and uses .
Change:
} } } <ins> removePod := func(i int) operation { return func() { if err := cache.RemovePod(pods[i]); err != nil { t.Error(err) } } } </ins> removePodWithAffinity := func(i int) operation { return func() { if err := cache.RemovePod(podsWithAffinity[i]); err != nil {

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:
fi if [[ -z "${KUBE_ADMISSION_CONTROL:-}" ]]; then <del> ADMISSION_CONTROL="Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,PodPreset,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,Priority,StorageObjectInUseProtection" </del> <ins> ADMISSION_CONTROL="Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,Priority,StorageObjectInUseProtection" </ins> if [[ "${ENABLE_POD_SECURITY_POLICY:-}" == "true" ]]; then ADMISSION_CONTROL="${ADMISSION_CONTROL},PodSecurityPolicy" fi

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: pull-kubernetes-e2e-gce and pull-kubernetes-kubemark-e2e-gce both start kube-apiserver with admission and but without enabling priorityclasses and podpresets resources. We can see many error logs from
/sig test /sig api-machinery
/kind bug
/sig testing
Change:
return append(allErrs, field.Invalid(fldPath, value, "must be a standard resource for containers")) } } <del> return field.ErrorList{} </del> <ins> return allErrs </ins> } // Validate resource names that can go in a resource quota

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: In some validation functions, such as , , value returned may be wrong. When return some errors and , we may just return , that is not expected What you expected to happen: return correctly
There are no sig labels on this issue. Please by: 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. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig api-machinery
/assign
Can you clarify "wrong"?
For example in will add and to field of ResourceQuotaSpec. Before , these two resources are not to standard resource sets, will return error since they are not fully-qualified neither. But will not return any error since the two resources are to standard quota resource name sets. The result above is not expected . Error happened in , we need to return it instead of returning when we ran
Change:
kube::util::ensure-gnu-sed kube::log::status "Building kubectl" <del> make -C "${KUBE_ROOT}" WHAT="cmd/kubectl" </del> <ins> make -C "${KUBE_ROOT}" WHAT="cmd/kubectl cmd/kubectl-convert" </ins> # Check kubectl kube::log::status "Running kubectl with no options"

Discussion:
was removed in 1.20 in favor of a plugin. However, this is not included in release artifacts. The binary is included in release artifacts, and ideally easily installable via kubectl plugin managers like . /sig cli /assign
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
This question came up in a docs review of a page referencing () Once this is resolved, please ensure the website is updated to document installation/use of this tool.
/sig release
Change:
"//vendor/k8s.io/client-go/discovery:go_default_library", ], ) <ins> go_test( name = "go_default_test", srcs = ["status_strategy_test.go"], embed = [":go_default_library"], deps = ["//vendor/k8s.io/apimachinery/pkg/apis/meta/v1/unstructured:go_default_library"], ) </ins>

Discussion:
the said: However the are different, it does not allow to set spec and metadata, but other changes are not ignored. And updates to other parts are not validated.
/cc for some suggestions.
/assign
Made a pull request:
Is the documentation wrong or the implementation? I think there was a longer discussion about the correct behaviour in the PR, but haven't found it yet.
It strange that other parts rather than metadata and spec can be modified and they are not validated. So I think the implementation is wrong, at least.
We should follow the design doc, I think.
/sig api-machinery
/priority important-soon
I agree the current behaviour is wrong. Added some comments to Especially, worries me whether we really have to right /status behaviour. Not really related to the given issue. But as we are touching the /status behaviour, we should clarify that as well.
[MILESTONENOTIFIER] Milestone Issue Needs Approval Action required: This issue must have the label applied by a SIG maintainer. If the label is not applied within 3 days, the issue will be moved out of the v1.11 milestone. <details<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. : 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:
source "config-default.sh" KUBECTL="${KUBE_ROOT}/cluster/kubectl.sh" export KUBECTL_PATH="${KUBE_ROOT}/cluster/ubuntu/binaries/kubectl" <ins> export KUBE_CONFIG_FILE=${KUBE_CONFIG_FILE:-${KUBE_ROOT}/cluster/ubuntu/config-default.sh} </ins> function init { echo "Creating kube-system namespace..."

Discussion:
This is not a problem when running kube-up because the kube-up for Ubuntu ensures that environment variable is defined. But when an operator runs , kubectl is invoked without ensuring KUBECONFIGFILE is defined and invokes detect-master without ensuring KUBECONFIGFILE is defined.
Change:
if addSCTPContainers { protocols = append(protocols, v1.ProtocolSCTP) } <ins> if framework.NodeOSDistroIs("windows") { return NewWindowsModel(namespaces, []string{"a", "b", "c"}, []int32{80, 81}, dnsDomain) } </ins> return NewModel(namespaces, []string{"a", "b", "c"}, []int32{80, 81}, protocols, dnsDomain) }

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Ive done preliminary testing with on calico powered clusters on some windows variants and found that the probing seems to work. Can we add wrapper to netpol suite so that we can run it on windows clusters ? Why is this needed: We need this because otherwise, CNIs such as EKS will give us This error is caused when, for example, pods that are landing on a windows node havent defined their target platform. Somehow i guess pods which are landing on linux nodes dont have this issue. Its also needed for the obvious reason that we probably want separate linux and windows test suites for policies, in general, even though we expect the logic to be identical (modulo hostports , which we dont currently test)
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 windows
/assign
grepping around, I can't figure out where those are supposed to go. Can you give me pointers?
(resolved in slack, matts digging into this)
ok, these are running now on eks, lots of failures. will dig
/assign
the netpol are not being applied for the ns: Instead of failing because should not be able to access , the connection succeeds.