jiebi/CodeConvo huggingface dataset:
Change:
// BindClusterFlags is a convenience method to bind the specified flags to their associated variables func BindClusterFlags(clusterInfo *clientcmdapi.Cluster, flags *pflag.FlagSet, flagNames ClusterOverrideFlags) { <del> flags.StringVarP(&clusterInfo.Server, flagNames.APIServer, flagNames.APIServerShort, "", "The address of the Kubernetes API server") </del> <ins> flags.StringVarP(&clusterInfo.Server, flagNames.APIServer, flagNames.APIServerShort, "", "The address and port of the Kubernetes API server") </ins> flags.StringVar(&clusterInfo.APIVersion, flagNames.APIVersion, "", "The API version to use when talking to the server") flags.StringVar(&clusterInfo.CertificateAuthority, flagNames.CertificateAuthority, "", "Path to a cert. file for the certificate authority.") flags.BoolVar(&clusterInfo.InsecureSkipTLSVerify, flagNames.InsecureSkipTLSVerify, false, "If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure.")

Discussion:
If the apiserver only listens on one physical IP, then you'd have to use kubectl --server to specify the host. The help message says specify the IP, connection refused: both IP and Port, then ok: So, is it possbile to default the port to 8080 if no port specified at command line or read it from the config file /etc/kubernetes/apiserver, which is 8080 too. If it's impossible to default the port to 8080, it needs an update of the help message at least, like: or add --port flag.
The options are: the port from the port by trying if none is specified a flag the documentation I think (4) is the way to go (I'm not lazy I swear). (1) requires access to the API server's filesystem which is off-limits. (2) seems like it'll work for some configs and is a default that may change. (3) is more verbose and adds yet another flag. Will send a PR.
Change:
// Strip value validation. StripValueValidation bool <ins> // Strip nullable. StripNullable bool </ins> // AllowNonStructural indicates swagger should be built for a schema that fits into the structural type but does not meet all structural invariants AllowNonStructural bool }

Discussion:
With in a CRD we get: This is because gnostic's OpenAPI proto types have no nullable support. Luckily CRDs keep working because in the upper error case we don't stop serving, just set the SSA schema to nil.
Thanks for reporting!
I think it should be "This is because gnostic's OpenAPI v2 proto types have no nullable support.". The problem is that we're not supposed to pass-in v3.
Source:
OK, We'll write a test and fix this, thanks Stefan!
/reopen This still happens in slightly different shape: This comes from :
That's a fairly different bug but yes, thanks!
Is this related to the stating that use of "anyOf" wouldn't be allowed after 1.16? We're seeing issue on OpenFaaS after going to 1.17.5 and 1.18. Usually upgrading K8s versions hasn't caused breaking changes and we're trying to figure out where to start with this one.
No. That post was about structural schemas. v1 CRDs are limited to structural schemas. v1beta1 CRDs can continue to create non-structural schemas until v1beta1 is no longer served (in 1.22) Also, is not completely disallowed, specific restrictions inside an clause (like ) are what are not allowed ("logical constraints using oneOf, allOf, anyOf, not are allowed").
extracted the newly found issue to to track separately with isolated reproducer /close
Closing this issue. <detailsIn response to : extracted the newly found issue to to track separately 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
Change:
MASTER_OS_DISTRIBUTION=${KUBE_MASTER_OS_DISTRIBUTION:-gci} NODE_OS_DISTRIBUTION=${KUBE_NODE_OS_DISTRIBUTION:-gci} <del> MASTER_IMAGE=${KUBE_GCE_MASTER_IMAGE:-cos-stable-60-9592-84-0} </del> <ins> MASTER_IMAGE=${KUBE_GCE_MASTER_IMAGE:-cos-stable-60-9592-90-0} </ins> MASTER_IMAGE_PROJECT=${KUBE_GCE_MASTER_PROJECT:-cos-cloud} NETWORK=${KUBE_GCE_NETWORK:-e2e}

Discussion:
The debian-based CVM image is going to be deprecated in September. We should: Change the default OS image for GCE cluster setup script. This means that all the GCE CI builds will use the new default OS image. Add deprecation warning to the cluster setup script if CVM is specified. Maintain the node e2e test coverage for CVM for 1.8. /cc
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten /remove-lifecycle stale
The CVM tests were turned off a while ago.
Change:
plug, _, tmpDir, _ := newTestWatchPlugin(t, fakeClient, true) defer os.RemoveAll(tmpDir) <ins> attachmentWatchCreated := make(chan core.Action) // Make sure this is the first reactor fakeClient.Fake.PrependWatchReactor("volumeattachments", func(action core.Action) (bool, watch.Interface, error) { select { case <-attachmentWatchCreated: // already closed default: // The attacher is already watching the attachment, notify the test goroutine to // update the status of attachment. // TODO: In theory this still has a race condition, because the actual watch is created by // the next reactor in the chain and we unblock the test goroutine before returning here. close(attachmentWatchCreated) } return false, nil, nil }) </ins> attacher, err := plug.NewAttacher() if err != nil { t.Fatalf("failed to create new attacher: %v", err)

Discussion:
Which test(s) are flaking: TestAttacherWithCSIDriver Reason for failure: This is flaking rarely enough that it is not caught by our CI jobs, which currently tolerate up to 2 unit test failures per run (!). With that toleration removed in , this flake has been seen (). Reproducible with the following steps: a test binary for the affected package: the affected test using the tool (setting the timeout to a generous timeout relative to the normal test runtime of .02 seconds): failures are seen, look at the logs to see the details about the error: /sig storage cc
/assign can you help investigate this flake?
I have found the root cause. /assign
filed to address this issue.
Change:
// How many seconds to wait for a multipath device if at least two paths are available. multipathDeviceTimeout = 10 <ins> // 'iscsiadm' error code stating that a session is logged in // See https://github.com/open-iscsi/open-iscsi/blob/7d121d12ad6ba7783308c25ffd338a9fa0cc402b/include/iscsi_err.h#L37-L38 iscsiadmErrorSessExists = 15 </ins> ) var (

Discussion:
What happened: In order to communicate with the target, the iscsi plugin creates a new iface. If for some reason an iface with the same name already exists in the node, this command will re-create it and no error will be reported. However, if the iface already exists and is being used by a session, this command will fail and report the error code 15 (). That's because it can't re-create the iface while it's in use by a session. What you expected to happen: The plugin could go ahead and use the existing iface instead of failing. How to reproduce it (as minimally and precisely as possible): pod1 pod2 Here, will re-use the session/iface from the step above. pod1 At this point, k8s will try to delete the session/iface used by pv1. However, it'll fail because the session is currently in use by pv2. pod1 Here the pod's status will be stuck at : Templates used: Anything else we need to know?: problem happens when a custom initiator is used, and it was reported to me that it's necessary in some set-ups in order to "restrict access to LUNs of the storage". to reproduce manually (assuming there's a session using the iface): /sig storage /CC
/assign
is this related to cc
If iface is reused, wouldn't it try to delete it once last volume (from kubelet perspective) is detached?
No
Change:
return isErrCode(err, ErrCodeResourceVersionConflicts) } <del> // IsRequestTimeout returns true if and only if err indicates that the request has timed out. func IsRequestTimeout(err error) bool { return isErrCode(err, ErrCodeTimeout) } </del> // IsInvalidObj returns true if and only if err is invalid error func IsInvalidObj(err error) bool { return isErrCode(err, ErrCodeInvalidObj)

Discussion:
various Oct 30 2023 6pm pst No response Looks like different test are failing with connection timeout errors: One of the tests triggered a core dump: No response /sig
are both suffers from pkg/registry and is from compoent-base, which likely same reason from `
/retitle failing-test: pkg/kubelet/eviction TestManagerWithLocalStorageCapacityIsolationOpen
/sig node
TestManagerWithLocalStorageCapacityIsolationOpen only failed in one of the PRs, so I don't think that specific test is the problem.
ok, rename as see fit. just put owning sigs please for triage.
TestStoreDeleteCollectionWithContextCancellation is the one that seems to be failing across all the failing PRs, so let's start there first. /retitle failing-test: TestStoreDeleteCollectionWithContextCancellation /sig api-machinery
triage link at shows this just starting (happening in CI jobs as well)
image used in the unit test job didn't change around the timeframe this was seen ()
looking for jumps in package unit test runtimes when this failure started happening to see if something is taking longer or stressing the system: ! - cc ! - cc ! - cc Could any of those have introduced changes that could be stressing or exhausting listener connections in unit tests?
the PR in question introduced a poll function around an API call that is unit tested with a fake client i.e. the poll is unit tested, but the fake client has reactors that return error or success right away, so in theory the poll should not be stretched to 1 retries with 1 connection attempts per fake client. while testing locally i did not notice any significant time difference after or the prior i can do some more checks to see what's going on.
merged right at the time the flakes were seen DeleteCollection invokes List, which was modified in that PR to cancel more aggressively cc
I can reproduce about a 10-20% flake rate at HEAD with: failures look like: or while testing that package with , I see ~1300-1500 open connections with this:
Let's revert it then. I looked into it and I don't know from a quick glance why it's failing and I don't have time to debug it now.

I opened
Okay, it looks like we need more debugging to open this PR
one optimization to strip some ~40 fake client connections and 2 seconds from a test:
sounds good, pointed at that commit as well
/triage accepted
Change:
est.lock.Lock() defer est.lock.Unlock() <del> rrv := est.relatedResourceVersions(endpointSlice) </del> <ins> rrv, ok := est.relatedResourceVersions(endpointSlice) if !ok { rrv = endpointSliceResourceVersions{} est.resourceVersionsByService[getServiceNN(endpointSlice)] = rrv } </ins> rrv[endpointSlice.Name] = endpointSlice.ResourceVersion } <ins> // DeleteService removes the set of resource versions tracked for the Service. func (est *endpointSliceTracker) DeleteService(namespace, name string) { est.lock.Lock() defer est.lock.Unlock() serviceNN := types.NamespacedName{Name: name, Namespace: namespace} delete(est.resourceVersionsByService, serviceNN) } </ins> // Delete removes the resource version in this endpointSliceTracker for the // provided EndpointSlice. func (est *endpointSliceTracker) Delete(endpointSlice *discovery.EndpointSlice) { est.lock.Lock() defer est.lock.Unlock() <del> rrv := est.relatedResourceVersions(endpointSlice) delete(rrv, endpointSlice.Name) </del> <ins> rrv, ok := est.relatedResourceVersions(endpointSlice) if ok { delete(rrv, endpointSlice.Name) } </ins> } // relatedResourceVersions returns the set of resource versions tracked for the <del> // Service corresponding to the provided EndpointSlice. If no resource versions // are currently tracked for this service, an empty set is initialized. func (est *endpointSliceTracker) relatedResourceVersions(endpointSlice *discovery.EndpointSlice) endpointSliceResourceVersions { </del> <ins> // Service corresponding to the provided EndpointSlice, and a bool to indicate // if it exists. func (est *endpointSliceTracker) relatedResourceVersions(endpointSlice *discovery.EndpointSlice) (endpointSliceResourceVersions, bool) { </ins> serviceNN := getServiceNN(endpointSlice) vers, ok := est.resourceVersionsByService[serviceNN] <del> if !ok { vers = endpointSliceResourceVersions{} est.resourceVersionsByService[serviceNN] = vers } return vers </del> <ins> return vers, ok </ins> } // getServiceNN returns a namespaced name for the Service corresponding to the

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: The endpointSliceTracker creates a set of resource versions for each service, the resource versions in the set could be deleted when endpointslices are deleted, but the set and its key in the map is never deleted, leading to memory leak. What you expected to happen: The set of resource versions should be delete from endpointSliceTracker when the service is deleted. Environment: Kubernetes version (use ): 1.18.5
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/cc
Change:
} func RunApply(f cmdutil.Factory, cmd *cobra.Command, out, errOut io.Writer, options *ApplyOptions) error { <del> shortOutput := cmdutil.GetFlagString(cmd, "output") == "name" </del> schema, err := f.Validator(cmdutil.GetFlagBool(cmd, "validate"), cmdutil.GetFlagString(cmd, "schema-cache-dir")) if err != nil { return err

Discussion:
What happened: What you expected to happen: yaml output How to reproduce it (as minimally and precisely as possible): Anything else do we need to know: Related PR
Change:
func New(address string, port uint, imageFsInfoProvider ImageFsInfoProvider, rootPath string, usingLegacyStats bool) (Interface, error) { sysFs := sysfs.NewRealSysFs() <del> ignoreMetrics := cadvisormetrics.MetricSet{cadvisormetrics.NetworkTcpUsageMetrics: struct{}{}, cadvisormetrics.NetworkUdpUsageMetrics: struct{}{}} </del> <ins> ignoreMetrics := cadvisormetrics.MetricSet{ cadvisormetrics.NetworkTcpUsageMetrics: struct{}{}, cadvisormetrics.NetworkUdpUsageMetrics: struct{}{}, cadvisormetrics.PerCpuUsageMetrics:     struct{}{}, } </ins> if !usingLegacyStats { ignoreMetrics[cadvisormetrics.DiskUsageMetrics] = struct{}{} }

Discussion:
/kind feature This is the once-per-release cut of a new cAdvisor release, which corresponds to the next kubernetes release. cAdvisor v0.29 corresponds to kubernetes v1.10. /sig node /priority important-soon
self-reminder to add per-cpu stats to ignore metrics when vendoring. reminder to add a release notice that one of the container labels fields is being removed.
/kind bug turns out most of the changes are bug-fixes
please mark this issue as approved-for-milestone, since it certainly seems to be, and it's now code slush. Thanks!
Change:
} containerPort, found := params["container-port"] if found && len(containerPort) > 0 { <del> cPort, err := strconv.Atoi(containerPort) if err != nil { service.Spec.ContainerPort = util.NewIntOrStringFromInt(cPort) } else { </del> <ins> if cPort, err := strconv.Atoi(containerPort); err != nil { </ins> service.Spec.ContainerPort = util.NewIntOrStringFromString(containerPort) <ins> } else { service.Spec.ContainerPort = util.NewIntOrStringFromInt(cPort) </ins> } } else { service.Spec.ContainerPort = util.NewIntOrStringFromInt(port)

Discussion:
expose hostnames --port=80 --container-port=9376 --selector="app=hostnames" get se hostnames -o yaml apiVersion: v1beta1 containerPort: "9376" ... obviously, endpoints controller is not happy.
Change:
return ds.Spec.Template.Spec.Containers[0].Image, nil } <del> func getContainerImageFromE2ETestDaemonset(dsYamlPath string) (string, error) { data, err := e2etestfiles.Read(dsYamlPath) </del> <ins> func getSampleDevicePluginImage() (string, error) { data, err := e2etestfiles.Read(SampleDevicePluginDSYAML) </ins> if err != nil { <del> return "", fmt.Errorf("failed to read the daemonset yaml: %w", err) </del> <ins> return "", fmt.Errorf("failed to read the sample plugin yaml: %w", err) </ins> } ds, err := e2emanifest.DaemonSetFromData(data) if err != nil { <del> return "", fmt.Errorf("failed to parse daemonset yaml: %w", err) </del> <ins> return "", fmt.Errorf("failed to parse daemon set for sample plugin: %w", err) </ins> } if len(ds.Spec.Template.Spec.Containers) < 1 { <del> return "", fmt.Errorf("failed to parse the container image: cannot extract the container from YAML") </del> <ins> return "", fmt.Errorf("failed to parse the sample plugin image: cannot extract the container from YAML") </ins> } return ds.Spec.Template.Spec.Containers[0].Image, nil }

Discussion:
Failing: ` Failing since . Last passing: First failing:
The diff () shows that went in which looks related
/sig node
/kind regression /kind bug /triage accepted
Change:
SRCS = peer-finder ARCH ?= amd64 TARGET ?= $(CURDIR) <ins> GOARM ?= 7 </ins> GOLANG_VERSION ?= latest SRC_DIR = pets/peer-finder export

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: Building the image binaries requires the GOARM variable to be set. Because it is not defined in all Makefiles, cannot the image binaries for the images in question. What you expected to happen: should succeed. How to reproduce it (as minimally and precisely as possible): git clone cd kubernetes/test/images/entrypoint-tester make Anything else we need to know?: Environment: N/A Kubernetes version (use ): N/A Cloud provider or hardware configuration: N/A OS (e.g: ): N/A Kernel (e.g. ): N/A Install tools: N/A Network plugin and version (if this is a network-related bug): N/A Others: N/A
/sig testing
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
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
/remove-lifecycle stale
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
/lifecycle stale
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/remove-lifecycle rotten
Change:
framework.ExpectNoError(err) }) <del> ginkgo.It("should list, patch and delete a LimitRange by collection", func() { </del> <ins> /* Release: v1.26 Testname: LimitRange, list, patch and delete a LimitRange by collection Description: When two limitRanges are created in different namespaces, both MUST succeed. Listing limitRanges across all namespaces with a labelSelector MUST find both limitRanges. When patching the first limitRange it MUST succeed and the fields MUST equal the new values. When deleting the limitRange by collection with a labelSelector it MUST delete only one limitRange. */ framework.ConformanceIt("should list, patch and delete a LimitRange by collection", func() { </ins> ns := f.Namespace.Name lrClient := f.ClientSet.CoreV1().LimitRanges(ns)

Discussion:
4 Oct 2022 [x] Two weeks soak end date: 18 Oct 2022 [x] Test promotion PR: According to this APIsnoop query, there are still three remaining LimitRange endpoints which are untested. listCoreV1LimitRangeForAllNamespacespatchCoreV1NamespacedLimitRangedeleteCoreV1CollectionNamespacedLimitRange Using a number of existing e2e test practices a new has been created for three LimitRange endpoints. The e2e logs for this test are listed below. This query shows which LimitRange endpoints are hit within a short period of running this e2e test example endpoint | useragent --------------------------------------------+
createCoreV1NamespacedLimitRange | should ensure that a limitRange can be listed, patched and deleted by collection deleteCoreV1CollectionNamespacedLimitRange | should ensure that a limitRange can be listed, patched and deleted by collection listCoreV1LimitRangeForAllNamespaces | should ensure that a limitRange can be listed, patched and deleted by collection listCoreV1NamespacedLimitRange | should ensure that a limitRange can be listed, patched and deleted by collection patchCoreV1NamespacedLimitRange | should ensure that a limitRange can be listed, patched and deleted by collection (5 rows) If a test with these calls gets merged, test coverage will go up by 3 point This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/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
Change:
import ( "context" <ins> "encoding/json" </ins> "fmt" "reflect" "strings"

Discussion:
In VMware Tanzu Supervisor Cluster k8s setup, we observed that the AdmissionWebhook tests fail intermittently while updating the namespace with the error: "the object has been modified; please apply your changes to the latest version and try again". This is because the update conflicts with an update being performed by another controller. The test could use Patch while adding labels via types.StrategicMergePatchType to prevent the conflict. /sig testing /sig api-machinery
(sig testing owns e.g. the frameworks but API Machinery own their test cases)
/triage accepted