jiebi/CodeConvo huggingface dataset:
Code change:
} } <del> // OpenAPIv3 type/maxLength/maxItems/MaxProperties/required/wrong type field validation failures are viewed as blocking err for CEL validation </del> <ins> // OpenAPIv3 type/maxLength/maxItems/MaxProperties/required/enum violation/wrong type field validation failures are viewed as blocking err for CEL validation </ins> func hasBlockingErr(errs field.ErrorList) (bool, *field.Error) { for _, err := range errs { <del> if err.Type == field.ErrorTypeRequired || err.Type == field.ErrorTypeTooLong || err.Type == field.ErrorTypeTooMany || err.Type == field.ErrorTypeTypeInvalid { </del> <ins> if err.Type == field.ErrorTypeNotSupported || err.Type == field.ErrorTypeRequired || err.Type == field.ErrorTypeTooLong || err.Type == field.ErrorTypeTooMany || err.Type == field.ErrorTypeTypeInvalid { </ins> return true, field.Invalid(nil, nil, "some validation rules were not checked because the object was invalid; correct the existing errors to complete validation") } }

Related discussion:
text: pointed out to me that a CEL x-kubernetes-validations rule in a CRD was hitting the estimated cost limit when performing a simple "string has prefix" check on an en enum field. Putting a limit in the OpenAPI of the enum string field fixed the problem, but having to add a limit like this is counter-intuitive and unnecessary, since the allowed enum values already make the max allowed length obvious. The apiserver automatically computes the max length of an enum as the length of the longest allowed enum value. I believe we already refuse evaluate CEL rules on values that fail OpenAPI value validation, since we rely in the value validations to establish all length limits. I haven't tested it locally, but something like this should work (given enough nested arrays): As a workaround, one can manually set on the string enum, e.g.: 25+ All No response No response No response No response
/sig api-machinery /triage accepted /assign
/assign
I wasn't sure if we special-cased the maxLength / maxItems / maxProperties failures, or if all openapi validation had to pass before we started messing with CEL evaluation
it looks like we currently special-case specific openapi errors that short-circuit CEL validation, I'm not sure an enum validation failure would currently prevent evaluation:
The enum err is converted to () error which is not short-circuit here. But for defaulting case, all error would be short-circuit. I would suggest to add error into the blockingErr list to short-circuit CEL validation. Would this make sense?
yeah, that sounds good if we're going to rely on it to catch things that are longer than the maximum length enum value
Code change:
// Removes SCSI controller which is latest attached to VM. func cleanUpController(newSCSIController types.BaseVirtualDevice, vmDevices object.VirtualDeviceList, vm *object.VirtualMachine, ctx context.Context) error { <ins> if newSCSIController == nil || vmDevices == nil || vm == nil { return nil } </ins> ctls := vmDevices.SelectByType(newSCSIController) if len(ctls) < 1 { return ErrNoDevicesFound

Related discussion:
text: Kubernetes 1.3.0. During attach disk to VM, call to cleanUpController dereferenced a null pointer. Stack trace:
The seems points to a comment instead of a cleanUpCotroller function in v1.3.0. There might be some modifications later which make the line number inaccurate. Would you please double check which line it really should point to? Thanks.
that is correct, this was a build from v1.3.0 with changes related to this: therefore the line numbers do no line up with v1.3.0. In either case, the panic happened inside
Hi Davide, I saw your PR for this issue and I have another question. Why cleanUpController could be called with an empty newSCSIController? According to the context, an empty newSCSIController should not even be returned by CreateSCSIController rt? Thanks.
it doesn't look like it should happen, but it did and there wasn't any checks for nil pointers in our code or the Govmomi library.
Code change:
// rest.Config generated by the resolver. type AuthenticationInfoResolverWrapper func(AuthenticationInfoResolver) AuthenticationInfoResolver <del> // AuthenticationInfoResolver builds rest.Config base on the server name. </del> <ins> // AuthenticationInfoResolver builds rest.Config base on the server or service // name and service namespace. </ins> type AuthenticationInfoResolver interface { <ins> // ClientConfigFor builds rest.Config based on the server. </ins> ClientConfigFor(server string) (*rest.Config, error) <ins> // ClientConfigForService builds rest.Config based on the serviceName and // serviceNamespace. ClientConfigForService(serviceName, serviceNamespace string) (*rest.Config, error) </ins> } <del> // AuthenticationInfoResolverFunc implements AuthenticationInfoResolver. type AuthenticationInfoResolverFunc func(server string) (*rest.Config, error) </del> <ins> // AuthenticationInfoResolverDelegator implements AuthenticationInfoResolver. type AuthenticationInfoResolverDelegator struct { ClientConfigForFunc        func(server string) (*rest.Config, error) ClientConfigForServiceFunc func(serviceName, serviceNamespace string) (*rest.Config, error) } func (a *AuthenticationInfoResolverDelegator) ClientConfigFor(server string) (*rest.Config, error) { return a.ClientConfigForFunc(server) } </ins> <del> //ClientConfigFor implements AuthenticationInfoResolver. func (a AuthenticationInfoResolverFunc) ClientConfigFor(server string) (*rest.Config, error) { return a(server) </del> <ins> func (a *AuthenticationInfoResolverDelegator) ClientConfigForService(serviceName, serviceNamespace string) (*rest.Config, error) { return a.ClientConfigForServiceFunc(serviceName, serviceNamespace) </ins> } type defaultAuthenticationInfoResolver struct {

