Allow developer to specify run action user on Processes

[tcdowney]

This adds a new field to the Process called user which is used to override the default run action user from vcap to something else. The use case this specifically solves is allowing Windows apps to opt-in to running as the built-in Windows ContainerUser user. It makes configuring user a bit more straightforward for Docker applications as well, but is not useful for the cflinux stacks since those stacks only support the vcap user.

Currently the list of permitted users is controlled by a new capi-release BOSH property called cc.allowed_process_users (see cloudfoundry/capi-release#555), but a possible future enhancement would be to make run_user and build_user first-class properties on Stack resources so that stacks could declare what users they support explicitly.

See #4372 for more details on the use cases this solves.

I plan on submitting follow-up PRs to support this configuration via Manifests and on Tasks.

• I have reviewed the contributing guide

• I have viewed, signed, and submitted the Contributor License Agreement

• I have made this pull request to the main branch

• I have run all the unit tests using bundle exec rake

• I have run CF Acceptance Tests

[sethboyles]

Interestingly I can get dora to work with user root, which is not surprising, but rolling deployments no longer work. The first instance comes up as 'running'. I think there might be some extra checks on whether or not an instance is 'routable' that is preventing it from progressing. I'd have to revisit the DeploymentUpdater code, though.

I think the same thing is happening with docker apps if you set 'root' user. You can do a plain old restart, though.

Do you think user should be tracked on Revisions?

[tcdowney]

Interestingly I can get dora to work with user root, which is not surprising, but rolling deployments no longer work. The first instance comes up as 'running'. I think there might be some extra checks on whether or not an instance is 'routable' that is preventing it from progressing. I'd have to revisit the DeploymentUpdater code, though.

I think the same thing is happening with docker apps if you set 'root' user. You can do a plain old restart, though.

Do you think user should be tracked on Revisions?

I will experiment with this, I realized I'm not copying user over when duplicating the process during the deployment. Not sure about tracking it on Revisions. From a purist standpoint it probably should be tracked, but in practice I think you will set this once and rarely (or never) change it for the life of the app. Will play around with this some more, though.

[tcdowney]

I think user is a reserved (?) column on MySQL (only tested with Postgres locally), I'm going to rename the column to action_user (but keep APIs the same).

Edit: I was wrong about this. user is fine as a column name, my idempotency test wasn't correct and was not truly idempotent on MySQL.

[tcdowney]

@sethboyles I can't reproduce deployment failures after making this change:

18abaff

Regarding adding user to a Revision. I think if we do that it will function like commands on a Process. Which have their own table called revision_process_commands. I don't think we should have a revision_process_users table in addition -- maybe that table should have all process level revision info? I think maybe that should be separate scope from this story though.

[sethboyles]

I agree. We should probably treat revision_process_commands as revision_processes or something if we have more process details we want to track. But it's not like we track health_check or readiness_health_check on revisions, so we probably don't need to add user just yet.

[tcdowney]

Docs tests are failing with a 429. I think Github may be rate limiting access to the OSBAPI spec file for some reason.
It's unrelated to this PR though @sethboyles @Samze

[jochenehret]

This change causes the "Docker Application Lifecycle" tests of the CATs suite to fail:
https://concourse.app-runtime-interfaces.ci.cloudfoundry.org/teams/capi-team/pipelines/capi/jobs/gyro-exp-tests/builds/38
https://concourse.app-runtime-interfaces.ci.cloudfoundry.org/teams/capi-team/pipelines/capi/jobs/olaf-mysql-tests/builds/39

  [FAIL] [docker] Docker Application Lifecycle running a docker app without a start command [BeforeEach] handles docker-defined metadata and environment variables correctly
  /tmp/build/1f5f819e/cf-acceptance-tests/docker/docker_lifecycle.go:80
  [FAIL] [docker] Docker Application Lifecycle running a docker app with a start command [BeforeEach] retains its start command through starts and stops
  /tmp/build/1f5f819e/cf-acceptance-tests/docker/docker_lifecycle.go:53
  [FAIL] [docker] Docker Application Lifecycle running a docker app without a start command [BeforeEach] when env vars are set with 'cf set-env' prefers the env vars from cf set-env over those in the Dockerfile
  /tmp/build/1f5f819e/cf-acceptance-tests/docker/docker_lifecycle.go:80
  [FAIL] [docker] Docker App Lifecycle CredHub Integration when CredHub is configured service bindings [JustBeforeEach] in assisted mode the app should see the service creds
  /tmp/build/1f5f819e/cf-acceptance-tests/docker/credhub_enabled.go:105

I found the following stack trace in the cloud controller logs:

{"timestamp":"2025-06-23T11:22:28.000598027Z","message":"Request failed: 500: {\"errors\"=\u003e[{\"title\"=\u003e\"UnknownError\", \"detail\"=\u003e\"An unknown error occurred.\", \"code\"=\u003e10001, \"test_mode_info\"=\u003e{\"detail\"=\u003e\"unexpected character (after ) at line 1, column 1 [parse.c:706] in '\", \"title\"=\u003e\"CF-EncodingError\", \"backtrace\"=\u003e[\"/var/vcap/data/packages/cloud_controller_ng/15dbf508b71c470d5ed4a0e29f62d3d68928ae12/cloud_controller_ng/app/models/runtime/process_model.rb:582:in `load'\", \"/var/vcap/data/packages/cloud_controller_ng/15dbf508b71c470d5ed4a0e29f62d3d68928ae12/cloud_controller_ng/app/models/runtime/process_model.rb:582:in `docker_run_action_user'\", \"/var/vcap/data/packages/cloud_controller_ng/15dbf508b71c470d5ed4a0e29f62d3d68928ae12/cloud_controller_ng/app/models/runtime/process_model.rb:399:in `run_action_user'\", \"/var/vcap/data/packages/cloud_controller_ng/15dbf508b71c470d5ed4a0e29f62d3d68928ae12/cloud_controller_ng/app/presenters/v3/process_presenter.rb:31:in `to_hash'\", 

Can you please check and provide a fix?

[tcdowney]

Yes, I'll take a look and fix it. Thanks for letting me know @jochenehret

PR here: #4415