jiebi/CodeConvo huggingface dataset:
Change:
install.Install(audit.Scheme) } <ins> // retryOnError enforces the webhook client to retry requests // on error regardless of its nature. // The default implementation considers a very limited set of // 'retriable' errors, assuming correct use of HTTP codes by // external webhooks. // That may easily lead to dropped audit events. In fact, there is // hardly any error that could be a justified reason NOT to retry // sending audit events if there is even a slight chance that the // receiving service gets back to normal at some point. func retryOnError(err error) bool { if err != nil { return true } return false } </ins> func loadWebhook(configFile string, groupVersion schema.GroupVersion, initialBackoff time.Duration) (*webhook.GenericWebhook, error) { <del> return webhook.NewGenericWebhook(audit.Scheme, audit.Codecs, configFile, </del> <ins> w, err := webhook.NewGenericWebhook(audit.Scheme, audit.Codecs, configFile, </ins> []schema.GroupVersion{groupVersion}, initialBackoff) <ins> w.ShouldRetry = retryOnError return w, err </ins> } type backend struct {

Discussion:
What would you like to be : The api server should retry sending audit events to configured webhook sinks regardless of the type of HTTP error code it might receive from the webhooks. Why is this needed: While some components may live with failed data transmissions, this is a particularly sensitive topic for the audit area. The API server audit mechanisms must ensure that no other reasonable option exists before dropping an audit event that may be the only trace of malicious behavior in the cluster. It seems that the current implementation may be improved further in this direction. Currently, when the API server is configured for non-blocking sending of audit events to a webhook audit sink backend, it will retry up to 5 times with exponential backoff, should there be an error in communicating with the webhook, as implemented . However, not all errors will trigger a retry. Some are considered transient and yield retry. Others simply stop the retry cycle. For example, it retries on receiving HTTP code , but not on receiving . The list of error codes that will yield a retry is actually quite small - three HTTP errors and one network error. Any other error will not trigger a retry and the audit events will be lost. The code comments explain that the retry will consider only recoverable failures, which may make sense in other cases, but as far as sending audit events to an audit backend webhook is concerned, it is not sufficient policy. A more robust approach would be to consider any error and give the backend service a chance to recover instead of relying on the error codes semantics and the webhook implementations interpretation of it. That is more inline with having the transmission of audit events as top priority. /sig auth /sig api-machinery
Change:
exit 1 fi <ins> echo "$(date +'%Y-%m-%d %H:%M:%S') Detecting if migration is needed" </ins> if [ "${TARGET_STORAGE}" != "etcd2" -a "${TARGET_STORAGE}" != "etcd3" ]; then echo "Not supported version of storage: ${TARGET_STORAGE}" exit 1

Discussion:
At the very least it should be clear when (timestamp) the migration started and finished.

If in line line is executed also for step 2.2.1 if the tool failed during first run of upgrade. I guess we should also check for the step and compare it to version.
Change:
return fmt.Errorf("looking up provisioner name for volume %v: %w", vol, err) } if !isCSIMigrationOn(csiNode, inTreeProvisionerName) { <ins> csiNodeName := "" if csiNode != nil { csiNodeName = csiNode.Name } </ins> klog.V(5).InfoS("CSI Migration is not enabled for provisioner", "provisioner", inTreeProvisionerName, <del> "pod", klog.KObj(pod), "csiNode", csiNode.Name) </del> <ins> "pod", klog.KObj(pod), "csiNode", csiNodeName) </ins> return nil } // Do translation for the in-tree volume.

Discussion:
handles cases when csiNode is nil. This is condition is used by cluster-autoscaler internal working. However, the log line refers to causing seg fault
/sig scheduling /sig storage
/sig storage /priority important-soon /triage accepted
/sig storage /sig scheduling Note that the lister returns an error for the case when the doesn't exist. But it's ignored here: It looks like the log line that causes the panic was introduced in in 1.25+
cc
/assign
As far as I can tell this issue is only fixed in version 1.27 (by ). Is there a plan to port it back to releases 1.25 and 1.26 as well?
it has already been picked to 1.25 and 1.26 () and will be in the next patch releases for those versions
Great. Thank you for the pointer.
Change:
return &TestDuplicatePlugin{}, nil } <ins> // TestPermitPlugin only implements PermitPlugin interface. type TestPermitPlugin struct { PreFilterCalled int } func (pp *TestPermitPlugin) Name() string { return permitPlugin } func (pp *TestPermitPlugin) Permit(ctx context.Context, state *CycleState, p *v1.Pod, nodeName string) (*Status, time.Duration) { return NewStatus(Wait, ""), time.Duration(10 * time.Second) } </ins> var registry Registry = func() Registry { r := make(Registry) r.Register(scoreWithNormalizePlugin1, newScoreWithNormalizePlugin1)