Related discussion:
text: We are getting the following error when the apiserver connects the webhook on localhost (configured via URL). We should only use the SSL tunnel for the connections to nodes when the webhooks are running as services. /sig api-machinery /kind bug /assign
/close
Code change:
v1 "k8s.io/api/core/v1" policy "k8s.io/api/policy/v1beta1" <del> apierrors "k8s.io/apimachinery/pkg/api/errors" </del> "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime"

Related discussion:
text: <!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Conformance - GCE - master (ci-kubernetes-gce-conformance-latest) Which test(s) are failing: [sig-scheduling] SchedulerPreemption [Serial] PreemptionExecutionPath runs ReplicaSets to verify preemption running path [Conformance]Changes Since when has it been failing: 2020-06-08 22:27 PDT Testgrid link: Reason for failure: Regression by Anything else we need to know: /sig scheduling /priority critical-urgent
cc/ /assign
Code change:
"type": "string" }, "ports": { <del> "description": "List of ports to expose from the container. Exposing a port here gives the system additional information about the network connections a container uses, but is primarily informational. Not specifying a port here DOES NOT prevent that port from being exposed. Any port which is listening on the default "0.0.0.0" address inside a container will be accessible from the network. Cannot be updated.", </del> <ins> "description": "List of ports to expose from the container. Not specifying a port here DOES NOT prevent that port from being exposed. Any port which is listening on the default "0.0.0.0" address inside a container will be accessible from the network. Modifying this array with strategic merge patch may corrupt the data. For more information See https://github.com/kubernetes/kubernetes/issues/108255. Cannot be updated.", </ins> "items": { "$ref": "#/definitions/io.k8s.api.core.v1.ContainerPort" },

Related discussion:
text: The comments in says that : However there are several cases where this is false : When using a Service with a targetPort that references a name in the ports arrays of the pod. Some software (ab)uses this API to get which ports are used (See Although unfixable, my goal is to fix the documentation so other people don't have the same problem). The Azure Load Balancer implementation does this for instance. Some other network/security software might use this information. Also, is it possible to document/reference the above issue in the comment ? Since it is described as informational I expected for the network to work without this information. But it's definitely not the case. Not needed since it's mostly a doc issue. I'm interested in contributing this patch but would like some feedbacks before doing it. :) <details</details<details</details<details</details<details</details<details</details<details</details
/sig network
/triage accepted -- thoughts? I believe the doc are due for a refresh.
I'd take this one. /assign
I didn't see that you wanted to do this patch, I am very sorry and now I unassign it. /unassign
No worries But I'm still not sure where / what to add. Should I only fix the part saying it is only informational ? Is there anything else ? (cc
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
/remove-lifecycle stale
Code change:
AUTOSCALER_MIN_NODES="${KUBE_AUTOSCALER_MIN_NODES:-1}" AUTOSCALER_MAX_NODES="${KUBE_AUTOSCALER_MAX_NODES:-${NUM_MINIONS}}" TARGET_NODE_UTILIZATION="${KUBE_TARGET_NODE_UTILIZATION:-0.7}" <ins> ENABLE_CLUSTER_MONITORING=googleinfluxdb </ins> fi # Optional: Enable deployment experimental feature, not ready for production use.

Related discussion:
text: Heapster pod: And logs: cc p0 for triage
Did the required node scope change?
Its either the API on the console or monitoring write scopes on the node. , Mike Danese wrote:
I think this affects only GCE
I will fix this issue since is on vacation.
Need to cherry pick so i'll leave open
is out for review.
has been closed and the cherrypick here () has been merged so I'm closing this issue. Thanks everyone for the debugging.
Code change:
ETCD_HOST=${ETCD_HOST:-127.0.0.1} ETCD_PORT=${ETCD_PORT:-4001} <ins> ETCD_PREFIX=${ETCD_PREFIX:-randomPrefix} </ins> API_PORT=${API_PORT:-8080} API_HOST=${API_HOST:-127.0.0.1} KUBE_API_VERSIONS=""

Related discussion:
text: removed this test. We need to continue testing this. This wasn't about testing upgrades, the prefix has nothing to do with upgrades. It's just there so people can share etcd. We maybe don't need to double everything but we do need to make sure that keeps working.
To be honest - I think that what we was testing before didn't give us completely any information. We didn't testing what information we are storing in etcd and where. That said, if we had a hardcoded prefix somewhere in our code, we wouldn't discover it at all, and those tests would still be passing. We should have a test that is directly checking etcd contents. I think it should be possible to write a simple unit test for it. Will try to put something together next week.
Code change:
} // performPlatformSpecificContainerCleanup is responsible for doing any platform-specific cleanup <del> // after either: //   * the container creation has failed //   * the container has been successfully started //   * the container has been removed // whichever happens first. // Any errors it returns are simply logged, but do not prevent the container from being started or // removed. </del> <ins> // after either the container creation has failed or the container has been removed. </ins> func (ds *dockerService) performPlatformSpecificContainerCleanup(cleanupInfo *containerCleanupInfo) (errors []error) { if err := removeGMSARegistryValue(cleanupInfo); err != nil { errors = append(errors, err)

