Infer Pebble run arguments when configured for a single service

[addyess]

When using rockcraft to define a single service for the container image, the rockcraft developer is allowed to define the pebble layer for their services:

services:
    app:
        override: replace
        command: node server.js [ extra-arguments ]
        startup: enabled
        on-success: shutdown
        on-failure: shutdown
        working-dir: /lib/node_modules/node_web_app

This configures pebble of course to run this app at startup with a command that's got some nice arguments. All is well

until...

Let's say this service is indented to be a replacement for a very standard kubernetes service like coredns

      containers:
      - name: "coredns"
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        args: [ "-conf", "/etc/coredns/Corefile" ]
        volumeMounts:
        - name: config-volume
          mountPath: /etc/coredns
{{- range .Values.extraSecrets }}
        - name: {{ .name }}
          mountPath: {{ .mountPath }}
          readOnly: true

One can replace the image in the helm chart with the rock version ✅ The bug here is subtle but this image will fail to start the container -- because of the args

Since pebble is the entrypoint into the container -- it doesn't know what to do with the args [ "-conf", "/etc/coredns/Corefile" ]

Solutions:

• A rockcraft guru or pebble guru would say "just change the args to ["--args","coredns", "-conf", "/etc/coredns/Corefile" ] and everything will be fine.
• A rockcraft guru may also say "you could use a dangerous entrypoint-service argument

I'd like to propose another possible solution:

Could pebble knowing it's own configuration, accept arguments if it's only managing 1 service -- and pass those arguments on to the running service in place of the default args?

[benhoyt]

@addyess Are the two solutions you mentioned workable? What's wrong with either of them?

@cjdcordeiro Do you have any thoughts here? Is entrypoint-service actually dangerous?

[jnsgruk]

entrypoint-service isn't "dangerous" as such, but it modifies the command-line behaviour which is why it's tagged that way. That said, it was introduced for exactly this sort of reason, where Pebble is ultimately started by something which isn't, and will never be, aware of pebble's CLI structure.

[cjdcordeiro]

I understand the feature request and I've actually thought about it myself. IMO, yes, it would make sense that whenever there is only 1 pebble service available, the rock would default its entrypoint-service to it.

having said that, this would need to be a rockcraft feature, and not pebble's, because Pebble can't know if the provided arguments are given to pebble itself, or a pebble service. This is why the Pebble enter --args was created.

So the idea is: should rockcraft automatically set the entrypoint-service with basis on the number of provided services? I'm open to consider this. It isn't as simple as it sounds though, because OCI images can be overlayed, as well as Pebble layers, which means it is quite easy to introduce new services without involving Rockcraft, thus breaking the initial assumption. Nonetheless, I think we need to see entrypoint-service through for a while longer, to assess how many users actually rely on it. At the moment, as said above, it isn't "dangerous", but it creates a deviation in the interface provided by rocks. So we need more data points before making the decision to make this entrypoint-service the standard and default behavior.

@addyess for now I suggest you log this request either internally, as Product Feedback, or directly in Rockcraft's issue board, such that we can get upvotes for people wanting the same.

[addyess]

thanks for the mighty wonderful discussion. With my renewed understanding that entrypoint-service isn't dangerous, just non-standard -- we can adjust all the rocks we're building since the helm charts and user's presumed understanding of those rock'd services relies on the container args to be the args for the running application, and not necessarily arguments for pebble itself.

thanks to all for the clarification on the docs.