jiebi/CodeConvo huggingface dataset:
Change:
reason = inspectResult.State.Error } result.status.State.Termination = &api.ContainerStateTerminated{ <del> ExitCode:   inspectResult.State.ExitCode, Reason:     reason, StartedAt:  util.NewTime(inspectResult.State.StartedAt), FinishedAt: util.NewTime(inspectResult.State.FinishedAt), </del> <ins> ExitCode:    inspectResult.State.ExitCode, Reason:      reason, StartedAt:   util.NewTime(inspectResult.State.StartedAt), FinishedAt:  util.NewTime(inspectResult.State.FinishedAt), ContainerID: DockerPrefix + dockerID, </ins> } if tPath != "" { path, found := inspectResult.Volumes[tPath]

Discussion:
Currently kubelet reports current status only. If pod's restart policy is not never, the last terminated container status will be override by the latest status, and lost. We should report last terminated container status. I am going to update our v1beta3 api first, but will hold the implementation until we have
did you have a chance to start working on it? IIUC, to support this we need to change the api (), which IIUC from what wrote in some other thread should be done this week. I'm happy to help with it if you want me to help.
Only breaking changes have a deadline. Additive changes can be done at any time.
I am working on this. PR should be ready today or tomorrow.
Also agree with This is not part of API breakage.
Thanks for answers & clarifications and
Change:
f.NamespacePodSecurityLevel = admissionapi.LevelBaseline ginkgo.Describe("CSI Conformance", func() { <del> ginkgo.It("should run through the lifecycle of a StorageClass", func(ctx context.Context) { </del> <ins> /* Release: v1.29 Testname: StorageClass, lifecycle Description: Creating a StorageClass MUST succeed. Reading the StorageClass MUST succeed. Patching the StorageClass MUST succeed with its new label found. Deleting the StorageClass MUST succeed and it MUST be confirmed. Replacement StorageClass MUST be created. Updating the StorageClass MUST succeed with its new label found. Deleting the StorageClass via deleteCollection MUST succeed and it MUST be confirmed. */ framework.ConformanceIt("should run through the lifecycle of a StorageClass", func(ctx context.Context) { </ins> scClient := f.ClientSet.StorageV1().StorageClasses() var initialSC, replacementSC *storagev1.StorageClass

Discussion:
[X] test approval issue : [X] test pr : [X] two weeks soak end date : 22 Sept 2023 [X] test promotion pr : [X] remove endpoint from According to following APIsnoop query, there are three StorageClass endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 7 endpoints. The e2e logs for this test are listed below. This query shows the following StorageClass endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 7 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted /cc
/sig storage
/reopen For tracking the rest of the steps to Promotion
Reopened this issue. <detailsIn response to : /reopen For tracking the rest of the steps to Promotion 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:
}}, }, }, rest.ValidateAllObjectFunc, &metav1.CreateOptions{}) <del> svc = obj.(*api.Service) </del> if err != nil { t.Fatalf("Expected no error: %v", err) } <ins> svc = obj.(*api.Service) </ins> _, _, err = storage.Update(ctx, svc.Name, rest.DefaultUpdatedObjectInfo(&api.Service{ ObjectMeta: metav1.ObjectMeta{ Name:            svc.Name,

Discussion:
Which test(s) are flaking: TestServiceRegistryUpdateDryRun 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: the bug in the test that casts the return value even when the create fails: logging on slow etcd writes because of etcd-io/etcd a test binary for the affected package: the affected test using the tool: failures are seen, look at the logs to see the details about the error: /sig network
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
heh this, was a funny one, we had 1/2^8 chances of using a duplicate, with 1/2^16 I've got 2000 runs without any failures
/assign /remove-triage unresolved
Change:
Per pod IP configuration is provider specific, so when making networking changes, its important to sand-box these as all providers may not use the same mechanisms (iptables, openvswitch, etc.) We should define a grains.conf key that captures more specifically what network configuration environment is being used to avoid future confusion across providers. <ins> ## Further reading The [cluster/saltbase](../cluster/saltbase) tree has more details on the current SaltStack configuration. </ins>

Discussion:
We need to document all the configuration derived by Salt. Ideally this would be a markdown doc that we kept as live documentation within the project. The main reasons to bother: It's hard right now for anyone approaching the directory to get a big picture view of what's is going on, especially across providers. If we ever want to do something disciplined w.r.t. upgrade between (non-dev) versions, we're probably going to need a place to look for the state of the world. Decreasing the velocity with which people can add to Salt configuration will encourage people to delete more Salt configuration. cc
Change:
} } <del> func TestValidationError(t *testing.T) { </del> <ins> func TestValidationErrorUsefulMessage(t *testing.T) { </ins> s := NewFieldInvalid("foo", "bar", "deet").Error() <del> if !strings.Contains(s, "foo") || !strings.Contains(s, "bar") || !strings.Contains(s, "deet") || !strings.Contains(s, ValueOf(ValidationErrorTypeInvalid)) { t.Errorf("error message did not contain expected values, got %s", s) </del> <ins> t.Logf("message: %v", s) for _, part := range []string{"foo", "bar", "deet", ValidationErrorTypeInvalid.String()} { if !strings.Contains(s, part) { t.Errorf("error message did not contain expected part '%v'", part) } } type complicated struct { Baz   int Qux   string Inner interface{} KV    map[string]int } s = NewFieldRequired( "foo", &complicated{ Baz:   1, Qux:   "aoeu", Inner: &complicated{Qux: "asdf"}, KV:    map[string]int{"Billy": 2}, }, ).Error() t.Logf("message: %v", s) for _, part := range []string{ "foo", ValidationErrorTypeRequired.String(), "Baz", "Qux", "Inner", "KV", "1", "aoeu", "asdf", "Billy", "2", } { if !strings.Contains(s, part) { t.Errorf("error message did not contain expected part '%v'", part) } </ins> } }

Discussion:
We now have pretty structured way of validating api object, but the error message to end user is not descriptive, e.g. when creating a replication controller with restart policy 'never', we get: even as simple as label name, we shouldn't assume end-user is familiar with our requirement. Apart from what is wrong, we'd better also give why it is wrong.
The main thing wrong here is not having a useful String() method. and have both been pretty adamant about not attaching code to API objects, but here's a clear UX justification. What if we only attached methods to internal API objects, not versioned ones? Also: this should print %#v, rather than %+v, which would be a BIT more readable.
Orrrr we could switch to spew, which is already a dep.
Actually we're printing a reflect.Value there, which makes no sense at all. I will fix. EDIT: no we aren't, I can't read-- will still fix though
Change:
func ValidateNetworkPolicyUpdate(update, old *networking.NetworkPolicy) field.ErrorList { allErrs := field.ErrorList{} allErrs = append(allErrs, apivalidation.ValidateObjectMetaUpdate(&update.ObjectMeta, &old.ObjectMeta, field.NewPath("metadata"))...) <del> if !reflect.DeepEqual(update.Spec, old.Spec) { allErrs = append(allErrs, field.Forbidden(field.NewPath("spec"), "updates to networkpolicy spec are forbidden.")) } </del> <ins> allErrs = append(allErrs, ValidateNetworkPolicySpec(&update.Spec, field.NewPath("spec"))...) </ins> return allErrs }

Discussion:
I tried to update the NetworkPolicy Spec field with more ingress rules but got It seems NetworkPolicy does not allow update on Spec This means if I want to have more ingress rules, I will have to add those in a new networkpolicy in the same namespace. Any reason why I should not add those in the existing one(update the existing networkpolicy)? Thanks!
This is as designed for now. The expectation is that updates to the spec will be allowed when the NetworkPolicy API moves from v1beta1 to GA.
(And that is planned for Kubernetes 1.6 release.)
good to know, thanks!
Note that the PR to move NetworkPolicy to v1 did not make it into v1.6, but is now planned for 1.7:
Oh, I didn't know about this bug and that didn't get changed in but we can do it as another PR after. (I'm trying to not make any more changes there so we can get it merged.)
Change:
deps = [ "//staging/src/k8s.io/apimachinery/pkg/util/sets:go_default_library", "//staging/src/k8s.io/apimachinery/pkg/util/wait:go_default_library", <ins> "//staging/src/k8s.io/apiserver/pkg/endpoints/metrics:go_default_library", </ins> "//staging/src/k8s.io/apiserver/pkg/server/httplog:go_default_library", "//vendor/k8s.io/klog:go_default_library", ],

Discussion:
What would you like to be : Currently the apiserver has request latencies metrics, which are a histogram of requests to the apiserver. However, these request metrics do not include healthz. While we have recently the ability to get back health check metrics from the healthz endpoint directly, we should also emit this data as a metric, so that we can monitor health check latencies. /assign /sig api-machinery instrumentation
GitHub didn't allow me to assign the following users: jktomer. Note that only , repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : What would you like to be : /sig api-machinery instrumentation 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
I noticed this is informally assigned. Has there been any progress? Is this a place I can fit in?
Yes, I'm working on a PR.
/assign
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
Change:
redisImage    = imageutils.GetE2EImage(imageutils.Redis) nginxImage    = imageutils.GetE2EImage(imageutils.Nginx) busyboxImage  = imageutils.GetE2EImage(imageutils.BusyBox) <ins> agnhostImage  = imageutils.GetE2EImage(imageutils.Agnhost) </ins> ) var (

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: Which test(s) are failing: Kubectl client [] Kubectl logs should be able to retrieve and filter logs [Conformance] Since when has it been failing: Testgrid link: Reason for failure: . . switched to using the docker official redis image and the test string was changed accordingly. On Windows, we still use the old image with the old string, and this caused the test to fail. /cc
Hmm, there doesn't seem to be a redis port for windows 3.2.100 : I guess we can modify the test to find "ready to accept connections" rather that "Ready ... ".
/cc
Change:
est.lock.Lock() defer est.lock.Unlock() <del> rrv := est.relatedResourceVersions(endpointSlice) </del> <ins> rrv, ok := est.relatedResourceVersions(endpointSlice) if !ok { return true } </ins> return rrv[endpointSlice.Name] != endpointSlice.ResourceVersion }

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:
rc.Status.AvailableReplicas == newStatus.AvailableReplicas && rc.Generation == rc.Status.ObservedGeneration && reflect.DeepEqual(rc.Status.Conditions, newStatus.Conditions) { <del> return nil </del> <ins> return &rc, nil </ins> } // Save the generation number we acted on, otherwise we might wrongfully indicate // that we've seen a spec update when we retry.

Discussion:
Is this a request for help? No. What keywords did you search in Kubernetes issues before filing this one? dangling ReplicaSet Is this a BUG REPORT or FEATURE REQUEST? BUG REPORT Kubernetes version (use ): Environment: Cloud provider or hardware configuration: Azure A1 OS (e.g. from /etc/os-release): NAME="Container Linux by CoreOS" ID=coreos VERSION=1235.9.0 VERSIONID=1235.9.0 BUILDID=2017-02-02-0235 PRETTYNAME="Container Linux by CoreOS 1235.9.0 (Ladybug)" ANSICOLOR="38;5;75" HOMEURL="" BUGREPORTURL="" Kernel (e.g. ): Linux node-3-vm 4.7.3-coreos-r2 SMP Thu Feb 2 02:26:10 UTC 2017 x8664 Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz GenuineIntel GNU/Linux Install tools: own Others: What happened: Created new deployment by altering the image tag of the deployment descriptor and using kubectl apply -f "". Noticed that one container of the previous deployment stayed there. What you expected to happen: All containers from the previous deployment should have been terminated. How to reproduce it (as minimally and precisely as possible): I cannot reliably trigger this, I do several deployments per hour and sometimes this problem manifests itself. Anything else we need to know: Deployment descriptor:
Can you also post the output of kubectl get deployment tviftttapp -o yaml kubectl get rs (dangling rs) -o yaml When this manifests again?
Here are the current deployment, the dangling RS, and the "good" RS. Deployment: Dangling RS: Current RS:
It seems that status.availableReplicas for the new replica set is never correctly updated to 2. Short term if you stop using minReadySeconds (minReadySeconds=2 doesn't offer you much anyway), this problem should stop. Long term, we should fix the status update. cc:
can one of you guys paste logs from the controller manager when this issue occurs? Log level should be ideally set to 2.

I managed to reproduce it:
Will close this one once is cherry-picked into 1.5
4 is out and contains a fix that should force the Deployment to be resynced eventually and have availableReplicas updated. Not optimal yet but eventually consistent. I have queued up some follow-up work to refine the resync.
Does anyone know when version 1.5.4 OR 1.6 will be available using Redhat package downloads (in RPM form) ? I only see version 1.5.2 being the latest there. I have the same problem that is being discussed in this thread and want to upgrade so that my K8S cluster can support Deployments.
Change:
- deleteStorageV1VolumeAttachment - getInternalApiserverAPIGroup - getResourceAPIGroup <del> - listCoreV1PersistentVolumeClaimForAllNamespaces </del> - listStorageV1CSINode - listStorageV1StorageClass - listStorageV1VolumeAttachment <del> - patchCoreV1NamespacedPersistentVolumeClaim </del> - patchCoreV1NamespacedPersistentVolumeClaimStatus <del> - patchCoreV1PersistentVolume </del> - patchCoreV1PersistentVolumeStatus - patchStorageV1CSINode - patchStorageV1StorageClass - patchStorageV1VolumeAttachment - patchStorageV1VolumeAttachmentStatus <del> - readCoreV1NamespacedPersistentVolumeClaim </del> - readCoreV1NamespacedPersistentVolumeClaimStatus <del> - readCoreV1PersistentVolume </del> - readCoreV1PersistentVolumeStatus - readStorageV1CSINode - readStorageV1StorageClass - readStorageV1VolumeAttachment - readStorageV1VolumeAttachmentStatus <del> - replaceCoreV1NamespacedPersistentVolumeClaim </del> - replaceCoreV1NamespacedPersistentVolumeClaimStatus <del> - replaceCoreV1PersistentVolume </del> - replaceCoreV1PersistentVolumeStatus - replaceStorageV1CSINode - replaceStorageV1StorageClass

Discussion:
[X] test approval issue : [X] test pr : [x] two weeks soak end date : 11 Sept 2023 [x] test promotion pr : [x] remove endpoint from According to following APIsnoop query, there are two PersistentVolume and three PersistentVolumeClaim endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 13 endpoints. The e2e logs for this test are listed below. This query shows the following PV and PVC endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 13 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/cc
/reopen For tracking the rest of the steps to Promotion
Reopened this issue. <detailsIn response to : /reopen For tracking the rest of the steps to Promotion 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:
return allErrs } <ins> if len(audiences) > 1 && !structuredAuthnFeatureEnabled { allErrs = append(allErrs, field.Invalid(fldPath, audiences, "multiple audiences are not supported when StructuredAuthenticationConfiguration feature gate is disabled")) } </ins> seenAudiences := sets.NewString() for i, audience := range audiences { fldPath := fldPath.Index(i)

Discussion:
For example, should not let you set discovery URL when the feature gate is not enabled. I believe this only impacts library users, as direct usage in KAS requires the file based config, which is feature gated. /assign enj aramase /milestone v1.32
Change:
patchedJob, err = jobClient.Get(context.TODO(), jobName, metav1.GetOptions{}) framework.ExpectNoError(err, "Unable to get job %s", jobName) patchedJob.Spec.Suspend = pointer.BoolPtr(false) <ins> if patchedJob.Annotations == nil { patchedJob.Annotations = map[string]string{} } </ins> patchedJob.Annotations["updated"] = "true" updatedJob, err = e2ejob.UpdateJob(f.ClientSet, ns, patchedJob) return err

Discussion:
[x] Test approval issue : [x] Test PR : - Needed an update on the handling of anotations 27 March 2022 [x] Two weeks soak end date : 6 April 2022 [x] Test promotion PR : [x] Update Test PR: 15 April 2022 [x] Two weeks soak end date : 4 May 2022 with start of 1.25 [x] Update Test Promotion: According to these APIsnoop queries, there are still four remaining Job endpoints which are untested. Using a number of existing e2e test practices a new has been created for this job lifecycle test. The e2e logs for this test are listed below. This query shows the endpoints hit within a short period of running the e2e test If a test with these calls gets merged, test coverage will go up by 4 points 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
/reopen for tracking e2e testgrid and promotion PR
/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:
framework.Failf("ginkgo.Failed to delete pod %s: %v", testAgnhostPod.Name, err) } }() <del> err = f.WaitForPodRunning(testAgnhostPod.Name) </del> <ins> err = f.WaitForPodReady(testAgnhostPod.Name) </ins> framework.ExpectNoError(err, "failed to wait for pod %s to be running", testAgnhostPod.Name) runCommand := func(arg string) string {

Discussion:
Per PR the test fails to error properly. One line of particular interest from that PR: If you wonder why it does not fail on docker, that's because the test does not report the error correctly but fails the same way. This issue is intended to track the discussion and resolution of making this test error properly so that it is useful to CI Signal /sig networking /cc
The label(s) cannot be appled. These labels are supported: <detailsIn response to : Per PR the test fails to error properly. One line of particular interest from that PR: If you wonder why it does not fail on docker, that's because the test does not report the error correctly but fails the same way. ` /cc </details
I'm following up on this in
/sig network
Change:
# comments below, and for poorly implemented tests, please quote the # issue number tracking speed improvements. GCE_SLOW_TESTS=( <del> # TODO: add deployment test here once it will become stable "AutoscalingsSuite.*viasreplicationController" </del> # Before enabling this loadbalancer test in any other test list you must # make sure the associated project has enough quota. At the time of this # writing a GCE project is allowed 3 backend services by default. This

Discussion:
Per our email discussion while getting 1.1 out the door. It looks like this never happened, though, which means we're not running autoscaling tests against GCE on the 1.1 branch, (we were running it on GKE with the 1.1-features job, but I'm removing that job in ). I'd once again like to (strongly) suggest that we mirror test suites running against release branch to jobs running against master, so that we avoid this problem of accidentally not running tests when we think we are. I'd much rather have a perhaps-unnecessary slow/HPA/whatever suite than continually try to figure out where slow/HPA/whatever tests are running, depending on if I'm looking at release jobs versus jobs running against master. cc
+1 We should be running the autoscaling tests in slow or continuous.
Change:
expectedScope: "resource", }, { <ins> name: "POST resource scope", requestInfo: &request.RequestInfo{ Verb:              "create", Namespace:         "my-namespace", IsResourceRequest: false, }, expectedScope: "resource", }, { </ins> name: "namespace scope", requestInfo: &request.RequestInfo{ Namespace:         "my-namespace",

Discussion:
I've observed, that some metrics has and labels. (create) requests are "single resource", therefor they should be classified as . Def: customresourcehandler uses , which is based on the RequstInfo only: the RequestInfo is based only on the requests: method and url example: e.g: Since this RequestInfo has Name and Namespace empty, it is classified as . In a similar way it could be explained why: There's a mismatch in scope classification between built-in and custom resources: The key difference - the check if either "name" was provided OR it is a : Where the metrics.CleanScope ONLY checks, if name is not-empty. Tested: = v1.20 There were other scope related issues <1.20 and the distinction is not obvious. <details</details<details</details<details</details<details</details<details</details
/sig api-machinery
/triage accepted