### What would you like to be added?

/sig apps
/assign

Want to get feedback on this proposal. I can proceed to KEP process later, if it looks worthy for it to everyone.

**Feature Summary**  
This RFE proposes adding an optional parameter to Kubernetes CronJobs that allows setting a maximum number of successful executions for a job, after which the job automatically is suspended. This feature would help manage resource usage (optionally) and ensure tasks do not run indefinitely and benefit those use cases where you want to check something for few times but not forever, similar to the 'at' command but within a Kubernetes environment.

**Context**  
While Kubernetes supports scheduled jobs via CronJobs, there is currently no native feature to automatically stop these jobs after a certain number of successful completions. This enhancement would allow users to set limits on job executions, which is interesting in some cases.

**Technical Details**  
Implementation could involve extending the `CronJob` specification to include an `.spec.successfulJobCountLimit` optional attribute, which defines the maximum number of successful executions before the crojob suspends. Kubernetes' job controller would need to be enhanced to track the count of successful executions and update the job's active status accordingly.

**Example of cronjob using this optional parameter**
```bash
apiVersion: batch/v1
kind: CronJob
metadata:
  name: example-cronjob
  namespace: default
spec:
  schedule: "0 1 * * *"
  successfulJobHistoryLimit: 3          # This keeps the last three successful job records
  successfulJobCountLimit: 5            # Hypothetical property to suspend the CronJob after 5 successful executions
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure
```


### Why is this needed?

Consider a scenario where temporary cronjobs are created dynamically and jobs are scheduled for specific operational checks or data processing tasks that only need to run a predetermined number of times. Without a native feature to limit executions, developers must implement additional logic to track and suspend the cronjobs.

This feature is particularly beneficial in scenarios such as:
- Jobs that are relevant only for a specific duration or a limited number of executions.
- Certain tasks may need to be run a specific number of times to meet regulatory requirements.
- Environments where jobs need to run a finite number of times to test and validate software under controlled conditions.

### Some notes

Having a finish date/time, instead of force X number of executions is a potential other solution that could work for this use-case.

### Practical use case

In my practical use case, my backend needs to monitor if an Instagram story has been removed. Since Instagram stories are ephemeral and last only 24 hours, I need a system that can perform checks several times within that period. The checks are triggered whenever a new story is detected.

I utilize Kubernetes cronjobs to manage these checks, as Kubernetes provides reliable scheduling to ensure the tasks are executed on time. However, the challenge arises with the cleanup of these dynamically generated cronjobs. As new stories can be added at any time, cronjobs can accumulate rapidly, leading to clutter and unnecessary use of resources and inconsistent results if these are not marked to run for few times during the day. Manually cleaning up these cronjobs isn't practical, especially when managing them in large numbers, which could easily exceed 100.

To address this issue systematically and possibly assist others in the community facing similar challenges, I proposed a Request for Enhancement (RFE). This proposal aims to explore solutions for automating the cleanup process of dynamically generated cronjobs in Kubernetes environments.
RFE Optional CronJob Parameter: Auto-Suspend Kubernetes CronJob After Specified Number of Successful Executions
This is a GitHub Issue
repo:kubernetes
owner:kubernetes
Title : RFE Optional CronJob Parameter: Auto-Suspend Kubernetes CronJob After Specified Number of Successful Executions
Issue date:

--- start body ---
### What would you like to be added?

/sig apps
/assign

Want to get feedback on this proposal. I can proceed to KEP process later, if it looks worthy for it to everyone.

**Feature Summary**  
This RFE proposes adding an optional parameter to Kubernetes CronJobs that allows setting a maximum number of successful executions for a job, after which the job automatically is suspended. This feature would help manage resource usage (optionally) and ensure tasks do not run indefinitely and benefit those use cases where you want to check something for few times but not forever, similar to the 'at' command but within a Kubernetes environment.

**Context**  
While Kubernetes supports scheduled jobs via CronJobs, there is currently no native feature to automatically stop these jobs after a certain number of successful completions. This enhancement would allow users to set limits on job executions, which is interesting in some cases.

**Technical Details**  
Implementation could involve extending the `CronJob` specification to include an `.spec.successfulJobCountLimit` optional attribute, which defines the maximum number of successful executions before the crojob suspends. Kubernetes' job controller would need to be enhanced to track the count of successful executions and update the job's active status accordingly.

**Example of cronjob using this optional parameter**
```bash
apiVersion: batch/v1
kind: CronJob
metadata:
  name: example-cronjob
  namespace: default
spec:
  schedule: "0 1 * * *"
  successfulJobHistoryLimit: 3          # This keeps the last three successful job records
  successfulJobCountLimit: 5            # Hypothetical property to suspend the CronJob after 5 successful executions
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure
```


### Why is this needed?

Consider a scenario where temporary cronjobs are created dynamically and jobs are scheduled for specific operational checks or data processing tasks that only need to run a predetermined number of times. Without a native feature to limit executions, developers must implement additional logic to track and suspend the cronjobs.

This feature is particularly beneficial in scenarios such as:
- Jobs that are relevant only for a specific duration or a limited number of executions.
- Certain tasks may need to be run a specific number of times to meet regulatory requirements.
- Environments where jobs need to run a finite number of times to test and validate software under controlled conditions.

### Some notes

Having a finish date/time, instead of force X number of executions is a potential other solution that could work for this use-case.

### Practical use case

In my practical use case, my backend needs to monitor if an Instagram story has been removed. Since Instagram stories are ephemeral and last only 24 hours, I need a system that can perform checks several times within that period. The checks are triggered whenever a new story is detected.

I utilize Kubernetes cronjobs to manage these checks, as Kubernetes provides reliable scheduling to ensure the tasks are executed on time. However, the challenge arises with the cleanup of these dynamically generated cronjobs. As new stories can be added at any time, cronjobs can accumulate rapidly, leading to clutter and unnecessary use of resources and inconsistent results if these are not marked to run for few times during the day. Manually cleaning up these cronjobs isn't practical, especially when managing them in large numbers, which could easily exceed 100.

To address this issue systematically and possibly assist others in the community facing similar challenges, I proposed a Request for Enhancement (RFE). This proposal aims to explore solutions for automating the cleanup process of dynamically generated cronjobs in Kubernetes environments.
--- end body ---
