Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature request] Have a way to patch workload/service #142

Open
mathieu-benoit opened this issue May 16, 2024 · 2 comments
Open

[feature request] Have a way to patch workload/service #142

mathieu-benoit opened this issue May 16, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@mathieu-benoit
Copy link
Contributor

mathieu-benoit commented May 16, 2024

I have this use case where I want to inject "security context" for each workload / service in my generated compose.yaml file.

Today, I need to manually do that:

cat <<EOF > compose.override.yaml
services:
  ${WORKLOAD_NAME}-${CONTAINER_NAME}:
    read_only: true
    cap_drop:
      - ALL
    user: "1000"
EOF

But when I have multiple workloads or containers, this is a bit painful.

A post-processing yq command may be able to help too, but same approach, not user friendly.

Do we have an opportunity to introduce a new provisioner type (or something else) in order to patch a workload or a service directly in score-compose generate?

@mathieu-benoit mathieu-benoit added the enhancement New feature or request label May 16, 2024
@astromechza
Copy link
Member

@mathieu-benoit what kind of expression language do you suggest? how complex should it be?

Tools like jq and yq are very good at what they do, so we will never do something of equivalent complexity, but there is room for something simple potentially using the existing Go template language?

We wouldn't use a provisioner or workload resource like humanitec does, because it breaks the Score resource contracts but we could do something specific to score compose here?

@mathieu-benoit
Copy link
Contributor Author

mathieu-benoit commented May 21, 2024

using the existing Go template language

Yeah, I think this would be a great experience, consistent with the existing provisioners too.

jq/yq could still be used outside score-compose but this feels disconnected and not a consistent experience for end users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants