← Back to issue list

Adds run_once_command rock build option

View original Github issue

Metadata

Project
rockcraft
Number
#745
Type
pull request
State
open
Author
claudiubelu
Labels
Created
Updated
Closed

Current evaluation

Adds a run_once_command rockcraft build option to bypass the Pebble entrypoint for short-lived workloads (K8s Jobs, init containers, *ctl images). Pending, no CI, last activity 2024-11-05; maintainers deferred design to Pebble, and the need was later met by the entrypoint-command key.

Suggested action: close stale

Reason: Inactive since 2024-11-05 (~13 months), with the maintainer stating the design would be handled in Pebble first (pebble#240, pebble#495) and that rockcraft support would need its own design. That design has since shipped as the entrypoint-command key (PR #939, Rockcraft 1.14 release notes: 'New entrypoint-command project key ... bypassing the default Pebble-powered entrypoint'), and no run_once code exists in the current tree, so this PR's approach is superseded.

Impact: 25 Quick Win: 15.0 Staleness: 78 Complexity: 40 Confidence: 80

Issue body

By default, rockcraft sets Pebble as the default entrypoint. However, if the defined service finishes faster than 1 second (either successfully or not), Pebble will ignore the ``on-success`` / ``on-failure`` settings and still continue running. [1] This can be problematic for a few types of rocks meant to be used in Kubernetes. There are some workload types which are expected to eventually finish and stop, entering a Completed state, and Pebble can be preventing that, leading to some workloads / operators not able to work as intended. A service manager like Pebble is not needed in these cases. Some of these cases are: - ``Jobs`` / ``CronJobs``: These are meant as tasks with a finite execution time. They will spawn Pods which are not meant to be endlessly running. - ``InitContainers``: Pods may have these in order to initialize various things before the main workload containers start. The workload containers are not started until the InitContainers have finished executing and entered a Completed state. - ``.*ctl`` type of images (e.g.: kubectl, falcoctl, longhornctl): These can be used in previously mentioned cases, but they may also be used standalone by the user in ephemeral Pods (kubectl run). At the moment, the workaround is to forcefully add a 1.1 sleep to the Pebble service. However, that may not be an option for bare-based rocks, as they wouldn't have the sleep command (unless it would be sliced in, needlessly increasing the image size and rock building complexity). Plus, it is an unpleasant user experience for peple switching to ``rockcraft`` and hitting this issue mostly through trial and error (building the rock, uploading it, deploy in a Kubernetes env if you have one, see if you encounter issues with it or not, notice issue, investigate, find issue, fix, start over). Alternatively, some Helm charts may have the option to completely override the image command / entrypoint, bypassing this issue. But a user would have to *know* about this issue (mostly through trial and error) and amend the Helm chart values accordingly, which is not great, considering that rocks should be drop-in replacements for regular images. But not all Helm charts have this option, in which case, the Helm chart would have to be patched, which is not great either. [1] https://github.com/canonical/pebble/issues/240#issuecomment-1599722443 - [x] Have you signed the [CLA](http://www.ubuntu.com/legal/contributors/)? -----

Evaluation history

Date Model Scores Action Summary
qwen/qwen3.8-27b
Impact: 25
Quick Win: 15.0
Staleness: 78
Complexity: 40
Confidence: 80
close stale Adds a run_once_command rockcraft build option to bypass the Pebble entrypoint for short-lived workloads (K8s Jobs, init containers, *ctl images). Pending, no CI, last activity 2024-11-05; maintainers deferred design to Pebble, and the need was later met by the entrypoint-command key.
qwen/qwen3.6-35b-a3b
Staleness: 85
Complexity: 20
Confidence: 90
close stale Adds a run_once_command build option to bypass Pebble's 1-second service timeout for Kubernetes jobs. Currently inactive for over a year; maintainers deferred the solution to Pebble upstream pending architectural design.
qwen3.6-35b-a3b-mtp-q6
Staleness: 85
Complexity: 45
Confidence: 80
close stale Proposes a run_once_command build option to bypass Pebble for fast-finish Kubernetes workloads. Inactive for 10+ months; maintainer indicated the feature should be implemented upstream in Pebble first, superseding this PR.
qwen3.6-35b-a3b-mtp-q6
Staleness: 85
Complexity: 35
Confidence: 80
keep open Introduces a run_once_command build option to bypass Pebble for one-shot Kubernetes workloads like Jobs and InitContainers. Currently blocked by upstream Pebble discussions and awaiting architectural alignment.
qwen3.6-35b-a3b-mtp-q6
Staleness: 70
Complexity: 40
Confidence: 85
keep open Proposes a run_once_command rockcraft build option to bypass Pebble's entrypoint for one-shot Kubernetes workloads. Currently under discussion; maintainers are evaluating it alongside Pebble changes and inviting the author to join design discussions.

Update history

No update history recorded yet.

Related work

  • Likely Fixed By: rockcraft#939 (confidence 85%)

    feat: add entrypoint-command (#939) shipped in Rockcraft 1.14 and lets rocks override the Pebble OCI entrypoint/CMD, covering the one-shot command use case this PR targets.

  • Blocked By: canonical/pebble#240 (confidence 70%)

    Maintainer cjdcordeiro cited pebble#240 (and pebble#495) as the first place this should be addressed, deferring the rockcraft-side design.

Related issues

Issue Project State Summary Similarity
#866 The image entry point should be configurable, making Pebble optional rockcraft open Request to make Pebble optional by allowing a configurable OCI entrypoint in Rockcraft. The feature was implemented in Rockcraft 1.14.0 via the entrypoint-command key (PR #939), but the issue remains open and unlabelled.
72%