Related discussion:
text: What would you like to be : Periodically remove cleanupInfos for old containers from dockershim's map. One way of doing that would be to just forget about s older than say an hour, as they should always be short-lived. Why is this needed: introduced a new in-memory map for the dockershim, that could potentially (in pathological cases) cause memory leaks - for containers that use GMSA cred specs, get created successfully, but then never get started nor removed. This might be okay for the alpha release of the GMSA feature, but should be addressed in the beta. See
/assign wk8
/sig windows
/milestone v1.15
got moved out. let's move this issue with it as well /milestone v1.16
Hello! I'm bug triage lead for the 1.16 release cycle and considering this issue is tagged for 1.16, but not updated for a long time, I'd like to check its status. The code freeze is starting on August 29th (about 1.5 weeks from now), which means that there should be a PR ready (and merged) until then. Do we still target this issue to be fixed for 1.16?
: yup we'd love to have this in 1.16, still waiting for kind reviewers on :) ...
Code change:
DefaultDummyDevice = "kube-ipvs0" connReuseMinSupportedKernelVersion = "4.1" <ins> // https://github.com/torvalds/linux/commit/35dfb013149f74c2be1ff9c78f14e6a3cd1539d1 connReuseFixedKernelVersion = "5.9" </ins> ) // iptablesJumpChain is tables of iptables chains that ipvs proxier used to install iptables or cleanup iptables.