Discussion:
What would you like to be : When the pod is scheduled to the phase and I delete the pod, the pod still remains in the until the plugin allow/reject/timeout(Especially when waiting for a long time). Why is this needed: We need to take the initiative to delete the data in the and terminate the process in waiting state of plugin to ensure data accuracy, if the pod has been deleted /cc /priority important-soon /assign /sig scheduling
I think we can update the event handler for deleting pods to reject the pod. Can you send a PR for that?
OKI will send a pr for it.
Change:
csics := f.CSIClientSet var err error <del> m.driver = drivers.InitMockCSIDriver(tp.registerDriver, tp.attachable, tp.podInfoVersion, tp.attachLimit) </del> <ins> m.driver = drivers.InitMockCSIDriver(tp.registerDriver, !tp.disableAttach, tp.podInfoVersion, tp.attachLimit) </ins> config, testCleanup := m.driver.PrepareTest(f) m.testCleanups = append(m.testCleanups, testCleanup) m.config = config

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: in Which test(s) are failing: Since when has it been failing: 2019-02-27 () -- since it was Testgrid link: Reason for failure: Timeout: Anything else we need to know: /kind failing-test /sig storage /priority important-soon /milestone v1.14 cc
cc Could you help with this please?
/assign
Neither of the failing tests mentioned in this issue are present in testgrid anymore. is all clear
Change:
} for _, test := range tests { t.Run(test.name, func(t *testing.T) { <ins> assignDefaultStartTime(test.pods) </ins> nodes := []*v1.Node{} for _, n := range test.nodes { nodes = append(nodes, makeNode(n, priorityutil.DefaultMilliCPURequest*5, priorityutil.DefaultMemoryRequest*5))

Discussion:
What would you like to be : TestSelectNodesForPreemption should assign pod.Status.StartTime for test Pod Why is this needed: We can see the following in the output of TestSelectNodesForPreemption: This is due to missing assignment to Status.StartTime
/sig scheduling
/assign
Change:
cs = f.ClientSet }) <del> ginkgo.It("should set default value on new IngressClass", func() { </del> <ins> ginkgo.It("should set default value on new IngressClass [Serial]", func() { </ins> ingressClass1, err := createIngressClass(cs, "ingressclass1", true, f.UniqueName) framework.ExpectNoError(err) defer deleteIngressClass(cs, ingressClass1.Name)

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: gce-master-scale-correctness Which test(s) are flaking: [sig-network] Ingress API should support creating Ingress API operations [Conformance] Testgrid link: https://k8s- Reason for failure: Anything else we need to know: /kind flake /sig scalability /sig network /cc
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
this is caused by the issue described in a different test is creating a default ingressclass, which breaks creation of ingress objects if there was already a default ingressclass set up in the cluster /assign
this should resolve the issue:
I take it back, looks like the conformance test is also creating default ingressclass objects... it should not fix in
Change:
--kubelet-port=${KUBELET_PORT}  --runtime-config=api/v1  --cert-dir="${TMPDIR:-/tmp/}"  <ins> --runtime_config="extensions/v1beta1=true"  </ins> --service-cluster-ip-range="10.0.0.0/24" 1>&2 & APISERVER_PID=$!

Discussion:
Now that we've moved the experimental api to /apis/experimental... it's inaccessible from by default. We should fix that. who stepped on this earlier
security questions for you: this prefix was apparently in response to a security review quite some time ago. I don't understand how this adds much security. Can we just remove it? If not, is it acceptable to change the default from "/api/" to "/api", which would match both api locations? Otherwise we'll have to take a comma-separated list or something...
Ref
Oh, so this is not related to the security requests! And the original use case was just to re-root the URL path so it didn't interfere with static content. Sorry, I got confused because the last time I monkeyed with that, it was in conjunction with the allow/deny list that actually was the security request. In that case, let's see if we can change the default to "/", if that will break anything.
That change got introduced as part of to protect against XSRF in kubectl proxy. But I think the more important part of that change was that it disallows POST/PUT/PATCH by default. So as long as there is no state changing action outside of /api/ that can be triggered with a GET it should be safe to remove.
Change:
tearDownUserspaceIptables(ipt) return &Proxier{ <del> serviceMap: make(map[proxy.ServicePortName]*serviceInfo), syncPeriod: syncPeriod, iptables:   ipt, </del> <ins> serviceMap:    make(map[proxy.ServicePortName]*serviceInfo), syncPeriod:    syncPeriod, iptables:      ipt, MasqueradeAll: MasqueradeAll, </ins> }, nil }

Discussion:
Related to . As a safety mesure, it could be very useful to actually include a flag to proxy to MASQUERADE everything (acting very close to a userspace proxy). I think it's not very hard to do and a very good way to diagnose or even fallback in case of problem (I'm thinking about vxlan cases). Something like "--snat-clients" or "--snat-pods" could be appropriate.
/cc
Looking at the current code: It looks like we SNAT almost everything already now? Would adding a set-mark rule (behind the flag of course) at line 548 be sufficient? Deprecated Public IPs, Loadbalancer IPs, and NodePorts all appear to be marked for SNAT already (also endpoint loopback traffic).
I think that is the flag, yeah. , Benjamin Elder wrote:
Ok, I'll push out a PR for that in a moment. I should be able to take care of that and the cleanup flag (PR out but needs some more work) today. On Aug 20, 2015 2:12 PM, "Tim Hockin" wrote:
Change:
podName := "pod-dualstack-host-ips" <del> pod := &v1.Pod{ ObjectMeta: metav1.ObjectMeta{ Name:   podName, Labels: map[string]string{"test": "dualstack-host-ips"}, }, Spec: v1.PodSpec{ Containers: []v1.Container{ { Name:  "dualstack-host-ips", Image: imageutils.GetE2EImage(imageutils.Agnhost), }, }, }, } </del> <ins> pod := genPodHostIPs(podName+string(uuid.NewUUID()), false) </ins> ginkgo.By("submitting the pod to kubernetes") podClient := e2epod.NewPodClient(f)

Discussion:
4 other Test Failures in ci-crio-cgroupv1-node-e2e-features. Test has failed 61 times (no passing result found). Earliest failure found at commit/ (Thu Oct 19 21:41 PDT). /cc { failed [FAILED] Error creating Pod: pods "pod-dualstack-host-ips9ddb9810-134c-4d35-a0c6-" is forbidden: violates PodSecurity "restricted:latest": host namespaces (hostNetwork=true) In [It] at: @ 10/23/23 01:38:06.024 } No response_ /sig network node
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
is also failing on these tests
the test has a bug, it checks the contrary
, let's start over, 1 commit for the e2e test, other for the promotion, and let's validate everything is alright before merging
Change:
"context" "fmt" "os" <ins> "os/exec" </ins> "path/filepath" "strconv" "time"

Discussion:
Failing on cri-o serial job. Looks like the dbus command isn't available for graceful shutdown tests that aren't running on Ubuntu. /assign /kind failing-test <!-- If this is a flake, please add: /kind flake --/sig node
/triage accepted /priority important-soon
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
hmm, is this still issue? The testgrid job is still failing even after the fix appears to be merged? !
Please take a look when you get a chance, the error still seems to be that dbus-send is unavailable... /cc
oops... I forgot to add this to the other
Change:
# TODO(mbforbes): Refactor setting scope flags. local -a scope_flags=() if (( "${#MINION_SCOPES[@]}" > 0 )); then <del> scope_flags=("--scopes" "${MINION_SCOPES[@]}") </del> <ins> scope_flags=("--scopes" "$(join_csv ${MINION_SCOPES[@]})") </ins> else scope_flags=("--no-scopes") fi

Discussion:
This happens over and over. Scary messages. WARNING: Lists should be separated by commas, try "--allow=tcp,udp,icmp,esp,ah,sctp". If you intend to use udp, icmp, esp, ah, sctp for positional arguments, put them before the flag. WARNING: Lists should be separated by commas, try "--scopes=storage-ro,compute-rw". If you intend to use compute-rw for positional arguments, put them before the flag. WARNING: Lists should be separated by commas, try "--metadata-from-file=startup-script=/usr/local/google/home/thockin/src/kubernetes/hack/e2e-internal/../../cluster/../cluster/gce/../../cluster/../cluster/gce/configure-,kube-env=/tmp/kubernetes.MURmzX/master-kube-". If you intend to use kube-env=/tmp/kubernetes.MURmzX/master-kube- for positional arguments, put them before the flag. WARNING: Lists should be separated by commas, try "--disk=name=e2e-test-thockin-master-pd,device-name=master-pd,mode=rw,boot=no,auto-delete=no". If you intend to use device-name=master-pd, mode=rw, boot=no, auto-delete=no for positional arguments, put them before the flag.
That's a new one. gcloud started getting a little more anal here. Exciting. cc
They changed list argument syntax a while back, but the warnings are new. Time to update startup scripts I guess.
Change:
package iptables import ( <ins> "bufio" </ins> "bytes" "context" "fmt" "regexp" <ins> "strconv" </ins> "strings" "sync" "time"

Discussion:
my k8s cluster version is 1.17.x this cluster has 10 master only 2 nodes get problem. it make my svc sometime can usesometime can timeout what can i do can resolve this problem ? this 2 node's svc is nodeportType
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
you can increase kube-proxy verbosity adding flag and you should get more information about the cause of the error Kubernetes 1.17 is EOL, so you should upgrade to 1.19 at least
/sig network
hello bromy cluster is use kubeadm init .so what should i do .i know this is use configmap but in this i can not found how edit this configmap is availableabout upgrade this cluster .this time is impossible
about stack. i only get this log.
To increase the verbosity on kube-proxy on a kubeadm deployment you can do and wait until pods are restarted. Despite that, if there is a bug, it will not be backported to 1.17, so you have to go to a supported version first
I swear we code to dump the ruleset when this happens, but I don't see it any more.
I'm going to re-purpose this as a feature :)
Hi, I would like to pick this up. Can someone give me some code pointers on where to start?
Let me know if I can help in anyway.
/assign
I'd start with - It's worth thinking about the cleanest solution here, but maybe something like: When you get an error from exec, parse the error for and if it matches, return a . Then let the callers check for a by interface assertion, extract the Line(), extract their input's data at -3 and +3 from that line and log it. E.g. You'll proably want a helper func to do that, which could live in that same iptables package. And a test.
/assign
hi everyone! Is anyone doing this?

I am willing to do this
at least I didn't see any PR from , in case of collision please sync between both to avoid duplicate efforts
hi did you work on it?
Hi apologies I was busy with some other work. You must please continue.
thanks
/assign
I'm working on this now, but I'm stuck in here, I got the line, and then how I extract at -3 and +3 from that line?
you may need to write a helper function to extract them from the logs. my 2 cents.. here is my version for reference. you could add some tests, to cover the boundary conditions. to play around :)
Change:
return err } <ins> // store generation in order to avoid repeated updates for the same generation (and potential // fights of API server in HA environments). c.lastSeenGenerationLock.Lock() defer c.lastSeenGenerationLock.Unlock() c.lastSeenGeneration[crd.Name] = crd.Generation </ins> return nil }

Discussion:
/sig api-machinery /kind bug /assign sttts because the controller that maintains the condition runs multiple instances in HA apiserver clusters, the controller must not duel in cases where the validation messages change slightly between releases
Change:
"k8s.io/kubernetes/pkg/api/unversioned" "k8s.io/kubernetes/pkg/apis/policy" policyclient "k8s.io/kubernetes/pkg/client/clientset_generated/internalclientset/typed/policy/internalversion" <ins> "k8s.io/kubernetes/pkg/client/retry" </ins> "k8s.io/kubernetes/pkg/labels" "k8s.io/kubernetes/pkg/registry/generic/registry" "k8s.io/kubernetes/pkg/runtime" <ins> "k8s.io/kubernetes/pkg/util/wait" </ins> ) const (

Discussion:
What happened: When I try to test after implementing the 1st approach according to , I found pod disruption budgets cannot handle concurrent requests. The error message is: It is an Optimistic Lock error message. It means PDB can't handle concurrent requests. How to reproduce it (as minimally and precisely as possible): 1) Create a deployment with 6 replicas and schedule them to the same node, say node A. You can leave only one node scheduling enabled, and then create the deployment. 2) Create the PDB that match the deployment's label 3) Uncordon another node, say node B 4) Drain node A using concurrent POST eviction requests. Ref: I'm not sure if this behavior is OK for PDB. I think I can make work by waiting for a while if current pod label(s) match previous pod label(s).
Oh, that's interesting. I think the problem is that this function doesn't retry if UpdateStatus() fails due to version conflict. I think the solution is to modify the caller, i.e. this function so that instead of just it instead does something like This will loop re-doing checkAndDecrement() and getPodDisruptionBudgets() until checkAndDecrement() succeeds, or fails with a non-conflict error. Does that make sense? cc/ for sanity check
Or use PATCH?
Yes, PATCH should work also. I haven't written code that uses PATCH, so I can't advise exactly the code to write here (there are examples by grepping for patch, but I'm not sure exactly what is the right way to do it from inside of API server code, which is where we are here). can you do a PR to implement this, either using the approach I described above or using PATCH? I think this is important to get into 1.5.
I think PATCH may NOT be safe here. For example: 1) current pdb 2) creating eviction A: get 3) creating eviction B: get 4) creating eviction A: PATCH pdb 5) creating eviction B: PATCH pdb 6) pdb's . It's wrong. Retry loop make more sense to me.
Good point! You're right. Retry loop should be OK.
I can help to create a PR using retry loop.

