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] Support for ephemeral environment deployments #6458

Open
oanasc opened this issue Feb 6, 2024 · 0 comments
Open

[Feature] Support for ephemeral environment deployments #6458

oanasc opened this issue Feb 6, 2024 · 0 comments
Labels

Comments

@oanasc
Copy link

oanasc commented Feb 6, 2024

Is your feature request related to a problem? Please describe.

From every git branch we deploy an ephemeral environment in our develop k8s cluster. The application name and components require an additional suffix appended in the name in order to deploy several versions of the same application with a unique name and not clash with one another, in our case we use the branch name to generate a suffix.

Describe the solution you'd like

  1. A possible solution could involve allowing a new variable nameSuffix in the metadata which if present will be automatically appended to all the component, traits, workflows, policy names and to the context.name and context.appName
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: webwithsa
  nameSuffix: mybranch
  namespace: vela-dev
spec:{}
  1. Another option is to implement the same nameSuffix and allow cue templating in the application.yaml so we can use the context to generate the final name
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: webwithsa
  nameSuffix: mybranch
  namespace: vela-dev
spec:
  components:
    - name: component1 + context.nameSuffix
      type: webservice
      properties:
        image: oamdev/hello-world

If possible option 2 would be better as there could be alot more places the suffix needs to be used like an application with env variables pointing to another component service name, or a database name.

Describe alternatives you've considered
I tested the sub app model where a app yaml is defined as a component, and although that could work it creates an additional application that is confusing for end users

Additional context

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

No branches or pull requests

2 participants