Related discussion:
text: There were two patches merged recently in the kernel that will significantly improve the IPVS proxier: The first patch fixes an issue where a packet is dropped whenever a stale conntrack entry is reused. This caused a 1s delay whenever the stale conntrack entry was used. This was the original reason for setting . More details in The second patch fixes an issue when a source port is reused from a given client and the corresponding destination was deleted. This is easily reproducible when a single client sends a lot traffic to a small set of destinations and one of the destination servers are removed. More details in Based on these two patches, we should start setting (default) starting on Linux v5.9 when those two patches make it to the main line. The new sysctls for the IPVS proxier would be: We should probably wait for v5.9 before making any changes to kube-proxy, this is just a tracking issue so we don't forget.
/sig network /area ipvs
Should probably hold on the PR until v5.9 is released later this year. cc
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Yes it makes sense to wait until a kernel with the patch exists ;) I think we can also avoid touching it and follow the approach "only touch the sysctl we absolutely need, otherwise trust the admin to know what they need"
I install linux-5.9-rc2 in centos7. set /proc/sys/net/ipv4/vs/connreusemode = 1 i have three service: service-a ---service-b --service-c in k8s. service-c return "helloworld" I use ab to benchmark service-a. [root ~]# ab -n -c 1000 http://172.17.2.66:/ This is ApacheBench, Version 2.3 &lt;Copyright 1996 Adam Twiss, Zeus Technology Ltd, Licensed to The Apache Software Foundation, Benchmarking 172.17.2.66 (be patient) Completed 1000 requests Completed 2000 requests Completed 3000 requests Completed 4000 requests Completed 5000 requests Completed 6000 requests Completed 7000 requests Completed 8000 requests Completed 9000 requests Completed requests Finished requests Server Software: Server Hostname: 172.
Code change:
DefaultDummyDevice = "kube-ipvs0" connReuseMinSupportedKernelVersion = "4.1" <ins> // https://github.com/torvalds/linux/commit/35dfb013149f74c2be1ff9c78f14e6a3cd1539d1 connReuseFixedKernelVersion = "5.9" </ins> ) // iptablesJumpChain is tables of iptables chains that ipvs proxier used to install iptables or cleanup iptables.