Could you please triage this for 1.5 and apply blocker or non-blocker labels as appropriate along with priority.
Done.
who is actually working on this issue? Could one of you set yourselves as an assignee for this issue? Thanks! cc:
retry logic with PR needs reviews/lgtm
Change:
storageframework.CapOnlineExpansion:     true, storageframework.CapNodeExpansion:       true, storageframework.CapSnapshotDataSource:  true, <ins> storageframework.CapReadWriteOncePod:    true, </ins> }, RequiredAccessModes: []v1.PersistentVolumeAccessMode{v1.ReadWriteOnce}, TopologyKeys:        []string{GCEPDCSIZoneTopologyKey},

Discussion:
For the ReadWriteOncePod feature to graduate to beta, we need to have E2E test coverage for its current alpha behavior. See this section of KEP-2485 for more context on what cases we need to cover for alpha: This is a requirement for beta graduation, see:
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 storage
Change:
} return opts } <ins> type typeCheckingCompiler struct { compositionEnv *plugincel.CompositionEnv typeOverwrite  typeOverwrite } // CompileCELExpression compiles the given expression. // The implementation is the same as that of staging/src/k8s.io/apiserver/pkg/admission/plugin/cel/compile.go // except that: // - object, oldObject, and params are typed instead of Dyn // - compiler does not enforce the output type // - the compiler does not initialize the program func (c *typeCheckingCompiler) CompileCELExpression(expressionAccessor plugincel.ExpressionAccessor, options plugincel.OptionalVariableDeclarations, mode environment.Type) plugincel.CompilationResult { resultError := func(errorString string, errType apiservercel.ErrorType) plugincel.CompilationResult { return plugincel.CompilationResult{ Error: &apiservercel.Error{ Type:   errType, Detail: errorString, }, ExpressionAccessor: expressionAccessor, } } env, err := c.compositionEnv.Env(mode) if err != nil { return resultError(fmt.Sprintf("fail to build env: %v", err), apiservercel.ErrorTypeInternal) } ast, issues := env.Compile(expressionAccessor.GetExpression()) if issues != nil { return resultError(issues.String(), apiservercel.ErrorTypeInvalid) } // type checker does not require the program, however the type must still be set. return plugincel.CompilationResult{ OutputType: ast.OutputType(), } } var _ plugincel.Compiler = (*typeCheckingCompiler)(nil) </ins>

Discussion:
When I load a policy definition like this The object is updated with the following status While this error is reported, the policy does seem to be fully functioning This is similar to the documented examples No error reported on a valid spec Create a a policy that uses variables Observe the status of the newly created policy No response <details</details<detailsn/a </details<details</details<detailskind </details<details</details<details</details
/sig api-machinery
/assign Oops. Good find. Thank you. /triage accepted