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: Templates for Creating Namespaces / Form in UI to Fill Template Variables #6990

Open
sspreitzer opened this issue Oct 20, 2023 · 2 comments
Labels
kind/proposal An issue that reports a new feature proposal to be discussed stale Automatic label to stale issues due inactivity to be closed if no further action

Comments

@sspreitzer
Copy link

Summary
Adding a feature to enable templates to create namespaces and filling template variables.

Background and rationale
Aside from deploying Helm charts and others, creating namespaces is not templated at the moment.

Allowing for namespace templates and UI forms would add namespace provisioning in which custom labels and annotations could be added to namespaces which could be further processed in policies, etc..

Description

  • A configurable namespace template
  • A ui form description to create a new namespace from that template

Acceptance criteria
Admins can define a namespace template and users can use that template to create a namespace.

Eg. configuration:

namespace:
  template: |
    apiVersion: v1
    kind: Namespace
    metadata:
      name: {{ .name }}
      annotations:
        snakeoil.inc/multi-network-zone: {{ .network-zone }}
        snakeoil.inc/owner: {{ .email }}
  form:
    - name: name
      type: string
      description: Name of the Namespace
    - name: network-zone
      type: string
      default: default-zone
      description: Network Zone
    - name: email
      type: string
      description: Your Email

Additional context

Instead of having to select a namespace in the UI to create a Helm deployment, it could also be thought of to have the namespace be created as part of the Helm deployment. By specifying the Namespace name at the deployment, the Helm Chart including a values.schema.json and a Namespace definition

@sspreitzer sspreitzer added the kind/proposal An issue that reports a new feature proposal to be discussed label Oct 20, 2023
@absoludity
Copy link
Contributor

Interesting, thanks @sspreitzer . Currently the Kubeapps UX is oriented around working within a namespace, while still allowing you to create new namespaces via the menu, within which you can then work:

image

Within that current UX, I can't see how we could enable installing into a new namespace in the UX without confusion (as you're always operating in the context of the current namespace). But yes, being able to include a template so that new namespaces created by users (with the current UX) could be useful. Not sure about users filling in further template variables when creating a namespace. We try to strike a balance of ease-of-use, reducing the complexity for people to simply deploy apps in their cluster. When a feature seems to be on a similar level of complexity as using the helm/kubectl CLI, we tend to leave it for the CLI. So in this case, enabling admins to specify a template that will simply be used when the user creates a namespace (using the current UX), is a great suggestion as it doesn't require any further complexity for the user. Adding variables within that template that the user fills out while creating a namespace - while possible, may or may not be worth the effort of creating a simple UX to allow that generally within Kubeapps. Let's keep it in mind when we're working on the namespace switcher/creator.

Thanks!

@antgamdia antgamdia added this to the Community requests milestone Jan 8, 2024
Copy link

stale bot commented Mar 17, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale Automatic label to stale issues due inactivity to be closed if no further action label Mar 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/proposal An issue that reports a new feature proposal to be discussed stale Automatic label to stale issues due inactivity to be closed if no further action
Projects
Status: 🗂 Backlog
Development

No branches or pull requests

3 participants