Related discussion:
text: 17.2.66 Server Port: Document Path: / Document Length: 11 bytes Concurrency Level: 1000 Time taken for tests: 4.128 seconds Complete requests: Failed requests: 0 Write errors: 0 Total transferred: bytes HTML transferred: bytes Requests per second: 2422.76 [#/sec] (mean) Time per request: 412.753 [ms] (mean) Time per request: 0.413 [ms] (mean, across all concurrent requests) Transfer rate: 302.84 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 16 71.5 4 1004 Processing: 4 216 92.9 202 2340 Waiting: 4 215 92.7 202 2340 Total: 4 232 121.5 215 2341 Percentage of the requests served within a certain time (ms) 50% 215 66% 253 75% 280 80% 299 90% 348 95% 412 98% 490 99% 556 100% 2341 (longest request) [root ~]# ab -n -c 1000 http://172.17.2.66:/ This is ApacheBench, Version 2.3 &lt;Copyright 1996 Adam Twiss, Zeus Technology Ltd, Licensed to The Apache Software Foundation, Benchmarking 172.17.2.66 (be patient) Completed 1000 requests Completed 2000 requests Completed 3000 requests Completed 4000 requests Completed 5000 requests Completed 6000 requests Completed 7000 requests Completed 8000 requests Completed 9000 requests Completed requests Finished requests Server Software: Server Hostname: 172.17.2.66 Server Port: Document Path: / Document Length: 11 bytes Concurrency Level: 1000 Time taken for tests: 7.071 seconds Complete requests: Failed requests: 0 Write errors: 0 Total transferred: bytes HTML transferred: bytes Requests per second: 1414.21 [#/sec] (mean) Time per request: 707.110 [ms] (mean) Time per request: 0.707 [ms] (mean, across all concurrent requests) Transfer rate: 176.
Code change:
DefaultDummyDevice = "kube-ipvs0" connReuseMinSupportedKernelVersion = "4.1" <ins> // https://github.com/torvalds/linux/commit/35dfb013149f74c2be1ff9c78f14e6a3cd1539d1 connReuseFixedKernelVersion = "5.9" </ins> ) // iptablesJumpChain is tables of iptables chains that ipvs proxier used to install iptables or cleanup iptables.

Related discussion:
text: 78 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 9 66.2 2 1019 Processing: 10 661 575.2 372 3603 Waiting: 1 659 573.7 372 3603 Total: 10 670 584.6 380 3607 Percentage of the requests served within a certain time (ms) 50% 380 66% 742 75% 1008 80% 1183 90% 1535 95% 1784 98% 2376 99% 2479 100% 3607 (longest request) [root ~]# ab -n -c 1000 http://172.17.2.66:/ This is ApacheBench, Version 2.3 &lt;Copyright 1996 Adam Twiss, Zeus Technology Ltd, Licensed to The Apache Software Foundation, Benchmarking 172.17.2.66 (be patient) Completed 1000 requests Completed 2000 requests Completed 3000 requests Completed 4000 requests Completed 5000 requests Completed 6000 requests Completed 7000 requests Completed 8000 requests Completed 9000 requests Completed requests Finished requests Server Software: Server Hostname: 172.17.2.66 Server Port: Document Path: / Document Length: 11 bytes Concurrency Level: 1000 Time taken for tests: 13.580 seconds Complete requests: Failed requests: 0 Write errors: 0 Total transferred: bytes HTML transferred: bytes Requests per second: 736.40 [#/sec] (mean) Time per request: 1357.958 [ms] (mean) Time per request: 1.358 [ms] (mean, across all concurrent requests) Transfer rate: 92.05 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 4 6.6 1 49 Processing: 11 1333 491.9 1307 3185 Waiting: 1 1330 491.9 1305 3185 Total: 17 1337 491.
Code change:
DefaultDummyDevice = "kube-ipvs0" connReuseMinSupportedKernelVersion = "4.1" <ins> // https://github.com/torvalds/linux/commit/35dfb013149f74c2be1ff9c78f14e6a3cd1539d1 connReuseFixedKernelVersion = "5.9" </ins> ) // iptablesJumpChain is tables of iptables chains that ipvs proxier used to install iptables or cleanup iptables.

Related discussion:
text: 9 1311 3191 Percentage of the requests served within a certain time (ms) 50% 1311 66% 1565 75% 1679 80% 1748 90% 1911 95% 2129 98% 2384 99% 2650 100% 3191 (longest request) [root ~]# ab -n -c 1000 http://172.17.2.66:/ This is ApacheBench, Version 2.3 &lt;Copyright 1996 Adam Twiss, Zeus Technology Ltd, Licensed to The Apache Software Foundation, Benchmarking 172.17.2.66 (be patient) Completed 1000 requests Completed 2000 requests Completed 3000 requests Completed 4000 requests Completed 5000 requests Completed 6000 requests Completed 7000 requests Completed 8000 requests Completed 9000 requests Completed requests Finished requests Server Software: Server Hostname: 172.17.2.66 Server Port: Document Path: / Document Length: 11 bytes Concurrency Level: 1000 Time taken for tests: 23.720 seconds Complete requests: Failed requests: 936 (Connect: 0, Receive: 0, Length: 936, Exceptions: 0) Write errors: 0 Total transferred: bytes HTML transferred: bytes Requests per second: 421.58 [#/sec] (mean) Time per request: 2372.009 [ms] (mean) Time per request: 2.372 [ms] (mean, across all concurrent requests) Transfer rate: 47.77 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 5 7.5 1 49 Processing: 8 2345 3364.8 333 Waiting: 0 1744 3030.9 277 Total: 8 2350 3364.8 340 Percentage of the requests served within a certain time (ms) 50% 340 66% 1434 75% 3390 80% 5490 90% 8669 95% 9233 98% 99% 100% (longest request) the last time tcp connections of service-b :
/assign Sorry, but I do not understand what are you trying to say.
Code change:
DefaultDummyDevice = "kube-ipvs0" connReuseMinSupportedKernelVersion = "4.1" <ins> // https://github.com/torvalds/linux/commit/35dfb013149f74c2be1ff9c78f14e6a3cd1539d1 connReuseFixedKernelVersion = "5.9" </ins> ) // iptablesJumpChain is tables of iptables chains that ipvs proxier used to install iptables or cleanup iptables.

Related discussion:
text: : (
/cc
Will this be implemented in 1.21?
/area kube-proxy
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-contributor-experience at . /lifecycle stale
Code change:
VolumeSubpath:                  {Default: true, PreRelease: featuregate.GA}, ConfigurableFSGroupPolicy:      {Default: false, PreRelease: featuregate.Alpha}, BalanceAttachedNodeVolumes:     {Default: false, PreRelease: featuregate.Alpha}, <del> VolumeSubpathEnvExpansion:      {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.19, </del> CSIBlockVolume:                 {Default: true, PreRelease: featuregate.GA, LockToDefault: true}, // remove in 1.20 CSIInlineVolume:                {Default: true, PreRelease: featuregate.Beta}, RuntimeClass:                   {Default: true, PreRelease: featuregate.Beta},

Related discussion:
text: /kind cleanup /sig storage /sig node Description: Feature gate VolumeSubpathEnvExpansion was GA in 1.17 and is marked for removal in 1.19 Related Issues: GA Release:
/assign
/cc