prepared-issues.json

[
    {
        "body": "**Describe the bug**\r\nUnable to pull default repo\r\n```\r\ncould not load clusterpackages: could not fetch package repository index: failed to fetch https://packages.dl.glasskube.dev/packages/index.yaml: Get \"https://packages.dl.glasskube.dev/packages/index.yaml\": net/http: TLS handshake timeout\r\n```\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. basic installation process\r\n - glasskube bootstrap command\r\n\r\n**Expected behavior**\r\nSee packages from default repo\r\n\r\n**Screenshots**\r\n<img width=\"938\" alt=\"image\" src=\"https://github.com/user-attachments/assets/ae5e701e-46fb-47c8-af6c-6bb1cf6b1938\">\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: 1.28.9\r\n - Provider: AKS\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: 0.24.0\r\n - CLI version: 0.24.0\r\n\r\n**Additional context**\r\nAdd any other context about the problem here.\r\n",
        "bug": true,
        "needs-triage": true,
        "title": "Running on private cloud / behind corporate proxy"
    },
    {
        "body": "**Describe the bug**\r\nWhen installing a package with a dependency, the parent package usually goes to status \"Pending\" until the next reconciliation. During that time, the `ownedPackages` does not contain the required package yet, so if one deletes the package during its in Pending status, the required package will not get purged (it has the `installed-as-depdency` annotation though). \r\n\r\nHaven't debugged it yet, but could be similar to #1261?\r\n\r\nFix should probably be to set the `ownedPackages` already at the first reconciliation. ",
        "bug": true,
        "needs-triage": true,
        "title": "`ownedPackages` should be set earlier"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nUpgrading more complex packages often shouldn't feel like a black box operation.\r\n\r\n**Describe the solution you'd like**\r\nHave possibility to determine a resource level diff between a suspended package and the actual state, as well as a package from a different repository / version.\r\n\r\n**Describe alternatives you've considered**\r\n-\r\n\r\n**Additional context**\r\nFor helm charts we should perform a helm diff to get the difference between the actual manifests.\r\nRelated to https://github.com/glasskube/glasskube/issues/1306\r\n",
        "enhancement": true,
        "needs-triage": true,
        "title": "Introduce upgrade diff"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nHaving bigger and more complex packages installed will require some kind of manual intervention at certain point. At the moment it is required to scale to operator deployment to 0 instances to stop package reconciliation.\r\n\r\n**Describe the solution you'd like**\r\nIntroduce a feature where a package can be get suspended. While a package is suspended it will not get reconciled by the package operator.\r\n\r\n- The suspension should be possible via UI and CLI. \r\n- A suspended package should clearly highlighted a suspended in the UI.\r\n\r\n**Describe alternatives you've considered**\r\n- In ArgoCD the feature is called \"Sync\"\r\n\r\n**Additional context**\r\nMost useful with: https://github.com/glasskube/glasskube/issues/1307\r\n",
        "component: cli": true,
        "component: package-operator": true,
        "component: ui": true,
        "enhancement": true,
        "title": "Introduce (cluster)package reconciliation suspension"
    },
    {
        "body": "**Describe the bug**\r\nthe error message \"Not able to fetch package repo index\" to extend beyond the designated div. This affects the visibility and usability of the alert.\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Add your own repo with wrong url or different url\r\n2. Open the website\r\n\r\n\r\n**Expected behavior**\r\n![msedge_1QPHUjLvAP](https://github.com/user-attachments/assets/aa99fe89-64f0-4bd4-9911-aad6babd6c03)\r\n\r\n**Screenshots**\r\n![msedge_MUUlQfa13c](https://github.com/user-attachments/assets/5eb4ac38-daf8-4bbf-bf01-d75380d5181c)\r\n\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: [e.g. Kubernetes, OpenShift]\r\n - Version: [e.g. 1.29]\r\n - Provider: [e.g. AWS, minikube]\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: [e.g. v0.0.1]\r\n - CLI version: [output of `glasskube --version`]\r\n\r\n**Additional context**\r\nAdd any other context about the problem here.\r\n",
        "bug": true,
        "needs-triage": true,
        "title": "Package Repo Index Fetch Error: Content Overflow in Toast Component"
    },
    {
        "body": "**Describe the bug**\r\nWhen uninstalling a failed namespaced package, it seems like some dependencies and/or components are not deleted, only the parent/root package is deleted.\r\n\r\n**To Reproduce**\r\n1. Install tracecat\r\n2. configure it invalidly to have it in status \"Failed\"\r\n3. uninstall it\r\n\r\nThe database and temporal (and therefore its components) are still in the cluster. \r\n\r\n**Expected behavior**\r\nThey should be cleaned up.\r\n\r\n**Screenshots**\r\nIf applicable, add screenshots to help explain your problem.\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: [e.g. Kubernetes, OpenShift]\r\n - Version: [e.g. 1.29]\r\n - Provider: [e.g. AWS, minikube]\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: latest dev\r\n - CLI version: latest dev",
        "bug": true,
        "needs-triage": true,
        "title": "Dependencies/Components not cleaned up when parent has status failed"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nFor example, when we patch environment variables most likely the containers need to be restarted in order to read the new config values. There might also be other occasions?\r\n\r\n**Describe the solution you'd like**\r\nTBD.\r\n",
        "component: package-operator": true,
        "enhancement": true,
        "title": "Restart deployments when package spec changes"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nCame up during the implementation of #1253 – we introduced a fallback in the dependency manager a while ago in #1177. This has some issues when a package is available in multiple repos, as the underlying `repoAdapter` returns an error because it can't decide which repo to pick the manifest from.\r\n\r\n**Describe the solution you'd like**\r\nThat error shouldn't happen, because in this case we already have an installed package and therefore know which repository to use. \r\n",
        "enhancement": true,
        "title": "Dependency manager should use repo name if known"
    },
    {
        "body": "**Describe the bug**\r\n`failed to validate dependencies of tracecat (v0.10.1+1):  is not available in any repository`\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Install tracecat via UI\r\n2. When it has succeeded, uninstall it via UI. \r\n\r\nOne or two error toasts appear with the above message. However, uninstallation proceeds and once the package is deleted, the UI redirects back to the package overview page as expected.\r\n\r\nWhat I found so far from debugging: \r\n* the dependency manager is looking for a package with an empty name, it's just not very visible in the error message\r\n* this happens in `addDependencies`, at the point where we try to `dm.getVersions`, which is called with name \"\"\r\n* that name is the `dep.PackageName`\r\n\r\nI didn't go any further yet to look why this name is empty. \r\n\r\nMaybe such empty names are even fair at the point of uninstallation. If that is the case, these specific kind of errors should be handled / ignored and not be transported back to the user. \r\n\r\n**Expected behavior**\r\n* No error toasts during uninstallation. \r\n* The error messages are suboptimal, maybe it makes sense to always put package names and stuff like that in \"\", and to wrap errors inside the dm once more (e.g. \"failed to get versions\").\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: all\r\n - Provider: minikube\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: latest dev\r\n - CLI version: latest dev\r\n\r\n**Additional context**\r\nFound during #1253 implementation, but most likely unrelated. \r\n",
        "bug": true,
        "title": "Dependency validation error during uninstallation – not available in any repository"
    },
    {
        "body": "Hello, \r\n\r\nI am using GlassKube Package with Flux CD for GitOps. \r\nOne of the primary features of Flux CD is its rbac based multitanency. https://github.com/fluxcd/flux2-multi-tenancy\r\n\r\nBascially, when I onboard a \"tenant\" in my multitenant cluster, all resources related to my tenant exist in its own namespace and tied to their own serviceAccount with permissions tied through K8s rbac.\r\n\r\nWhen I sync my glasskube packages, although the flux kustomizations I use to do so, refer to my tenant's service account, the resulting deployed workloads (deployment, statefulsets etc) assume default service account. \r\n\r\nI am using helm charts in glasskube packages. So the \"translated\" HelmRelease flux manifest has a missing serviceAccount field. \r\n\r\nTo support this feature:\r\n\r\n* Glasskube package accepts ServiceAccount name in its manifests for deploying workloads. \r\n* The serviceAccount name is also used for resulting flux HelmRelease instance, when using a helm chart in Glasskube. ",
        "enhancement": true,
        "needs-triage": true,
        "title": "Add ServiceAccount  support for Glasskube Packages"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\nPackages often have some configurations that belong to the same configuration groups. If there are a *lot* of configurations the configuration page *and* the interactive cli questionair becomes confusing.\n\n**Describe the solution you'd like**\nAdd a `valueDefinitionGroups` configuration block inside the package manifest with metadata:\n\n* \"rank\" (to sort value Definition groups) (not needed as we will use a list)\n* label\n* description\n\nAdditionally each `valueDefinition` should have `group` attribute.\n\n**Describe alternatives you've considered**\nOther nested value groups.\n\n**Additional context**\nI'm open for different implementation methods that make it easier to install packages with multiple configuration options.",
        "enhancement": true,
        "needs-triage": true,
        "title": "Introduce value definition groups"
    },
    {
        "body": "**Describe the bug**\r\nOn smaller screens the new blog appearance doesn't auto-adjust the image thumbnail aspect ratio, resulting in cut off border as can be seen in the screenshot attached below. \r\n\r\n**To Reproduce**\r\nOpen https://glasskube.dev/blog/ on a laptop screen\r\n\r\n**Expected behavior**\r\nImages adjust automatically to smaller screens and borders are not cut off\r\n\r\n**Screenshots**\r\n<img width=\"1507\" alt=\"Screenshot 2024-09-08 at 11 07 57\" src=\"https://github.com/user-attachments/assets/a75d39cd-143f-4e04-9b39-b77b3a020279\">\r\n",
        "bug": true,
        "needs-triage": true,
        "title": "Adjust blog image aspect ratio to adapt to different screen sizes"
    },
    {
        "body": "**Describe the bug**\r\nOn mobile screen devices the newly added search bar now overlaps and covers the GitHub star counter component right beside it. \r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\nOpen https://glasskube.dev on a mobile device (screenshot also added below)\r\n\r\n**Expected behavior**\r\nNo overlap, usable search component as well as a visible star counter. \r\n\r\n**Screenshots**\r\n![WhatsApp Image 2024-09-08 at 11 29 37 AM](https://github.com/user-attachments/assets/73123650-279a-4c90-995e-94f3bc571d94)\r\n",
        "bug": true,
        "needs-triage": true,
        "title": "Search bar overlaps an blocks the star counter on mobile devices "
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nInstalling packages via the the cli that has a loft of (optional) value definitions with default values is quite cumbersome.\r\n\r\n**Describe the solution you'd like**\r\nAdd a cli argument that skips all questionairs for non-required configuration options that have a default value.\r\nThe cli argument could be called `--defaults`\r\n\r\n**Describe alternatives you've considered**\r\nWe can also call the cli argument:\r\n- `--with-defaults`\r\n- `--use-defaults`\r\n- `--configure-only-required`\r\n- ...\r\n\r\n\r\n**Additional context**\r\nThis feature also helps us during CI workflows in the packages repo, as we don't need to explicitly define default values.\r\nTrieve is also one of the packages the will benefit form this newly added configuration.\r\n",
        "component: cli": true,
        "enhancement": true,
        "title": "Add a cli argument to install packages with the default values for non-required configurations"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nGoreleaser.yaml can define the homebrew builtin functions to generate and install the shell completions in the appropriate directories\r\n\r\n**Describe the solution you'd like**\r\nit would be convenient to have shell completion automatically on install with homebrew\r\n\r\n**Describe alternatives you've considered**\r\nCurrently there are instructions on how to generate and source the completions post install. \r\n\r\n**Additional context**\r\nhttps://docs.brew.sh/Formula-Cookbook\r\nhttps://carlosbecker.com/posts/golang-completions-cobra/\r\n\r\n```\r\n    install: |\r\n      bin.install \"glasskube\"\r\n      bash_completion.install \"completions/glasskube.bash\" => \"glasskube\"\r\n      zsh_completion.install \"completions/glasskube.zsh\" => \"_glasskube\"\r\n      fish_completion.install \"completions/glasskube.fish\"\r\n```",
        "enhancement": true,
        "needs-triage": true,
        "title": "generate completions on homebrew install"
    },
    {
        "body": "### Discussed in https://github.com/glasskube/glasskube/discussions/1175\r\n\r\n<div type='discussions-op-text'>\r\n\r\n<sup>Originally posted by **521xueweihan** September  4, 2024</sup>\r\nWe're thrilled to share that [your project](https://hellogithub.com/en/repository/5bcfc97b9ef44c409ae26d7531072f16) has caught the attention of the HelloGitHub community and has been recognized for its merit. Your work is truly inspiring, and we'd like to invite you to participate in our [HelloGitHub Badge Program](https://hellogithub.com/en/repository/5bcfc97b9ef44c409ae26d7531072f16/embed).\r\n\r\nBy joining, you'll enjoy a few benefits that we believe will complement your project's journey:\r\n\r\n1. **Community Acknowledgement**: The badge serves as a mark of distinction, indicating that your project has met the community's criteria for recommendation.\r\n2. **Visibility Boost**: Wearing the badge can help increase the visibility of your project, potentially drawing the attention of new users and contributors.\r\n3. **Easier Engagement**: The badge acts as a quick reference for users to understand your project, facilitating interaction through likes, comments, and bookmarks.\r\n4. **Feedback Opportunities**: It opens the door for valuable feedback from a diverse user base, which can be instrumental in your project's growth and refinement.\r\n5. **Notable Recognition**: Verified participants will receive a special identifier, highlighting their contributions within the community.\r\n\r\n<img width=\"775\" alt=\"image\" src=\"https://github.com/user-attachments/assets/d97539a9-718d-4b76-a90b-b2566c83336e\">\r\n\r\n\r\nWe invite you to consider joining the [HelloGitHub Badge Program](https://hellogithub.com/en/repository/5bcfc97b9ef44c409ae26d7531072f16/embed) as a way to further engage with the community and enhance your project's presence. It's completely up to you, and we respect your decision either way.\r\n\r\nThank you for being part of this journey with us.\r\n\r\nWarm regards,\r\nThe HelloGitHub Team\r\n\r\n---\r\n\r\nHelloGitHub since launch in 2016 as a monthly newsletter, we've evolved into a thriving community that celebrates and enhances the reach of open-source projects. Today, our community is home to over 20,000 enthusiastic members, and our [open-source project](https://github.com/521xueweihan/HelloGitHub) have garnered a stellar 90,000 GitHub stars.</div>",
        "title": "HelloGitHub Badge"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThe components introduced in #1126 are not visible yet to the user.\r\n\r\n**Describe the solution you'd like**\r\nThe `describe` command and the package detail page should show the components, in a similar manner as done with the dependencies. On the UI we should also link to them: When the package is not installed, it should link to the \"new\" page for namespaced packages, and when it is installed, it should probably link to the page of the installed namespaced package. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\n\r\n",
        "component: cli": true,
        "component: client": true,
        "component: ui": true,
        "enhancement": true,
        "title": "Show package components on UI and CLI"
    },
    {
        "body": "The PackageRepository custom resource definition can not be found, because it doesn't exist yet. But this error is catchable, because we can assume that when the CRD does not exist, there also simply exists no resource of that type. So we don't have to print that error to the console and might be able to do the bootstrap without the force argument (?).",
        "bug": true,
        "component: cli": true,
        "title": "No matches for PackageRepository error should not appear in gitops bootstrap"
    },
    {
        "body": "As shortly discussed, we want to have all input data in all cases in one form. \r\n* The labels of the package detail header will become part of the form. The package detail header then only shows the status (will have to be tried out how that looks, if there is only one label – TBD).\r\n* When advanced options are enabled or the package is not installed, repo and version are changeable, otherwise they are read-only.\r\n* Warnings about advanced options have to be adjusted and should be next to the two fields that can be changed, if enabled.\r\n* The new \"header\" part of the form (containing repo, version and auto updates) will be in the same form as the configuration below.\r\n* Header and config part of the form should be visibly separated, but it should be clear that the save/install button on the bottom is meant to be for the entire page. \r\n\r\nFor that, the template and the endpoints will have to be refactored a bit, and maybe the advanced option information needs to be stored somewhere other then local storage?\r\n\r\nAlso, be aware that this might (?) affect the live reload of the package detail page (there is some logic whether only header or whole page should be refetched). \r\n\r\nFrom a technical point of view, it would be interesting to explore some options for more client-side interactivity (see input config component madness, namespace check, etc.).\r\n\r\nRef #1091",
        "component: ui": true,
        "enhancement": true,
        "title": "Improve package detail page"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWhen a user specifies the `--yes` flag for a CLI command, they generally want to avoid interactivity. Glasskube, however, always asks the user to enter a name for the package. \r\n\r\n**Describe the solution you'd like**\r\nWhen `--yes` is specified, the default name (same as the package name) should be used without asking.\r\n\r\n**Additional context**\r\nThis will help us greatly for our package CI pipelines, see e.g. https://github.com/glasskube/packages/pull/380\r\n",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "title": "`glasskube install` should use default name if `--yes` is specified"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nAs #1155 has shown, during bootstrap the cert-manager job is recreated and new certificates are issued. This can lead to a short time span in the bootstrap process, where certificate errors occur. \r\n\r\n**Describe the solution you'd like**\r\nThere should be a retry logic when applying the default repository, in case the error is a certificate error like shown in the issue. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n**Additional context**\r\n#1155 #1160\r\n",
        "component: cli": true,
        "enhancement": true,
        "title": "Retry applying default package repo during bootstrap in existing installations"
    },
    {
        "body": "**Describe the bug**\r\n\r\nUpdated from v0.13.0 straight to v0.18.0, and this error appeared. However, it seems that most of the stuff has been updated and `glasskube version` shows v0.18.0. \r\n\r\n```\r\n$ glasskube bootstrap\r\nGlasskube will be updated to version v0.18.0 in cluster xxx.\r\nContinue? (Y/n) \r\n\r\n## Installing GLASSKUBE ##\r\n🧊 The next generation Package Manager for Kubernetes 📦\r\n* Fetching Glasskube manifest from https://github.com/glasskube/glasskube/releases/download/v0.18.0/manifest-aio.yaml\r\n* Validating existing installation\r\n* Applying Glasskube manifests\r\nApplying glasskube-validating-webhook-configuration (ValidatingWebhookConfiguration)  90% || (47/52, 5 it/s) [9                                                                                                               Applying glasskube-validating-webhook-configuration (ValidatingWebhookConfiguration)  92% || (48/52, 5 it/s) [9                                                                                                               Applying glasskube (PackageRepository)  92% |████████████████████████████████████    | (48/52, 5 it/s) [9s:0s]* Couldn't apply manifests: Internal error occurred: failed calling webhook \"vpackagerepository.kb.io\": failed to call webhook: Post \"https://glasskube-webhook-service.glasskube-system.svc:443/validate-packages-glasskube-dev-v1alpha1-packagerepository?timeout=10s\": tls: failed to verify certificate: x509: certificate signed by unknown authority\r\n\r\nAn error occurred during bootstrap:\r\nInternal error occurred: failed calling webhook \"vpackagerepository.kb.io\": failed to call webhook: Post \"https://glasskube-webhook-service.glasskube-system.svc:443/validate-packages-glasskube-dev-v1alpha1-packagerepository?timeout=10s\": tls: failed to verify certificate: x509: certificate signed by unknown authority\r\n$ glasskube version\r\n\r\n  ____ _        _    ____ ____  _  ___   _ ____  _____\r\n / ___| |      / \\  / ___/ ___|| |/ / | | | __ )| ____|\r\n| |  _| |     / _ \\ \\___ \\___ \\| ' /| | | |  _ \\|  _|\r\n| |_| | |___ / ___ \\ ___) |__) | . \\| |_| | |_) | |___\r\n \\____|_____/_/   \\_\\____/____/|_|\\_\\\\___/|____/|_____|\r\n\t\r\nglasskube: v0.18.0\r\npackage-operator: v0.18.0\r\n```\r\n\r\nI think the problem is that we also create the default repository custom resource, and this will be validated. At bootstrap time however, the updated controller manager might not be ready yet and run into this error.\r\n\r\nRunning `glasskube bootstrap` again after 2 minutes, a different error occurs:\r\n\r\n```\r\nglasskube bootstrap\r\n⚠️  Glasskube is already installed in this cluster (xxx) in version v0.18.0. You are about to bootstrap this version again.\r\nContinue? (Y/n) \r\n\r\n## Installing GLASSKUBE ##\r\n🧊 The next generation Package Manager for Kubernetes 📦\r\n* Fetching Glasskube manifest from https://github.com/glasskube/glasskube/releases/download/v0.18.0/manifest-aio.yaml\r\n* Validating existing installation\r\n* Applying Glasskube manifests\r\nApplying glasskube-validating-webhook-configuration (ValidatingWebhookConfiguration)  90% || (47/52, 5 it/s) [9                                                                                                               Applying glasskube-validating-webhook-configuration (ValidatingWebhookConfiguration)  92% || (48/52, 5 it/s) [9                                                                                                               Applying glasskube (PackageRepository)  92% |████████████████████████████████████    | (48/52, 5 it/s) [9s:0s]* Couldn't apply manifests: admission webhook \"vpackagerepository.kb.io\" denied the request: validator called with unexpected object type\r\n\r\nAn error occurred during bootstrap:\r\nadmission webhook \"vpackagerepository.kb.io\" denied the request: validator called with unexpected object type\r\n```\r\n\r\nThis is either a bug in the package repo validator (#1094) or the package repository we create is actually incorrect. Either way this only happens in v0.18.0 (not verified).\r\n\r\nNevertheless, both things should be fixed:\r\n1. Directly at bootstrap time, the validator isn't ready yet\r\n2. The default repository must be createable.  \r\n\r\nAlso, luckily the package repo is the last thing that is applied during bootstrap, so all the other things are successfully set up. The error does not appear at all when installing glasskube, only when updating.\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n`glasskube bootstrap`\r\n\r\n**Expected behavior**\r\nNo errors. \r\n\r\n**Screenshots**\r\nIf applicable, add screenshots to help explain your problem.\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: [e.g. 1.29]\r\n - Provider: minikube\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: v0.18.0\r\n - CLI version: v0.18.0\r\n\r\n**Additional context**\r\n",
        "bug": true,
        "title": "Error during bootstrap: package repo webhook certificate problem"
    },
    {
        "body": "See #1084 and #1101, but this time for the UI, i.e. when a user wants to install a new `Package`, they have to enter the namespace which it is going to be installed into, and this should be created if not existent yet. \r\n\r\nOn the package detail page, in the section where the installed packages are listed, there should also be an information that the namespace will be created (which will only be shown if it does not exist yet). \r\n\r\nWhen the user installs this package and this namespace does not exist yet, it should be created automatically. \r\n\r\n**Additional context**\r\nWait for #1101 to be finalized and reuse the functionality – maybe it makes sense to move the namespace check + creation into the installer too.  \r\n",
        "component: ui": true,
        "enhancement": true,
        "title": "UI: Create namespace if necessary before installing a namespaced package"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nCurrently it is only possible to specify the `--host` parameter for the serve command.\r\n\r\n**Describe the solution you'd like**\r\nIt should work similar to the serve command.\r\n\r\n**Describe alternatives you've considered**\r\n-\r\n\r\n**Additional context**\r\nIssue came up during a call Glasskube GitOps template onboarding call with @asaiacai\r\n",
        "enhancement": true,
        "needs-triage": true,
        "title": "Add `--host` parameter for open command."
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nSome packages contain components that are identical or very similar to other packages. There should be a way to reuse these component definitions for multiple packages. A prime example for this would be databases, but other components should be possible as well. \r\n\r\n**Describe the solution you'd like**\r\nA package manifest file can include a list of components that should be installed alongside the package. A component declaration can be very similar to a dependency declaration but there are some differences in how they are handled during installation:\r\n1. In contrast to dependencies, components are not shared between different package installations. \r\n2. Components are always prefixed with the name of the package they are installed as part of.\r\n3. While dependencies are required to be cluster-scoped, components are required to be namespace-scoped. (This requirement follows from the points above and the fact that cluster-scoped packages may include components)\r\n\r\n**Describe alternatives you've considered**\r\nWE also considered adding support for packages that include more than one helm release and then creating helm charts for the components, but this has several disadvantages: \r\n1. Only helm charts are supported (we'd prefer to avoid to depend on helm more than necessary)\r\n2. The version of a component can not be changed independently of the parent package\r\n\r\n**Additional context**\r\nThis is sort of a follow-up of #112 but it became more pressing in the light of current package integration efforts.",
        "component: cli": true,
        "component: package-operator": true,
        "component: repo": true,
        "component: ui": true,
        "enhancement": true,
        "title": "Add support for package subcomponents"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nHi guys! I'm one of the maintainers of https://github.com/paradedb/paradedb. We'd love for ParadeDB to be supported on Glasskube. You can find our Helm chart here, for reference: https://github.com/paradedb/helm-charts.\r\n\r\nWe're built on CloudNativePG with a few extra extensions that we build, so it should be nearly identical.\r\n\r\n**Describe the solution you'd like**\r\n^\r\n\r\n**Describe alternatives you've considered**\r\nN/A\r\n\r\n**Additional context**\r\nHappy to help whenever possible.",
        "needs-triage": true,
        "packages": true,
        "title": "Add support for ParadeDB"
    },
    {
        "body": "**Describe the bug**\r\nUI/CLI should not allow being able to \"Open\" an application before it is fully installed. And handle errors gracefully.\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Click \"Install ArgoCD\" through the UI\r\n2. Click Open while the installation is not yet complete (this is often the case for impatient DevOps engineers.)\r\n3. You will see an error in the UI and the CLI that says `failed to open argo-cd: could not open entrypoint [anonymous]: no pod found for service argocd-server has status ready`\r\n\r\n**Expected behavior**\r\nA clear and concise description of what you expected to happen.\r\n\r\n**Screenshots**\r\n<img width=\"400\" alt=\"Screenshot 2024-08-19 at 5 22 29 PM\" src=\"https://github.com/user-attachments/assets/cc6f77c1-e505-4212-88bd-6d6d5d8f737b\">\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: 1.30\r\n - Provider: Docker Desktop\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version:  0.17.0\r\n - CLI version: 0.17.0\r\n",
        "bug": true,
        "title": "Glasskube should handle errors gracefully while a package is being installed."
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nAdd cluster package that help in enables security, automation, compliance, and governance using policy-as-code\r\n\r\n**Describe the solution you'd like**\r\nAdd cluster package like [Kyverno](https://kyverno.io/) \r\n\r\n**Additional context**\r\nSecurity is one of the most crucial pillars in today's digital landscape. Integrating a Policy-as-Code tool within a Kubernetes cluster is essential for strengthening its security posture. Having a tool like Kyverno or OPA will helpin automate the enforcement of security policies, ensuring that all deployed resources adhere to organizational standards and best practices.\r\n\r\n",
        "needs-triage": true,
        "packages": true,
        "title": "Add Policy Management Cluster Package"
    },
    {
        "body": "**Describe the bug**\r\nWhen running the update check with the CLI, the new version for the package operator is shown as the version of the locally used CLI.\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Run `glasskube version --skip-update-check=false` \r\n2. Newest version for the PackageOperator is shown as `dev` instead of `0.17.0`\r\n```\r\n📣 A newer version of Glasskube is available: dev → 0.17.0\r\n📘 Release notes: https://github.com/glasskube/glasskube/releases/tag/v0.17.0\r\n\r\n❗ Glasskube PackageOperator needs to be updated: 0.16.0 -> dev\r\n💡 Please run `glasskube bootstrap` again to update Glasskube PackageOperator\r\n```\r\n\r\n**Expected behavior**\r\nThe newest version for glasskube should be shown. Same as for the CLI.\r\n`❗ Glasskube PackageOperator needs to be updated: 0.16.0 -> 0.17.0`\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: v1.29.2\r\n - Provider: kind\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: v0.16.0\r\n - CLI version: dev (https://github.com/glasskube/glasskube/commit/31cfe95d2088d3c0166e04b000af4f5a315db03d)",
        "component: cli": true,
        "help wanted": true,
        "title": "CLI update check shows wrong version for PackageOperator"
    },
    {
        "body": "**Describe the bug**\r\n\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behaviour:\r\n1. Install `argocd` into the cluster\r\n2. Install `quickwit` into the cluster and provide `argocd` as the namespace to install\r\n3. Uninstall `argocd`\r\n4. See `quickwit` being deleted together with the namespace\r\n\r\n**Expected behaviour**\r\nSince both cluster packages and packages are being installed in the same namespace. Deleting the cluster package also deletes the namespace and hence the namespace scoped packages with it. Ideally, we should either not allow the user to create packages in namespaces like `argocd` or return an error if we are trying to delete such a namespace with the package in it.\r\n",
        "bug": true,
        "needs-triage": true,
        "title": "Uninstalling cluster packages deletes namespace scoped packages installed in the namespace"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nIt can be frustrating to have lots of dangling namespaces in a cluster that are no longer in use. Glasskube should offer an option to delete the namespace when uninstalling a package.\r\n\r\n**Describe the solution you'd like**\r\nThe `uninstall` command can be invoked with a `--delete-namespace` flag. If this is the case, it should check if there are any Packages installed in that namespace, other than the one that should be uninstalled. If there are, it should print an error message and abort the operation, otherwise it should proceed to delete the `Package` and subsequently the namespace resource.\r\n\r\n**Additional context**\r\nFor context, see #1084.\r\nRelated to: #1101\r\n",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "help wanted": true,
        "title": "Add `--delete-namespace` flag to uninstall command"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nInstalling a namespace-scoped package can be more complicated than necessary if the target namespace does not exist yet. In that case, a user has to resort to `kubectl` or other means to create the namespace before being able to install the package. This should not be necessary.\r\n\r\n**Describe the solution you'd like**\r\nWhen installing a namespace-scoped package, the CLI should check if the target namespace exists and, if it does not, create it after the user has confirmed the install operation (if no `--yes` flag is present) and before the `Package` is created. The installation summary should inform the user that the namespace is going to be created. Example output:\r\n\r\n```\r\n$ glasskube install quickwit -n test\r\nSummary:\r\n * The following packages will be installed in your cluster (minikube):\r\n    1. quickwit of type quickwit in namespace test (version v0.8.1+5)\r\n * Namespace test does not exist and will be created\r\n * Automatic updates will be not enabled\r\n```\r\n\r\n**Additional context**\r\nFor context, see #1084",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "help wanted": true,
        "title": "CLI: Create namespace if necessary when installing a namespace-scoped Package"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nCurrently it is not possible to change the status of package \r\n\r\n**Describe the solution you'd like**\r\nEnable and disable auto updates via the UI.\r\n\r\n**Describe alternatives you've considered**\r\n\r\n**Additional context**\r\nWe will do this together with #1167\r\n",
        "component: ui": true,
        "enhancement": true,
        "title": "Allow enable / disable auto updating for installed (cluster-)packages "
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWe released the `glasskube-autoupdater` package. But it does not get automatically installed if a package with automatic updates is installed or automatic updates get enabled later on.\r\n\r\n**Describe the solution you'd like**\r\nWe should place a warning / hint around the checkbox that in order for auto updates to work, the `glasskube-autoupdater` package needs to be installed. `glasskube-autoupdater` should be a link to the actual package.\r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\n",
        "component: ui": true,
        "enhancement": true,
        "html": true,
        "needs-triage": true,
        "title": "Install `glasskube-autoupdater` if a package with auto update enabled gets installed"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nHelm charts can also be stored in container registries. (e.g. https://github.com/glasskube/packages/pull/277 ). Glasskube doesn't support this yet.\r\n\r\n**Describe the solution you'd like**\r\n\r\n```yaml\r\nhelm:\r\n  repositoryUrl: \"oci://ghcr.io/spinkube/charts/spin-operator\"\r\n  chartName: \"spin-operator\"\r\n  chartVersion: \"0.2.0\"\r\n```\r\n\r\n**Describe alternatives you've considered**\r\nWe can also introduce a new key e.g. `ociRepositoryUrl`.\r\n\r\n**Additional context**\r\nFor Helm OCI we need to reference an `OCIRepository` instead of a `HelmRepository`. See: https://fluxcd.io/flux/cheatsheets/oci-artifacts/#helm-oci\r\n",
        "enhancement": true,
        "needs-triage": true,
        "title": "Support Helm charts stored in container registries ( OCI images )"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nAdditional manifests cannot be tested in our CI / CD pipeline and the lack of the features make private repositories harder.\r\n\r\n**Describe the solution you'd like**\r\nThere should be an option for relative referenced manifests:\r\n\r\ne.g.\r\n\r\n```yaml\r\nmanifests:\r\n  - url: ./keptn-cert.yaml\r\n  - url: ./keptn-issuer.yaml\r\n```\r\n\r\ninstead of\r\n\r\n\r\n```yaml\r\nmanifests:\r\n  - url: https://glasskube.github.io/packages/packages/keptn/v2.1.0+1/keptn-cert.yaml\r\n  - url: https://glasskube.github.io/packages/packages/keptn/v2.1.0+1/keptn-issuer.yaml\r\n\r\n```\r\n\r\n**Describe alternatives you've considered**\r\nFixing it in our packages ci / cd pipeline.\r\n\r\n",
        "enhancement": true,
        "needs-triage": true,
        "title": "Support manifests with a relative url in `package.yaml`"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nCurrently namespaces need to be created manually if used for a package installation. The same applies when uninstalling a package. The namespace needs to be deleted manually. This makes managing of especially namespace scoped packages quite cumbersome.\r\n\r\n**Describe the solution you'd like**\r\n* When installing a package with `glasskube install quickwit --namespace quickwit`, if the namespace doesn't exist, it should be created.\r\n* When uninstalling a package installed with glasskube and the namespace was created by glasskube, the namespace should be deleted.\r\n  * There are additional considerations before deleting a namespace, like if the namespace is used by other resources not managed by glasskube.\r\n* A different option would be to give the user the possibility to create or delete the namespace with the install or uninstall command. Similar to helm with a flag `--create-namespace` or `delete-namespace` .\r\n\r\n#### Subtasks\r\n- [x] https://github.com/glasskube/glasskube/issues/1101\r\n- [ ] https://github.com/glasskube/glasskube/issues/1102\r\n- [x] #1149",
        "enhancement": true,
        "needs-triage": true,
        "title": "Glasskube should manage namespaces if used for installation"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nNamespaced packages can be installed via `glasskube install [package-name]`, and then the namespace will be asked for. If one wants to install it without interactivity, `glasskube install [package-name] [namespace]` can be used. There is also a `--namespace` flag available at the install command, but it doesn't do anything. \r\n\r\n**Describe the solution you'd like**\r\nIt should also be possible to install a namespaced package by using `glasskube install [package-name] --namespace [namespace]`. If both options are used (argument and `--namespace` flag), there should be an error. \r\n\r\n**Describe alternatives you've considered**\r\nRemoving the `--namespace` flag, but I think it would be nice to make a command more clear. \r\n\r\n**Additional context**\r\n\r\n",
        "enhancement": true,
        "needs-triage": true,
        "title": "`glasskube install` should respect `--namespace` flag"
    },
    {
        "body": "**Describe the bug**\r\nRemoving and re-adding a glasskube repository with the same name doesn't update the URL\r\n\r\n**To Reproduce**\r\n```\r\n# Add repository with invalid URL\r\nglasskube repo add test3 https://raw.githubusercontent.com/yeahservice/packages\r\nglasskube repo list\r\n\r\nNAME          URL                                                                                                     DEFAULT  AUTHENTICATION  STATUS     MESSAGE\r\nglasskube     https://packages.dl.glasskube.dev/packages                                                              Yes      None            Ready      repo has 20 packages                                                                                                   \r\ntest3         https://raw.githubusercontent.com/yeahservice/packages                                                  No       None            Not ready  failed to fetch https://raw.githubusercontent.com/yeahservice/packages/index.yaml: wrong status code: 400 Bad Request  \r\n\r\n# Delete repository and re-add with valid URL\r\nglasskube repo delete test3\r\nglasskube repo add test3 https://raw.githubusercontent.com/yeahservice/packages/feature/nginx-ingress-namespace-scoped/packages\r\nglasskube repo add test2 https://raw.githubusercontent.com/yeahservice/packages/feature/nginx-ingress-namespace-scoped/packages\r\n\r\n# test3 repository still checks old URL, while test2 works as expected\r\nglasskube repo list\r\n\r\nNAME          URL                                                                                                     DEFAULT  AUTHENTICATION  STATUS     MESSAGE\r\nglasskube     https://packages.dl.glasskube.dev/packages                                                              Yes      None            Ready      repo has 20 packages                                                                                                   \r\ntest2         https://raw.githubusercontent.com/yeahservice/packages/feature/nginx-ingress-namespace-scoped/packages  No       None            Ready      repo has 20 packages      \r\ntest3         https://raw.githubusercontent.com/yeahservice/packages/feature/nginx-ingress-namespace-scoped/packages  No       None            Not ready  failed to fetch https://raw.githubusercontent.com/yeahservice/packages/index.yaml: wrong status code: 400 Bad Request  \r\n\r\n```\r\n\r\n**Expected behavior**\r\nAfter deleting and adding a repository with the same name but different URL, the URL should also be updated\r\n\r\n**Screenshots**\r\n-\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: v1.29.2\r\n - Provider: Kind\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: v0.13.0\r\n - CLI version: glasskube version dev (commit 6c3e38ea7964b17efc7f5e09766067bec09cab34)\r\n\r\n**Additional context**\r\n-\r\n",
        "bug": true,
        "needs-triage": true,
        "title": "Removing and re-adding a glasskube repository with the same name doesn't update the URL"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThe Glasskube UI shows a warning on top of the page, if client version and cluster version are not equal. It also shows a hint how to update the cluster version:\r\n\r\n![Screenshot from 2024-08-05 11-09-27](https://github.com/user-attachments/assets/9dfd17b4-78c3-4267-b1bc-33c29ba6d048)\r\n\r\nIn GitOps mode however, running only `glasskube bootstrap` directly applies the newer manifests into the cluster, which will in the next reconciliation by argocd be replaced again by whatever is defined in the git repository. \r\n\r\n**Describe the solution you'd like**\r\nThe message in the UI should be different, if gitops mode is enabled in the cluster. It should be: \"... Please update the cluster components to ... by using `glasskube bootstrap --dry-run -o yaml` and pushing the generated manifests into your gitops repository.\"\r\n\r\n**Describe alternatives you've considered**\r\nCompletely remove the \"Please upate...\" sentence, but I think it's a nice hint.\r\n\r\n**Additional context**\r\n",
        "component: ui": true,
        "enhancement": true,
        "help wanted": true,
        "title": "UI version warning text should consider gitops mode"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nSome cluster architectures require multiple ingress controllers for better isolation and configuration of workloads. Nginx ingress also supports this use case and the glasskube package just needs to allow configuration of the underlying helm chart (https://kubernetes.github.io/ingress-nginx/user-guide/multiple-ingress/)\r\n\r\n**Describe the solution you'd like**\r\n\r\n* Change the scope of ingress-nginx package to namespace\r\n* Introduce additional configuration values such as `ingressClass`. These are needed to manage multiple ingress controllers within the same cluster.\r\n\r\n**Describe alternatives you've considered**\r\n-\r\n\r\n**Additional context**\r\n-",
        "enhancement": true,
        "title": "Ingress-nginx package should support namespace scoped installation"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nJust as many other commands, `uninstall` should have a `--dry-run` option to simulate package uninstallation. \r\n\r\n**Additional context**\r\n#629",
        "component: cli": true,
        "enhancement": true,
        "title": "`glasskube uninstall` should support `--dry-run`"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nAlmost every application in the \"CLI for k8s\" space allows using the `KUBECONFIG` environment variable to set the path to the kubeconfig file to use. Glasskube should follow suite and do the same.\r\n\r\n**Describe the solution you'd like**\r\nIf the `KUBECONFIG` environment variable is set to a non-empty string, that value should be used for getting the kubeconfig. It should still be possible to overwrite this with the `--kubeconfig` flag though",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "help wanted": true,
        "title": "Glasskube should honor the KUBECONFIG environment variable"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nA recently shipped [feature](https://github.com/glasskube/glasskube/pull/1027) allows for the use of the `--host` flag to be appended to `glasskube serve` which serves the Glasskube UI on a host different to the default `localhost`. \r\n\r\nThe `Open` button  in the package UI is still associated with localhost (even when the `--host` flag is in use) and therefore is rendered unusable if running glasskube on a remote browserless VM. \r\n\r\n**Describe the solution you'd like**\r\nFor the `Open` button to be associated to whichever IP that is specified by the `--host` flag. To allow for normal entrypoint access even on remote VMs",
        "enhancement": true,
        "title": "Redirect UI open button to serve alternative IP if --host flag is used"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nCurrently in our infrastructure, we have SSL inspection on the Firewall level. \r\n\r\nHence all systems internally need to either have the CA trusted of our network team. Or ignore TLS errors in the worst case. \r\n\r\n**Describe the solution you'd like**\r\nPreferably I would be able to load my own ca certs into the operator and have it trust them. (the underlying nodes of k8s all trust them already ofc) or worst case to have it ignore TLS issues. But would strongly prefer the first option to not have to worry in terms of security.\r\n\r\n",
        "enhancement": true,
        "needs-triage": true,
        "title": "Option to load in custom ca or ignore tls on operator/installer"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nMarkdown is already supported in the description of package configuration values, see #734 \r\n\r\n**Describe the solution you'd like**\r\nThe `glasskube configure` command should also consider markdown when printing the package config descriptions. \r\n",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Markdown support for value description in CLI"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWhen trying to use glasskube in a gitops approach by using `glasskube install [pkg] --dry-run -o yaml`, the output contains a `uid`, which probably should not be there. Same for `generation`, `managedFields` and others. \r\n\r\n**Describe the solution you'd like**\r\nProbably all metadata fields except the `name` and `namespace` should be excluded from the output. \r\n\r\n**Describe alternatives you've considered**\r\nNone\r\n\r\n**Additional context**\r\nWhen trying to install a package this way via argocd, argo cannot sync because the uid field is immutable, but it would be changed.\r\nWhen trying to directly apply the generated yaml with `kubectl`, it works, but the uid is changed.\r\n",
        "component: cli": true,
        "enhancement": true,
        "title": "`glasskube install --gitops` should exclude most `metadata`"
    },
    {
        "body": "**Describe the bug**\r\nWhen uninstalling, the message should contain the removed package, but also all packages that have been required by it (only if they have not been installed manually before that). However, the uninstall message on the UI only shows the primary removed package, although the required package is removed as well.\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. install `keptn` without having `cert-manager` installed\r\n2. uninstall `keptn`\r\n\r\n`cert-manager` is correctly uninstalled as well, but the user does not get the information about that.\r\n\r\n**Expected behavior**\r\nThe uninstall message should show required uninstalled packages again.\r\n\r\nIt should also be checked whether this is correct on the CLI.",
        "duplicate": true,
        "invalid": true,
        "title": "Uninstall message does not show removal of required package"
    },
    {
        "body": "I run glasskube on a remote server without UI. the default serve command listen on 127.0.0.1 only. I check the help message and could find how to change it to 0.0.0.0.\r\n\r\n```\r\n./glasskube  serve --help\r\nStart server and open the UI.\r\n\r\nUsage:\r\n  glasskube serve [flags]\r\n\r\nAliases:\r\n  serve, start, ui\r\n\r\nFlags:\r\n  -h, --help            help for serve\r\n  -l, --log-level int   Level for additional logging, where 0 is the least verbose\r\n  -p, --port int        Port for the webserver (default 8580)\r\n  -s, --skip-open       Skip opening the browser\r\n\r\nGlobal Flags:\r\n      --kubeconfig string   Path to the kubeconfig file, whose current-context will be used (defaults to xxx.kube/config)\r\n      --no-progress         Prevent progress logging to the cli\r\n      --non-interactive     Run in non-interactive mode. If interactivity would be required, the command will terminate with a non-zero exit code.\r\n      --skip-update-check   Do not check for Glasskube updates\r\n\r\n```\r\n\r\n**Describe the solution you'd like**\r\n\r\nIt should be able to listen on other address besdies localhost.\r\n",
        "enhancement": true,
        "title": "Listen on other NIC instead of local host for `glasskube  serve`"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWe differentiate between a value that is empty, and one that is not set, e.g. someone might set an empty string `\"\"` on purpose, but it's not well defined if it means that this value is considered to be \"unset\" or actually empty. The package operator already correctly differentiates between these two cases, but UI and partially CLI do not allow to unset a value yet. It is only possible via GitOps, or on the CLI by using the `--value` arguments. \r\n\r\n**Describe the solution you'd like**\r\nUI+CLI should support unsetting a value.\r\n\r\nDesign proposal for the UI config form:\r\n* Initially we only render the required values.\r\n* Additional values can be added dynamically by the user with an \"Add Value\" button, which triggers some component with a selection of the possible config values, that are not set yet. \r\n* Any values that are not shown on the config form, are considered to be unset.\r\n* Therefore, if someone wants to explicitly set an empty value, they can add this value to the form, and then leave the input field empty.\r\n* Any non-required values can also be deleted from the form. \r\n\r\nOpen for discussion + also needs a proposal for the CLI config input loop.\r\n\r\n**Additional context**\r\nThis came up during testing the quickwit integration of the newly added domain value, which is not required, but the defined regex pattern validation did not allow an empty value. The shortcut was to change the pattern to allow an empty string: https://github.com/glasskube/packages/pull/219\r\n",
        "component: cli": true,
        "component: ui": true,
        "enhancement": true,
        "needs-triage": true,
        "title": "Allow unsetting configuration values on UI/CLI"
    },
    {
        "body": "**Describe the bug**\r\nWhen adding/updating repo URL using the repo client `glasskube repo add <repoName> <repoURL>` The client settings cache does not update automatically (perhaps only on reconciliation) leading to the `glasskube repo list` command to show a repo URL that is not actually being fetched.\r\n\r\n@kosmoz has identified where the logic has to be added to reset repo client cache upon adding new package repositories.  \r\n \r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Go to '...'\r\n2. Click on '....'\r\n3. Scroll down to '....'\r\n4. See error\r\n\r\n**Expected behavior**\r\nA clear and concise description of what you expected to happen.\r\nTo be able to add, delete and add a new repo URL under the same repo name and to always fetch the latest configured URL. \r\n\r\n**Screenshots**\r\nIf applicable, add screenshots to help explain your problem.\r\n![image (1)](https://github.com/glasskube/glasskube/assets/38757612/5c628827-cb39-441f-bf68-c77a742fd09e)\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: [e.g. Kubernetes, OpenShift]\r\n - Version: [e.g. 1.29]\r\n - Provider: [e.g. AWS, minikube]\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: [e.g. v0.0.1]\r\n - CLI version: [output of `glasskube --version`]\r\n\r\n**Additional context**\r\nAdd any other context about the problem here.\r\n",
        "bug": true,
        "component: package-operator": true,
        "go": true,
        "title": "Client settings on glasskube repo client does not update cache"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThe UI footer shows \"Up to date\", even though there is a newer glasskube version available. The meaning of \"Up to date\" is that the CLI and cluster version is equal. If they are not equal, the message \"New version available\" is shown – additionally there is the big update banner at the top of the page. \r\n\r\n**Describe the solution you'd like**\r\nI suggest to remove the extra text like \"Up to date\" and \"New version available\" completely, because \"Up to date\" might be wrong/misleading (it does not mean the user has the latest glasskube version installed right now), and \"New version available\" is redundant (but more inexact) than the update banner that is on the top of the page anyway. \r\n\r\nWe could additionally show a line with \"Latest version available: ...\" with a link to the release page, and a yellow warning sign that a new version is available (but that shouldn't be too pushy, we already show this when starting the server and in all cli commands too). \r\n\r\nOpen for discussion. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n**Additional context**\r\n\r\nCLI == cluster:\r\n![Screenshot from 2024-07-09 16-01-49](https://github.com/glasskube/glasskube/assets/7556574/2d0d8ab5-e2e2-44f8-8d8f-a4a19d026379)\r\n\r\nCLI > cluster: \r\n![image](https://github.com/glasskube/glasskube/assets/7556574/8301dcc9-2305-4413-8353-59e60af7c00d)\r\n\r\n![Screenshot from 2024-07-09 16-09-35](https://github.com/glasskube/glasskube/assets/7556574/f4045bf2-9939-480f-814a-a07bff58610f)\r\n",
        "component: ui": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "UI Footer version messages might be misleading"
    },
    {
        "body": "**Describe the bug**\r\nIf there is at least one `PackageRepository` in the cluster that does not work (e.g. server unavailable), it is not possible to show the details page for any package that has not been installed (both cluster-scoped and namespace-scoped).\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Add a broken repo: `glasskube repo add broken https://not-a-glasskube-repo.org/`\r\n2. Start UI (there should be an error at the top saying that not all repos could be fetched, this is ok)\r\n3. Try to open any package that is not installed\r\n4. See error\r\n\r\n**Expected behavior**\r\nPossible to show package details and install from the working repository.\r\n\r\n**Screenshots**\r\n![image](https://github.com/glasskube/glasskube/assets/16959694/bf01e51d-d2c1-4645-ab21-01ec6bb4f1fa)\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: any\r\n - Version: any\r\n - Provider: any\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: dev (latest main)\r\n - CLI version: dev (latest main)\r\n\r\n**Additional context**\r\nAdd any other context about the problem here.\r\n",
        "bug": true,
        "needs-triage": true,
        "title": "Can not open package details if there is a package repository that does not work"
    },
    {
        "body": "**Describe the bug**\r\nWe only support the following combinations of resource type - manifest scope:\r\n- `ClusterPackage` - `Cluster`\r\n- `Package` - `Namespaced`\r\n\r\nEverything else might lead to undesired behavior.\r\n\r\n**To Reproduce**\r\nCreate a file `package.yaml` with the following contents:\r\n```yaml\r\n# This is WRONG! cert-manager is cluster scoped!\r\napiVersion: packages.glasskube.dev/v1alpha1\r\nkind: Package\r\nmetadata:\r\n  name: cert-manager\r\nspec:\r\n  packageInfo:\r\n    name: cert-manager\r\n    version: v1.15.1+1\r\n```\r\n\r\nRun `kubectl apply -f package.yaml`\r\n\r\n**Expected behavior**\r\nThe creation should be prevented.\r\n\r\n**Screenshots**\r\nCreation is accepted.\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: -\r\n - Provider: -\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: 0.12.1\r\n - CLI version:0.12.1\r\n\r\n**Additional context**\r\nThis validation should be done by the validating admission webhook: \r\n\r\nhttps://github.com/glasskube/glasskube/blob/f9a1dfe58b3cffa2df6f2f50b4280dc29e6e8ff0/internal/webhook/package_validator.go\r\n",
        "bug": true,
        "component: package-operator": true,
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Creation of `Package`/`ClusterPackage` resource should be prevented if the manifest has the wrong `scope`"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nSome external manifest files might have empty documents, see e.g. https://github.com/glasskube/packages/pull/155. The repo client tries to parse them to unstructured objects, but fails because mandatory fields are missing.\r\n\r\n**Describe the solution you'd like**\r\nIgnore empty documents. \r\n\r\n**Additional context**\r\nThis blocks https://github.com/glasskube/packages/pull/155. \r\n",
        "component: client": true,
        "enhancement": true,
        "help wanted": true,
        "title": "Do not consider empty documents when parsing YAMLs"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\nAdd a search functionality in the UI to search the packages easily.\n\n**Describe the solution you'd like**\nUser can search the package in search bar with its name and it shows the installed packages as well as options to install new packages.\nAs well as there should label/filters that can be used to filter packages.\n\nSuggested Filters/Labels could be\n```Installed```\n```Not Installed ```\n\nBased on the scope: \n```Cluster```\n```Namespace```\n In the namespace part, index the available namespaces to choose from.\n\n\n**Describe alternatives you've considered**\n\n**Additional context**\n\n",
        "component: ui": true,
        "enhancement": true,
        "go": true,
        "html": true,
        "needs-triage": true,
        "title": "Search packages feature in the UI"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nCurrently our blog layout is basically the default one and not really appealing.\r\n\r\n**Describe the solution you'd like**\r\nAfter the introduction of  https://github.com/glasskube/glasskube/pull/874 and the image attribute for blog posts, we can also revamp our `/blog` page. Headlamp (also built with Docusaurus) has a very very nice Design we should get a lot of inspiration from: https://headlamp.dev/blog\r\n\r\n**Additional context**\r\n@jakepage91 might be needed to add the image attribute to all past blog posts.\r\n",
        "enhancement": true,
        "help wanted": true,
        "title": "Improve website blog layout",
        "typescript": true,
        "website": true
    },
    {
        "body": "**Describe the bug**\r\nCant get to bootstrap glasskube, I'm using an EKS cluster with Fargate nodes, tried purging and reinstalling.\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Create an EKS cluster\r\n2. glasskube bootstrap\r\n\r\n**Expected behavior**\r\nShould complete bootstrap\r\n\r\n**Screenshots**\r\n![image](https://github.com/glasskube/glasskube/assets/863005/49551a12-9c93-4652-8b7b-ae0ba422f64a)\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: v1.28.9-eks-036c24b\r\n - Provider: AWS\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: v0.12.1\r\n - CLI version: v0.12.1\r\n\r\n**Additional context**\r\nkubectl get nodes -o wide\r\n![image](https://github.com/glasskube/glasskube/assets/863005/745edb8a-54b6-446d-a03e-5953d02739d7)\r\n\r\n",
        "bug": true,
        "title": "Bootstrap Stuck on 96% (Applying glasskube (PackageRepository))"
    },
    {
        "body": "Right now glasskube command has no consistent way of showing flags descriptions. A mix of uppercase and lowercase descriptions are shown. \r\n\r\n![image](https://github.com/glasskube/glasskube/assets/30386061/05b0001d-39ad-483d-9e3f-9ba3b1aae9ae)\r\n\r\n![image](https://github.com/glasskube/glasskube/assets/30386061/a524d7b2-52a0-4d49-9300-7770c5b98677)\r\n\r\nI think we should offer an uppercase description for any command flag.\r\n\r\nI'd like to have the opportunity to fix this issue but I understand that you may offer it as a good-first-issue",
        "component: cli": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Consistent uppercase description for command flags"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThe current package overview page simply shows all packages of all namespaces.\r\n\r\n**Describe the solution you'd like**\r\nThere should be a dropdown element on the top of the page, where the user can choose between all the namespaces of the cluster + one option \"All namespaces\" (default). The overview page should look the same, but show only the packages that are in the selected namespace. \r\n\r\n**Additional context**\r\nIt's a bit tricky, and it might need some refactoring, so we will solve this internally. ",
        "component: ui": true,
        "enhancement": true,
        "title": "Namespace Select for Package Overview Page"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\n`-o` (output) flag is not yet implemented for listing packages, only for clusterpackages.\r\n\r\n**Describe the solution you'd like**\r\nSimilar to `glasskube ls --kind clusterpackage` the command should also support `yaml` and `json` output for packages.",
        "component: cli": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "`glasskube ls --kind package` should also support `-o` flag"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nLike #899, but for the describe command of a package.\r\n\r\n**Describe the solution you'd like**\r\nMessage should be shown below the status, but non-installed packages should not show it at all.\r\n\r\n**Additional context**\r\n#899 \r\n",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Display status message in `glasskube describe` command"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nFair input from here: https://github.com/glasskube/glasskube/issues/836#issuecomment-2200397313\r\nOn the UI we use the non-blocking methods for creating, updating and deleting resources, and we use the `stderr` statuswriter – this is the same as doing these operations on the CLI with `--no-wait`. This is in order to not have long-running requests to the backend (which could potentially look on the UI like it's loading forever). However, we therefore lose track of when the operation has finished and cannot show the correct log message in the server log.\r\n\r\n**Describe the solution you'd like**\r\n\r\nSolution A:\r\nRewrite to use non-blocking blocking operations. For example, we would call `InstallBlocking` on the server, but wrap it in a goroutine such that it doesn't block the client. Unfortunately this makes error handling a bit less obvious, because if there is an error, it cannot be sent via the regular http response anymore, but has to be sent via an SSE message – which would be broadcast to all clients! So if the UI is opened in multiple tabs or browsers, either all of them would get the error message, or we implement another solution there to track which client exactly did the original request, and therefore only send it to this one client.\r\n\r\nSolution B:\r\nDo not log the start of the operation either (probably use `noop` statuswriter), which would also make it consistent at least.\r\n",
        "component: ui": true,
        "enhancement": true,
        "title": "Make server output of user operations consistent"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWhen there is some error happening on the UI (e.g. package uninstallation fails), the error alert is shown at the top of the page. Sometimes (when scrolled to any other position than the top) this is not visible to the user. It seems this is more likely to happen with the sticky header. \r\n\r\n**Describe the solution you'd like**\r\nError messages must be visible on the screen where they happen, and the user should not have to scroll to them.\r\n\r\nPossible solutions are:\r\n* Scroll to the error alert (maybe htmx offers something for that)\r\n* Change from error alert to toasters that will always be on screen. \r\n\r\n**Additional context**\r\nSome htmx knowledge is required for this.\r\n",
        "component: ui": true,
        "enhancement": true,
        "needs-triage": true,
        "title": "UI Error Alerts should not disappear under the sticky header"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nGlasskube doesn't provide any metrics in a standardized way about installed packages, updates and configuration changes\r\n\r\n**Describe the solution you'd like**\r\nExport specific Events as OTel events so the they can get consumed by an OTel infrastructure.\r\n\r\n**Describe alternatives you've considered**\r\nA prometheus metrics endpoint make also make sense.\r\n\r\n**Additional context**\r\n- @henrikrexed will give additional inputs on this issue.\r\n",
        "enhancement": true,
        "needs-triage": true,
        "title": "Expose OpenTelemetry Events for Glasskube packages"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nIf users have an older version of flux installed in their cluster, neither the \"all-in-one\" nor the \"slim\" installation will work.\r\n\r\n**Describe the solution you'd like**\r\nDocument which minimum version of Flux is required if installing Glasskube in the slim version.\r\n\r\n**Describe alternatives you've considered**\r\nDynamically check if flux is already installed during the bootstrap command and print an error and recommend installation method. \r\n\r\n**Additional context**\r\nThe dynamic bootstrap can be a follow-up issue.",
        "documentation": true,
        "enhancement": true,
        "title": "State the required flux version in the bootstrap documentation"
    },
    {
        "body": "**Describe the bug**\r\nThe package detail page and package discussion page share the same header template, which includes logo, name, and the badges showing installation information (version, repo, auto-update). However, on the discussion page, the auto-update value is empty, while on the package detail page it say \"Disabled\" or \"Enabled\". \r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Go to the package detail page of an installed package\r\n2. Click on the discussion badge to get to the discussion page\r\n\r\n**Expected behavior**\r\nAuto update value should be the same as on package detail page. \r\n\r\n**Screenshots**\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: 1.30\r\n - Provider: minikube\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: v0.10.1\r\n - CLI version: dev (not released yet)\r\n\r\n**Additional context**\r\n\r\n",
        "bug": true,
        "component: ui": true,
        "help wanted": true,
        "regression": true,
        "title": "Auto-Update is not shown on discussion page"
    },
    {
        "body": "**Describe the bug**\r\n\r\nDoing:\r\n\r\n```\r\ngk bootstrap --no-progress --non-interactive --yes -o yaml > foobar.yaml\r\n⚠️  Glasskube is already installed in this cluster (default) in version v0.11.0. You are about to bootstrap this version again.\r\n\r\n## Installing GLASSKUBE ##\r\n🧊 The next generation Package Manager for Kubernetes 📦\r\n* Fetching Glasskube manifest from https://github.com/glasskube/glasskube/releases/download/v0.11.0/manifest-aio.yaml\r\n* Validating existing installation\r\n* Applying Glasskube manifests\r\n```\r\n\r\n**To Reproduce**\r\nDo the above command\r\n\r\n**Expected behavior**\r\n\r\nI expect no other input, just the YAML. Yet I get:\r\n```\r\n⚠️  Glasskube is already installed in this cluster (default) in version v0.11.0. You are about to bootstrap this version again.\r\n\r\n## Installing GLASSKUBE ##\r\n🧊 The next generation Package Manager for Kubernetes 📦\r\n* Fetching Glasskube manifest from https://github.com/glasskube/glasskube/releases/download/v0.11.0/manifest-aio.yaml\r\n* Validating existing installation\r\n* Applying Glasskube manifests\r\n```\r\n\r\n**Screenshots**\r\n\r\nN/A\r\n\r\n**Cluster Info (please complete the following information):**\r\n\r\nN/A\r\n\r\n**Glasskube Info (please complete the following information):**\r\n```\r\n▶ gk version\r\nError checking PackageOperator version:\r\n\r\ndeployments.apps \"glasskube-controller-manager\" not found\r\n\r\n  ____ _        _    ____ ____  _  ___   _ ____  _____\r\n / ___| |      / \\  / ___/ ___|| |/ / | | | __ )| ____|\r\n| |  _| |     / _ \\ \\___ \\___ \\| ' /| | | |  _ \\|  _|\r\n| |_| | |___ / ___ \\ ___) |__) | . \\| |_| | |_) | |___\r\n \\____|_____/_/   \\_\\____/____/|_|\\_\\\\___/|____/|_____|\r\n\r\nglasskube: v0.11.0\r\npackage-operator: not installed\r\nGlasskube is not yet bootstrapped. Use 'glasskube bootstrap' to get started.\r\n```\r\n\r\n",
        "bug": true,
        "component: cli": true,
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "The `--no-progress` flag is ignored by the `glasskube bootstrap` command"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nIf a package is in the state \"installation failed\" a user has no further information why the installation failed or if he should do something. Most users won't be able to look up the package status conditions.\r\n\r\n**Describe the solution you'd like**\r\nAdd an additional column that shows that package status description\r\n\r\n\r\n\r\n**Additional context**\r\nUI issue: https://github.com/glasskube/glasskube/issues/898",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "help wanted": true,
        "title": "CLI: Display status message in table when running `glasskube list`"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nIf a package is in the state \"installation failed\" a user has no further information why the installation failed or if he should do something. Most users won't be able to look up the package status conditions.\r\n\r\n**Describe the solution you'd like**\r\nOn the package detail page there should a message with the latest status description\r\n\r\n**Describe alternatives you've considered**\r\nLinking to the Kubernetes Dashboard for example (but this makes not that much sense)\r\n\r\n**Additional context**\r\nRelated cli issue:  https://github.com/glasskube/glasskube/issues/899\r\n",
        "component: ui": true,
        "enhancement": true,
        "go": true,
        "help wanted": true,
        "html": true,
        "title": "UI: Display status condition message on package details page"
    },
    {
        "body": "**Describe the bug**\r\n\r\nAfter using `glasskube telemetry disable` I expect something to be done to the operator / cluster to disable telemetry?\r\n\r\nAlthough it looks like there is no confirmation / changes / other confirmations that it's actually been done?\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\nDo `glasskube telemetry disable`\r\n\r\n**Expected behavior**\r\n\r\nExpect it to do something to the cluster?\r\n\r\n**Screenshots**\r\n\r\nN/A\r\n\r\n**Cluster Info (please complete the following information):**\r\n\r\nN/A\r\n\r\n**Glasskube Info (please complete the following information):**\r\n\r\n```\r\nglasskube version\r\n\r\n  ____ _        _    ____ ____  _  ___   _ ____  _____\r\n / ___| |      / \\  / ___/ ___|| |/ / | | | __ )| ____|\r\n| |  _| |     / _ \\ \\___ \\___ \\| ' /| | | |  _ \\|  _|\r\n| |_| | |___ / ___ \\ ___) |__) | . \\| |_| | |_) | |___\r\n \\____|_____/_/   \\_\\____/____/|_|\\_\\\\___/|____/|_____|\r\n\r\nglasskube: v0.11.0\r\npackage-operator: v0.11.0\r\n```\r\n\r\n**Additional context**\r\nAdd any other context about the problem here.\r\n",
        "bug": true,
        "needs-triage": true,
        "title": "`glasskube telemetry disable` does nothing to the cluster?"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\n\r\nIn the docs it says: https://github.com/glasskube/glasskube/blob/c7e139ffc89cb93a76066c475b92dce0c86fcf22/website/docs/04_design/telemetry.md?plain=1#L49C1-L49C105\r\n\r\nThe information about whether telemetry is enabled or not, is stored **once per cluster installation**. \r\n\r\nBasically I did:\r\n1. Install with `glasskube bootstrap`\r\n2. Realized \"oh no there is telemetry\"\r\n3. Did:\r\n```\r\nglasskube telemetry disable\r\n\r\nGlasskube telemetry is now disabled for cluster default.\r\n```\r\n4. Realized in the docs it's only stored once per cluster installation\r\n5. Think it's actually disabled\r\n6. Go to uninstall bootstrap so I can re-install with telemetry disabled\r\n7. Unable to uninstall bootstrap (see #893 )\r\n\r\n\r\n**Describe the solution you'd like**\r\n\r\nMore clear documentation?\r\n\r\n**Describe alternatives you've considered**\r\n\r\nN/A\r\n\r\n**Additional context**\r\n\r\nN/A",
        "documentation": true,
        "title": "Documentation is confusing regarding cluster telemetry uninstallation."
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\n\r\nWhen doing `glasskube bootstrap` there is ZERO warnings that telemetry will be populated.\r\n\r\nIt also installs this with the telemetry config enabled within the cluster config.\r\n\r\nThis isn't cool as it's a big privacy concern with company kubernetes clusters.\r\n\r\n**Describe the solution you'd like**\r\n\r\nTelemetry warning / \"we are installing telemetry on your cluster\" when using bootstrap\r\n\r\n**Describe alternatives you've considered**\r\n\r\nN/A\r\n\r\n**Additional context**\r\n\r\nN/A\r\n",
        "component: cli": true,
        "component: client": true,
        "component: ui": true,
        "enhancement": true,
        "title": "No warnings that telemetry is installing."
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\n\r\nTelemetry is a **huge** privacy risk with regards to dealing with large clusters and I was disappointed to see that it's defaulted to opt-in without warning.\r\n\r\n**Describe the solution you'd like**\r\n\r\nOpt-in :( Sorry for opening up a can of worms.\r\n\r\n**Describe alternatives you've considered**\r\n\r\nN/A\r\n\r\n**Additional context**\r\n\r\nN/A\r\n",
        "enhancement": true,
        "needs-triage": true,
        "title": "Make telemetry opt-in"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\n\r\nI cannot find a clear way to uninstall the bootstrap / operator.\r\n\r\n**Describe the solution you'd like**\r\n\r\nAbility to uninstall bootstrap\r\n\r\n**Describe alternatives you've considered**\r\n\r\nGoing through --help / documentation.\r\n\r\n**Additional context**\r\n\r\nN/A",
        "documentation": true,
        "title": "Uninstalling bootstrap?"
    },
    {
        "body": "**Describe the bug**\r\n\r\nDocs issue?\r\n\r\n![Screenshot 2024-06-27 at 9 11 29 AM](https://github.com/glasskube/glasskube/assets/6422176/cf7e4cd3-1d86-4319-a9f3-06b9437e98d4)\r\n\r\nI haven't had enough coffee and I bet there are others which feel the same, but with Apps grayed out I would expect there to be a link to documentation explaining why / is it a roadmap thing / how would I be able to enable it / try it out?\r\n\r\n\r\n**To Reproduce**\r\n\r\n\r\nDo `glasskube serve` and try it out.\r\n\r\n\r\n\r\n**Expected behavior**\r\n\r\nApps not grayed\r\n\r\n**Screenshots**\r\n\r\n\r\nSee above / N/A.\r\n\r\n**Cluster Info (please complete the following information):**\r\n\r\n▶ gk version\r\n\r\n  ____ _        _    ____ ____  _  ___   _ ____  _____\r\n / ___| |      / \\  / ___/ ___|| |/ / | | | __ )| ____|\r\n| |  _| |     / _ \\ \\___ \\___ \\| ' /| | | |  _ \\|  _|\r\n| |_| | |___ / ___ \\ ___) |__) | . \\| |_| | |_) | |___\r\n \\____|_____/_/   \\_\\____/____/|_|\\_\\\\___/|____/|_____|\r\n\r\nglasskube: v0.11.0\r\npackage-operator: v0.11.0\r\n\r\n**Glasskube Info (please complete the following information):**\r\n\r\nN/A see above?\r\n\r\n**Additional context**\r\n\r\nN/A",
        "bug": true,
        "needs-triage": true,
        "title": "Apps grayed out with no information / link to documentation"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\n\r\nUnsure if this is a bug or a feature request.\r\n\r\nFor some reason this did not work:\r\n```sh\r\nglasskube install sealed-secrets --skip-update-check --enable-auto-updates=false --dry-run --non-interactive -o yaml\r\n```\r\n\r\nI'm honestly unsure if this is intentional or not?\r\n\r\nTLDR; I would like to be able to see **exactly** what YAML will be applied to my cluster.\r\n\r\nSame for interactive mode too.\r\n\r\nMy use-case is that sometimes I was the raw .yaml for backup purposes, or if I wanted to debug what happened between two version updates (-o yaml on one, -o yaml on the other) and be able to compare the two. \r\n\r\n**Describe the solution you'd like**\r\n\r\nBe able to see what YAML is going to be applied.\r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\nTried debugging.\r\n\r\n**Additional context**\r\n\r\nN/A",
        "enhancement": true,
        "needs-triage": true,
        "title": "Feature: Preview the exact YAML to be used for install?"
    },
    {
        "body": "**Describe the bug**\r\nThese are two different projects. The logo for this project `nginxinc/kubernetes-ingress` is being used as a logo for `kubernetes/ingress-nginx`\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Go to https://glasskube.dev/packages/\r\n2. Scroll down till you see ingress-NGINX\r\n3. See NGINX Ingress Controller's logo.\r\n",
        "bug": true,
        "good first issue": true,
        "help wanted": true,
        "title": "The website shows the Community Ingress controller using NGINX Ingress Controllers logo.",
        "website": true
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWe currently have a mix of youtube embeds with [youtube](https://github.com/search?q=repo%3Aglasskube%2Fglasskube%20www.youtube.com&type=code) and the [youtube-nocookie](https://github.com/search?q=repo%3Aglasskube%2Fglasskube+www.youtube-nocookie.com&type=code) domain.\r\n\r\n**Describe the solution you'd like**\r\nOnly use the youtube-nocookie domain.\r\n\r\n\r\n**Additional context**\r\nThis is also relevant for new embeds \r\n",
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "html": true,
        "title": "Migrate all embedded youtube videos to the youtube-nocookie domain",
        "website": true
    },
    {
        "body": "**Describe the bug**\r\n`glasskube open quickwit` does not work\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Install quickwit\r\n2. open quickwit\r\n3. See error\r\n\r\n**Expected behavior**\r\nOpen the UI\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: 1.30.0\r\n - Provider: minikube\r\n\r\n**Glasskube Info (please complete the following information):**\r\nglasskube: v0.10.1\r\npackage-operator: v0.10.1\r\n\r\n**Additional context**\r\nrelated to \r\n- https://github.com/glasskube/glasskube/issues/844\r\n",
        "bug": true,
        "go": true,
        "regression": true,
        "title": "`glasskube open quickwit` does not work"
    },
    {
        "body": "When building the website by running `npm run build` in the `website` directory, some broken links are found:\r\n```\r\nExhaustive list of all broken links found:\r\n- Broken link on source page path = /guides/cert-manager/:\r\n   -> linking to ./ingress-nginx/ (resolved as: /guides/cert-manager/ingress-nginx/)\r\n- Broken link on source page path = /guides/ingress-nginx/:\r\n   -> linking to ./cert-manager/ (resolved as: /guides/ingress-nginx/cert-manager/)\r\n```",
        "bug": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Fix Broken Links in Website",
        "website": true
    },
    {
        "body": "When building the website by running `npm run build` in the `website` directory, the following warnings are shown:\r\n```\r\n[WARNING] {\"file\":\"assets/css/styles.cb46e6fd.css\",\"message\":\"assets/css/styles.cb46e6fd.css from Css Minimizer plugin\\nUnexpected '}' at assets/css/styles.cb46e6fd.css:25:42359.\",\"compilerPath\":\"client\"}\r\n[WARNING] {\"file\":\"assets/css/styles.cb46e6fd.css\",\"message\":\"assets/css/styles.cb46e6fd.css from Css Minimizer plugin\\nInvalid property name 'h2{text-shadow' at assets/css/styles.cb46e6fd.css:25:42314. Ignoring.\",\"compilerPath\":\"client\"}\r\n```\r\n\r\nThis is probably related to the `text-shadow` applied to `h2` elements.",
        "bug": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Fix CSS Minimizer Warnings in Website Build",
        "website": true
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThe AsciinemaPlayer got outdated and glasskube already introduced an UI.\r\n\r\n**Describe the solution you'd like**\r\nExchange the `AsciinemaPlayer` component with an YouTube embed of: https://www.youtube.com/watch?v=aIeTHGWsG2c\r\nThe youtube video should be embedded similar to we embed videos on our blog: https://glasskube.dev/blog/release-v0.1.0/\r\nAlso the Asciinema Player and dependency should removed after the change.\r\n\r\n**Additional context**\r\nThe video is already linked in the README.md\r\n",
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "html": true,
        "title": "Exchange AsciinemaPlayer demo on website with actual demo video from youtube",
        "website": true
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\n`PackageRepository` resources can be deleted, even if there are packages installed from that repository.\r\n\r\n**Describe the solution you'd like**\r\nThere should be a webhook validator in the operator, that, when a `PackageRepository` is about to be deleted, should check whether there are no packages installed from that repository. There should be a validation error, if packages from the repo are still installed. \r\n\r\n**Additional context**\r\nThere are already some webhook validations in place, e.g. for `ClusterPackage` resources. ",
        "component: package-operator": true,
        "enhancement": true,
        "go": true,
        "help wanted": true,
        "title": "Webhook Validator for `PackageRepository` deletion"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThe `glasskube version` command shows the versions of the CLI and package operator.\r\n\r\n**Describe the solution you'd like**\r\nIt would be nice if the version command also shows a nice ascii art of the text `Glasskube` at the top of the output. \r\n\r\n**Additional context**\r\nhttps://www.asciiart.eu/",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "`glasskube version` ascii art"
    },
    {
        "body": "**Describe the solution you'd like**\r\nAs Glasskube becomes more mature we can less prominent indicate that we are not yet API stable. (as we are still in the v0.x release phase).\r\n\r\n**Describe alternatives you've considered**\r\nThe scope of this ticket is to remove ` (Beta Version)` from the h3.\r\n\r\n**Additional context**\r\nAdd any other context or screenshots about the feature request here.\r\n",
        "documentation": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Remove `(Beta Version)` label from README.md"
    },
    {
        "body": "When a package has no configuration values, the `glasskube configure` command should show \"This package has no configuration values\" and quit. \r\n\r\nExample: `glasskube configure cert-manager`.",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "`glasskube configure` should show special message when there are no values to configure"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWhen the UI is opened in a small browser window, the navbar/header looks like this:\r\n\r\n![Screenshot from 2024-06-25 16-46-42](https://github.com/glasskube/glasskube/assets/7556574/b2948d33-c66e-4854-a9b8-182d597d2cf8)\r\n\r\n**Describe the solution you'd like**\r\nAll items should stay in the same row.\r\n\r\n**Describe alternatives you've considered**\r\nOn very small screens, it could even transform to a classical hamburger menu, but that would be an extra task.",
        "component: ui": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "html": true,
        "title": "Improve Navbar on small screens"
    },
    {
        "body": "### Is your feature request related to a problem? Please describe.\r\n`glasskube list` shows the list of all ClusterPackages or Packages or both. It should also be possible to list all packages with a particular `.Spec.PackageInfo.Name`.\r\n\r\n### Describe the solution you'd like\r\nWhen `glasskube list` is called with an argument, only the `Package`s with that `.Spec.PackageInfo.Name` should be listed. \r\n\r\n#### Examples\r\n\r\n```sh\r\n# shows a list of all Package resources with .Spec.PackageInfo.Name == \"quickwit\"\r\nglasskube list quickwit\r\n```\r\n```sh\r\n# shows a list of all Package resources in namespace \"foo\" with .Spec.PackageInfo.Name == \"quickwit\"\r\nglasskube list quickwit --namespace foo\r\n```\r\n```sh\r\n# shows an error message and call ExitWithError\r\nglasskube list quickwit --kind clusterpackage\r\n```\r\n\r\n#### More details\r\n- This operational mode is defined by `len(args) > 0`\r\n- This mode implies that only namespace-scoped `Package`s should be shown, no `ClusterPackage`s (like `--kind package`). \r\n- In this mode, using the `--kind` flag is an error\r\n\r\n",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "CLI: Add support for listing all packages for a package name"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nIf the value definitions of a package are different between versions, it is sometimes not possible to update safely. Particularly, if a new required value is added, it is not possible to update at all.\r\n\r\n**Describe the solution you'd like**\r\nWhen running `glasskube update` to update a package with configuration values, the user should be asked if they want to change the configuration. If they answer yes, the configuration wizard should be started.\r\n\r\n",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "CLI: Add support for changing configuration during update"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThe UI currently has a header, but when the page is too long and the user scrolls down, the header is not visible anymore.\r\n\r\n**Describe the solution you'd like**\r\nThe UI should show the header at all times (sticky header), even if the user scrolled down. \r\n\r\n**Additional context**\r\nThe bootstrap position helpers probably help: https://getbootstrap.com/docs/5.3/helpers/position",
        "component: ui": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "html": true,
        "title": "UI should have a sticky header"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nCurrently it is only possible to add and update repository via the `cli`.\r\n\r\n**Describe the solution you'd like**\r\nWhen clicking on a repository a detail page should be shown (similar to `ClusterPackages`) where a user can configure the name, url and checkbox if the repo is the default repo.\r\n\r\nAdditionally there should be button to add a new repository in the top right corner.\r\n\r\nThe scope of this ticket is to create the golang backend to receive the form request from the frontend and process it similar to how the cli processes it.\r\n\r\n**Additional context**\r\nRelated frontend issue: https://github.com/glasskube/glasskube/issues/860\r\nDesign specification: https://glasskube.dev/docs/design/repositories/\r\n",
        "component: ui": true,
        "enhancement": true,
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Repository configuration via UI backend"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nCurrently it is only possible to add and update repository via the `cli`.\r\n\r\n**Describe the solution you'd like**\r\nWhen clicking on a repository a detail page should be shown (similar to `ClusterPackages`) where a user can configure the name, url and checkbox if the repo is the default repo.\r\n\r\nAdditionally there should be button to add a new repository in the top right corner.\r\n\r\nThe scope of this ticket is to create the html forms in order to send the form request to the backend.\r\n\r\n**Additional context**\r\nRelated backend issue: https://github.com/glasskube/glasskube/issues/861\r\nDesign specification: https://glasskube.dev/docs/design/repositories/\r\n",
        "component: ui": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "html": true,
        "title": "Repository configuration via UI frontend"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nIt is not easily possible to determine if an configuration value is mandatory.\r\n\r\n**Describe the solution you'd like**\r\nIf a configuration value as marked as mandatory an asteriks should be added to the label\r\n\r\n**Describe alternatives you've considered**\r\nNone, open for suggestions\r\n\r\n**Additional context**\r\n - Bootstrap 5 related documentation: https://getbootstrap.com/docs/5.3/forms/validation/\r\n - Example solution of an asterisk: https://stackoverflow.com/questions/23141854/adding-asterisk-to-required-fields-in-bootstrap-3\r\n - related to https://github.com/glasskube/glasskube/issues/849\r\n",
        "component: ui": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Add asterisks to input label for required configuration values"
    },
    {
        "body": "**Describe the bug**\r\nHtml form validation is broken\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. open the ui `glasskube open`\r\n2. configure a package with a mandatory configuration values (e.g. `k8sgpt-operator`)\r\n3. save a package without entering a mandatory value\r\n4. See error\r\n\r\n**Expected behavior**\r\nHtml validation should work\r\n\r\n**Screenshots**\r\n![image](https://github.com/glasskube/glasskube/assets/3041752/0e592624-c600-4ad9-a644-7bd3493bc992)\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: 1.30.0\r\n - Provider: minikube\r\n\r\n**Glasskube Info (please complete the following information):**\r\n```\r\nat 14:29:49 ➜ glasskube version\r\nglasskube: v0.10.0\r\npackage-operator: v0.10.0\r\n```\r\n\r\n**Additional context**\r\n- This is a regression.\r\n- The required attribute should be added if a configuration value is marked as required",
        "bug": true,
        "component: ui": true,
        "good first issue": true,
        "regression": true,
        "title": "Native html validation seems to be broken"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThe current Glasskube documentation provides installation and upgrade instructions for MacOS using Homebrew, but Windows users do not have a package manager to facilitate the installation and upgrading of Glasskube. This makes the process cumbersome, as it requires manually downloading and reinstalling the binaries.\r\n\r\n**Describe the solution you'd like**\r\nIntegrate [Chocolatey](https://chocolatey.org/) as the package manager for Windows. This will allow users to install and upgrade Glasskube packages easily using the Chocolatey framework.\r\n\r\n**Describe alternatives you've considered**\r\nCurrently, the only alternative for Windows users is to manually download the latest Glasskube binary and perform a full reinstallation. This method is less efficient and user-friendly compared to using a package manager like Chocolatey.\r\n\r\n**Additional context**\r\nImplementing Chocolatey support will enhance the user experience for Windows users, making Glasskube more accessible and easier to maintain.",
        "component: cli": true,
        "enhancement": true,
        "needs-triage": true,
        "title": "Add Chocolatey Support for Windows Installation and Upgrade of Glasskube"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nGlasskube installation and upgrading are detailed in the documentation. However, the current MacOS installation method does not include instructions for upgrading Glasskube using Homebrew.\r\n\r\nTo upgrade Glasskube, use the following command:\r\n```\r\nbrew upgrade glasskube\r\n```\r\nAlso add the upgrading steps for Linux and Windows, which requires downloading the latest binary and reinstalling Glasskube.\r\n\r\nWe should add a section to the [Upgrading page](https://glasskube.dev/docs/getting-started/upgrading/) ) to include this Homebrew upgrade method.\r\n\r\n",
        "enhancement": true,
        "good first issue": true,
        "needs-triage": true,
        "title": "Add upgrade instruction section to the upgrading doc (for macOS, Linux and Windows)",
        "website": true
    },
    {
        "body": "**Describe the bug**\r\nDue to refactoring of in [v0.10.0](https://github.com/glasskube/glasskube/releases/tag/v0.10.0) the open command does not work any longer.\r\n\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Install kubernetes-dashboard\r\n2. open kubernetes-dashboard\r\n3. See error\r\n\r\n**Expected behavior**\r\nOpen the UI\r\n\r\n**Screenshots**\r\n![image](https://github.com/glasskube/glasskube/assets/3041752/d6bd30d9-8c27-4b9d-91be-e8cbe70519a7)\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: 1.30.0\r\n - Provider: minikube\r\n\r\n**Glasskube Info (please complete the following information):**\r\n```\r\nat 14:29:49 ➜ glasskube version\r\nglasskube: v0.10.0\r\npackage-operator: v0.10.0\r\n```\r\n\r\n\r\n**Additional context**\r\nservice got the name `kubernetes-dashboard-kubernetes-dashboard` instead of `kubernetes-dashboard`. So either port-forwarding or service name should be adjusted.",
        "bug": true,
        "component: cli": true,
        "component: client": true,
        "go": true,
        "regression": true,
        "title": "Could not open `package` via UI and cli"
    },
    {
        "body": "**Describe the bug**\r\nAt random times, the watches of the UI server to the API server are \"stuck\", i.e. no events are received anymore, but there is no error or anything indicating so. As a consequence the UI does not react anymore to any cluster updates. \r\n\r\n**To Reproduce**\r\nNo actual reproduction scenario found yet. Sometimes happens after 1 minute, sometimes after 4 hours. \r\n\r\n**Expected behavior**\r\nWhen watches are lost, they have to be reconnected, and if that fails or is not possible, the user needs to be notified somehow about the error. \r\n\r\n**Screenshots**\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: 1.28, 1.29, 1.30\r\n - Provider: minikube, OVH\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: all recent versions\r\n - CLI version: all recent versions\r\n\r\n**Additional context**\r\nRelated: https://github.com/glasskube/glasskube/issues/768, https://github.com/glasskube/glasskube/issues/756\r\n",
        "bug": true,
        "component: client": true,
        "title": "Server out of sync with Kubernetes API server"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nCurrently the `glasskube serve` command only logs if a user installs a package. So only following the logs it seems that the installation will not be finished.\r\n\r\n**Describe the solution you'd like**\r\nAll (or most) status changes should be logged to `Stderr`. This can be noisy as this also might help us to reproduce and fix bugs if users can copy past us the ui logs. \r\n\r\n**Additional context**\r\nThis also might help investigating the \"out-of-sync\" task (#838).\r\n",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "title": "Extend logging that happens during `serve` command"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThe `longDescription` of a package manifest can contain links in markdown format. A markdown link is correctly rendered as an html anchor element, but it opens in the same tab the user is currently in.\r\n\r\n**Describe the solution you'd like**\r\nLinks in the `longDescription` should be rendered to have the `target=\"_blank\"` attribute too, to make it open in a new tab.\r\n\r\n**Describe alternatives you've considered**\r\n\r\n**Additional context**\r\nThis description is converted from markdown to HTML on the `package.html` template, using the `| Markdown` pipe. The corresponding function `Markdown` is registered in the `templates.go` file. There, the rendering happens – probably here something has to be done. \r\n",
        "component: ui": true,
        "enhancement": true,
        "help wanted": true,
        "title": "Links in package description should open in new tab"
    },
    {
        "body": "Hi.\r\n\r\n**Is your feature request related to a problem? Please describe.**\r\n\r\nOn some installations of quickwit, the metastoreUri isn't the same value as the default index uri (which is an object storage bucket). So we should have two separate fields even if it's the same value sometimes.\r\n\r\nIt'll help the quickwit users to understand the mapping with the helmchart better and also be able to add an external postgreSQL in their cluster to tune the quickwit performances later.\r\n\r\n**Describe the solution you'd like**\r\n\r\nTwo separate fields `metastoreUri` and `s3Uri`\r\n\r\nThanks in advance\r\n",
        "packages": true,
        "title": "Quickwit package: separation of metastoreUri and defaultIndexUri"
    },
    {
        "body": "**Describe the bug**\r\nI was working on #764 . When running the package operator on mac air m2 its returning with an error saying `problem running manager\t{\"error\": \"open /var/folders/gs/6x7sqthj2wscyhddhzzdtwdw0000gn/T/k8s-webhook-server/serving-certs/tls.crt: no such file or directory\"}`. However, when I did the same thing in my ubuntu it worked. After going through the logs I found out that when running the `make setup` command its saving the certificates in the `/tmp/k8s-webhook-server/serving-certs` . but when using the `make run` command its checking for the certs in ` /var/folders/gs/6x7sqthj2wscyhddhzzdtwdw0000gn/T/k8s-webhook-server/serving-certs/tls.crt` and there is no directory called `k8s-webhook-server` in the `T` folder.\r\n\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. You should have a mac(m2)\r\n2. Follow [this](https://github.com/glasskube/glasskube/blob/main/CONTRIBUTING.md#custom-package-repository) instruction .\r\n\r\n\r\n**Expected behavior**\r\nThe operator should run successfully.\r\n\r\n**Screenshots**\r\n<img width=\"1710\" alt=\"Screenshot 2024-06-15 at 9 55 25 AM\" src=\"https://github.com/glasskube/glasskube/assets/123734227/5acc02aa-50c4-4c8d-a60c-3fee8b1d8fb2\">\r\n<img width=\"1710\" alt=\"Screenshot 2024-06-15 at 9 57 55 AM\" src=\"https://github.com/glasskube/glasskube/assets/123734227/61039ab4-37a6-4ef5-80c8-f7d6f3768795\">\r\n<img width=\"1710\" alt=\"Screenshot 2024-06-15 at 9 59 39 AM\" src=\"https://github.com/glasskube/glasskube/assets/123734227/13deff04-0858-4c1c-ad42-ca45ba09b8a2\">\r\n\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type:  Kubernetes\r\n - Version: 1.30\r\n - Provider: minikube\r\n\r\n\r\n",
        "bug": true,
        "needs-triage": true,
        "title": "When trying to run the package operator on mac air m2 by the `make run` command getting error saying can't find `tls.crt` - no such file or directory."
    },
    {
        "body": "**Describe the bug**\r\n[Documentation](https://glasskube.dev/docs/design/repositories/#repository-management) states that if you use --default with the `repo add` command it should return an error if there's a repository with that annotation already.\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Try to add a new repository with `glasskube repo add test https://example.com --default`\r\n2. List repositories with `glasskube repo list`\r\n3. Check that there are two default repositories\r\n\r\n**Expected behavior**\r\nEither we should get an error, or instead the current default repo will get the default annotation removed and the new repository being added will be the new default repo\r\n\r\n**Screenshots**\r\n\r\n![image](https://github.com/glasskube/glasskube/assets/30386061/c44c7386-bdba-4293-9042-94f2e7a9ab8a)\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: 1.30.0\r\n - Provider: minikube\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: v0.0.1\r\n - CLI version: dev\r\n",
        "bug": true,
        "component: cli": true,
        "go": true,
        "help wanted": true,
        "title": "`repo add` command with --default flag should return an error if there's a repository with that annotation already"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nDuring quickwit integration, we noticed there might be a general need for dynamic default value configurations, i.e. configurations that are dependent on the package, but the user should not be able to change them. \r\n\r\nFor example: https://github.com/glasskube/packages/pull/139/files#diff-dfb7a579fd55c8c027910c1cd40500fad2952f96e57b58c0a634cce8d0fcc1d4R37 – here the name of the secret should include the package name, such that when multiple quickwits are installed in a namespace, each has its unique secret name. \r\n\r\n**Describe the solution you'd like**\r\nThere should be a new type of value configurations (name suggestions: `HIDDEN`, `STATIC`, `DEFAULT`), which are not shown on the CLI or the UI. Instead only the operator takes care of these. \r\n\r\nThe problem described above could then be solved with the following addition to the manifest:\r\n\r\n```\r\nvalueDefinitions:\r\n  tlsSecretName:\r\n    type: HIDDEN / STATIC / DEFAULT\r\n    targets:\r\n      - chartName: quickwit\r\n        patch:\r\n          op: add\r\n          path: /ingress/tls\r\n          valueTemplate: quickwit-tls-secret-{{ GetPackageName }}\r\n```\r\n\r\nwhere `GetPackageName` would be a newly added function that returns the package name of the evaluated package. \r\n\r\n**Describe alternatives you've considered**\r\n* Provide a mechanism to template parts of the `helm.values` part of the package manifest – more likely to add confusion for package maintainers\r\n* specifically for this case: add another `patch` to the `quickwitDomain` value – still need the `GetPackageName` function, and it would not be solved in general but only for this package.\r\n\r\n**Additional context**\r\n#803 \r\n",
        "component: cli": true,
        "component: client": true,
        "component: package-operator": true,
        "component: ui": true,
        "enhancement": true,
        "title": "Support hidden default value definitions in manifest"
    },
    {
        "body": "In the current state, Glasskube packages can only be installed once per cluster. In some situations, this is an unnecessary restriction and limits some use-cases. \r\n\r\nIt should be possible for the author of a package to specify a \"scope\", which can either be \"Cluster\" or \"Namespaced\" (default \"Cluster\"). Depending on a packages scope, the Glasskube system should create either a cluster or namespace scoped custom resource. The name of the cluster-scoped CRD is `ClusterPackage`, the name for the namespace-scoped CRD is `Package`. This is a breaking change, because we currently use the `Package` CRD name for the cluster-scoped resources, but we settled on this to stay consistent with common Kubernetes nomenclature (e.g. `Role`/`ClusterRole`). Existing installations can not be migrated automatically.\r\n\r\n### Tasklist\r\n- [x] Refactor the codebase to support `ClusterPackage` and `Package`\r\n- [x] Refactor to use finalizers instead of owner references\r\n- [x] Update the dependency manager to allow `Package` validation\r\n- [x] Update `install` command to allow creating `Package` (#851)\r\n- [x] Update `update` command to allow updating `Package`\r\n- [x] Update `configure` command to allow updating `Package`\r\n- [x] Update `describe` command to show status of all `Package` instances\r\n- [x] Update `list` command to show all `Package` instances (#817)\r\n- [x] Update `open` command to support `Package`\r\n- [x] Update `uninstall` command to allow deleting `Package` (#857)\r\n- [x] Update `autoupdate` commands to handle `Package` (#834, #855)\r\n- [x] Add Apps list page (#817)\r\n- [x] Add Apps detail page (#817)\r\n\r\n### Limitations\r\n* For now, dependencies must always be Cluster scoped, even for namespace scoped packages",
        "epic": true,
        "title": "Namespace-scoped packages"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWe just redesigned our front page of [glasskube.dev](https://glasskube.dev/) and publish [blog posts](https://glasskube.dev/blog/) regularly, but the latest posts are not visible on the website.\r\n\r\n**Describe the solution you'd like**\r\nAdd a recent blog post section to the front-page, similar to the [cyclops](https://cyclops-ui.com/) website:\r\n\r\n![image](https://github.com/glasskube/glasskube/assets/3041752/5dc2ad51-e0d3-4a76-8e31-5ea9815e668e)\r\n\r\n\r\n**Additional context**\r\nThe blog posts should be fetched dynamically.\r\n",
        "enhancement": true,
        "help wanted": true,
        "title": "Add recent blog posts section to website front page",
        "typescript": true,
        "website": true
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThere is currently no link in the Glasskube UI to our Discord server.\r\n\r\n**Describe the solution you'd like**\r\nA good place for the Discord link would be in the footer below \"Glasskube Cloud\"\r\n\r\nIt should be called \"Glasskube Discord\" with following link: `https://discord.gg/SxH6KUCGH7`\r\n\r\n",
        "component: ui": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Add Discord link to Glasskube UI footer"
    },
    {
        "body": "**Describe the bug**\r\nOpen the UI in 10 tabs, the UI becomes completely unresponsive. \r\n\r\n**To Reproduce**\r\n\r\n**Expected behavior**\r\nUI works. \r\n\r\n**Screenshots**\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: 1.30\r\n - Provider: minikube\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: dev\r\n - CLI version: dev\r\n \r\n**Additional context**\r\n\r\n",
        "bug": true,
        "title": "UI breaks when several tabs are opened"
    },
    {
        "body": "**Describe the bug**\r\nA javascript error is logged:\r\n\r\n> The selector \"#pkg-install-repository\" on hx-include returned no matches!\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Only configure one repository\r\n2. Open UI\r\n3. Go to package detail page\r\n4. Switch version you want to install\r\n5. See error in console\r\n\r\n**Expected behavior**\r\nNo error should be thrown\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: 1.30\r\n - Provider: minikube\r\n\r\n**Glasskube Info (please complete the following information):**\r\nglasskube: v0.8.0\r\npackage-operator: v0.8.0\r\n\r\n\r\n**Additional context**\r\nAlso no pages can be loaded afterwards and the ui is stuck\r\n",
        "bug": true,
        "needs-triage": true,
        "title": "Switching version before install throws javascript error if only one repository is present"
    },
    {
        "body": "**Describe the bug**\r\n[pull request template](https://github.com/glasskube/glasskube/blob/main/.github/pull_request_template.md) URL in [the contribution guid](https://github.com/glasskube/glasskube/blob/main/CONTRIBUTING.md) is returning a 404 Not Found error and needs to be updated.\r\n\r\n**To Reproduce**\r\nURL [pull request template](https://github.com/glasskube/glasskube/blob/main/.github/pull_request_template.md) is `404 Not Found error`.\r\n\r\n**Expected behavior**\r\nFix URL https://github.com/glasskube/glasskube/blob/main/.github/PULL_REQUEST_TEMPLATE.md\r\n\r\n",
        "bug": true,
        "documentation": true,
        "title": "pull request template URL returns 404Not Found"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\nGlasskube used to support automatic updates on the operator side, but this feature has since been removed and we don't currently have an alternative, even though the CLI and UI can set the relevant annotation.\n\n**Describe the solution you'd like**\nThere should be a new CLI command that runs the auto updates. This command should be as simple as possible and never require user interaction, because it should be designed to be integrated into automated workflows.\n\nIt should also be easier to enable/disable automatic updates. This should be provided via separate CLI commands.\n\n**Describe alternatives you've considered**\nAlternatively, we could build a separate tool for this use-case but since we already have a lot of the logic in the Glasskube CLI I think it's a better fit.\n\n**Additional context**\n\nExamples:\n\n```sh\n# run the auto updater\nglasskube auto-update\n# enable auto updates for specific packages\nglasskube auto-update enable foo bar\n# enable auto updates for all packages\nglasskube auto-update enable --all\n# disable auto updates for all packages\nglasskube auto-update disble --all\n```",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "title": "Add a CLI Command to Run Automatic Updates for Packges Where Enabled"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nTurning off some logging shows that we open the browser and show the \"ready message\" (\"UI is available ...\") a bit too early: \r\n\r\n```\r\nI0606 15:14:07.129073  279189 cert_rotation.go:137] Starting client certificate rotation controller\r\nI0606 15:14:07.135934  279189 reflector.go:296] Starting reflector *v1alpha1.Package (0s) from pkg/mod/k8s.io/client-go@v0.30.1/tools/cache/reflector.go:232\r\nI0606 15:14:07.135937  279189 reflector.go:296] Starting reflector *v1alpha1.PackageInfo (0s) from pkg/mod/k8s.io/client-go@v0.30.1/tools/cache/reflector.go:232\r\n...\r\nglasskube UI is available at http://localhost:8580\r\nI0606 15:14:07.137386  279189 reflector.go:359] Caches populated for *v1.Namespace from pkg/mod/k8s.io/client-go@v0.30.1/tools/cache/reflector.go:232\r\nI0606 15:14:07.137814  279189 reflector.go:359] Caches populated for *v1alpha1.PackageInfo from pkg/mod/k8s.io/client-go@v0.30.1/tools/cache/reflector.go:232\r\nI0606 15:14:07.137825  279189 reflector.go:359] Caches populated for *v1alpha1.Package from pkg/mod/k8s.io/client-go@v0.30.1/tools/cache/reflector.go:232\r\n...\r\n```\r\n\r\nWhen the connection to the cluster is slow, this could lead to an \"empty\" (i.e. nothing installed, even though packages are installed) package overview page on the initial load – happened to me once in my OVH cluster. It was corrected after page reload, so I suspect this timing issue was the cause of that. \r\n\r\n**Describe the solution you'd like**\r\nIt should be investigated whether we can actually hook into the store/controller of `client-go` (or maybe we can somehow use our `initPackageStoreAndController` functions?), or not at all – if not, I guess the issue can be neglected.\r\nIf it's possible, we could \r\n* send an update event to the client once caches are populated, then it will rerender anyway,\r\n* show a warning on the UI: \"server is initializing\" or something like that,\r\n* or not open the browser until caches are populated (but of course one can still always open the page in the browser by themselves), \r\n* or both. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n**Additional context**\r\n",
        "component: ui": true,
        "enhancement": true,
        "needs-triage": true,
        "title": "Wait for server caches to be populated"
    },
    {
        "body": "Some use-cases require running tasks using the Glasskube CLI from within the cluster. To enable those workflows, we need to publish docker images for the Glasskube CLI.",
        "distribution": true,
        "title": "Add Creation of Docker Images for Glasskube CLI During Release"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nJSON/YAML output to `glasskube describe` has been added in #717. The field `autoUpdate` is a string \"Enabled\" or \"Disabled\", but it should actually be a boolean true/false instead.\r\n\r\n**Describe the solution you'd like**\r\n`autoUpdate` should be a boolean.\r\n\r\n**Describe alternatives you've considered**\r\n\r\n**Additional context**\r\nhttps://github.com/glasskube/glasskube/pull/717#discussion_r1629411787\r\n",
        "component: cli": true,
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "`autoUpdate` output in `glasskube describe --output=[yaml|json]` should be a boolean"
    },
    {
        "body": "**Package Information**\r\n - Name: gateway-api\r\n - Source Code: [if available]\r\n - Website: [https://gateway-api.sigs.k8s.io/](https://gateway-api.sigs.k8s.io/)\r\n\r\n**Why we should add this package to our registry**\r\n\r\n\r\n**If you are an author of this project, let us know**\r\n - [ ] I am an author of this project\r\n\r\n**Additional information**\r\n\r\n[https://gateway-api.sigs.k8s.io/guides/#install-standard-channel](https://gateway-api.sigs.k8s.io/guides/#install-standard-channel)",
        "packages": true,
        "title": "Gateway API"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWhen turning on logging, I noticed that we already have some client-side throttling again because of requests to the `PackageRepository` resources:\r\n\r\n```\r\nInstalling kubernetes-dashboard...\r\nI0606 13:42:59.093760  206148 request.go:629] Waited for 180.502406ms due to client-side throttling, not priority and fairness, request: GET:https://192.168.58.2:8443/apis/packages.glasskube.dev/v1alpha1/packagerepositories/glasskube\r\nI0606 13:42:59.293507  206148 request.go:629] Waited for 359.303205ms due to client-side throttling, not priority and fairness, request: GET:https://192.168.58.2:8443/apis/packages.glasskube.dev/v1alpha1/packagerepositories\r\nI0606 13:42:59.493378  206148 request.go:629] Waited for 392.101617ms due to client-side throttling, not priority and fairness, request: GET:https://192.168.58.2:8443/apis/packages.glasskube.dev/v1alpha1/packagerepositories\r\nI0606 13:42:59.693269  206148 request.go:629] Waited for 397.435373ms due to client-side throttling, not priority and fairness, request: GET:https://192.168.58.2:8443/apis/packages.glasskube.dev/v1alpha1/packagerepositories/glasskube\r\nI0606 13:42:59.893667  206148 request.go:629] Waited for 397.891212ms due to client-side throttling, not priority and fairness, request: GET:https://192.168.58.2:8443/apis/packages.glasskube.dev/v1alpha1/packagerepositories/glasskube\r\n```\r\n\r\n**Describe the solution you'd like**\r\n* Investigate whether it is reasonable that so so many requests are being made (probably yes)\r\n* Implement the same kind of cache as we have for `Package` and `PackageInfo` resources\r\n\r\n**Describe alternatives you've considered**\r\n\r\n**Additional context**\r\n",
        "component: cli": true,
        "component: client": true,
        "enhancement": true,
        "title": "Cache `PackageRepository` custom resources"
    },
    {
        "body": "The `uninstall` command was the first one to have such a feature, but we settled on the name `--yes` for all other commands. For better consistency, the `uninstall` command should also use `--yes` for this flag. ",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Change flag name of `--force` to `--yes` for  `glasskube uninstall`"
    },
    {
        "body": "The default cache time of the repo cache is 5 minutes and is hardcoded. We should discuss strategies for local development and testing where one might want to disable the cache, or reduce the time, or clear it manually with a button click / command. ",
        "component: cli": true,
        "component: package-operator": true,
        "component: repo": true,
        "enhancement": true,
        "go": true,
        "title": "Possibility to set cache time or to clear caches manually"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nOn the UI, when opening the package detail page of a package, which does not have a corresponding discussion (https://github.com/glasskube/glasskube/discussions/categories/packages) yet, an error will be logged to the console: \"failed to get discussion counts from giscus: wrong status code: 404 Not Found\". \r\n\r\nHowever, this is a legit case and should not be logged, as this could confuse the user. \r\n\r\n**Describe the solution you'd like**\r\nThe giscus API is called here: `internal/web/discussions.go:discussionBadge` – this is the endpoint to load the number of reactions on the package detail page. When calling `giscus.Client().GetCountsFor(pkgName)`, the returned error should be checked whether it is a NOT_FOUND error (404) or not. If it is, then the error should not be logged.\r\n\r\n**Describe alternatives you've considered**\r\n\r\n**Additional context**\r\n",
        "enhancement": true,
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Suppress 404 error for packages without a giscus discussion"
    },
    {
        "body": "Squash merging provides several benefits over rebasing:\r\n- always a single changelog entry for a PR\r\n- no need for contributors to continuously rebase their branch and fiddle with commit message format\r\n- more control over commit message in `main` branch (and thus changelog entries) for the core team\r\n\r\nIn order to adopt this workflow, the following changes must be made:\r\n- [ ] Disable all merge options other than \"Squash & Merge\" in the repository settings (must be performed by a repository admin)\r\n- [ ] Add a PR check that verifies that the title conforms to the spec. There are two options for this, an app and a workflow action:\r\n      - https://github.com/Ezard/semantic-prs (used by renovate)\r\n      - https://github.com/amannn/action-semantic-pull-request\r\n- [ ] Remove the commitlint workflow\r\n",
        "title": "PR Workflow Update: Migrate from Rebase-Merge to Squash-Merge"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThe `glasskube serve` command always opens a new browser tab. In cases where the command is often stopped and restarted (like development), this can be annoying. \r\n\r\n**Describe the solution you'd like**\r\nThe command should have a flag `--skip-open` (shorthand: `-s`). When it is set, the page should not be opened in the browser. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n**Additional context**\r\n",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "`--skip-open` flag for `glasskube serve` command"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nOn the UI, the settings page shows a green or red circle next to each repository, indicating whether it has status \"Ready\" or not. \r\n\r\n**Describe the solution you'd like**\r\nThere should be an additional text when hovering with the mouse over this circle. The html `title` attribute should be used. The two possible texts are \"Ready\" and \"Not Ready\".\r\n\r\n**Describe alternatives you've considered**\r\n\r\n**Additional context**\r\n",
        "component: ui": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Show repository status on settings page"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\n`glasskube ls` always shows the packages of all configured repositories, but there should be a way to look at packages of one specific repository.\r\n\r\n**Describe the solution you'd like**\r\n`glasskube ls` should have a flag `--repository`, which can be used this way: `glasskube ls --repository [repoName]`. Only the packages defined in the given repo will then be listed. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n**Additional context**\r\n",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "`--repository` flag for `glasskube list` command"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nCurrently the `glasskube bootstrap` command shows a prompt like \"Glasskube will be installed in context xyz. Continue?\" (see #719). While this is correct for non-bootstrapped clusters, it makes no sense when the user wants to update the current glasskube installation and might be confusing. \r\n\r\n**Describe the solution you'd like**\r\nWhen glasskube is bootstrapped in the current cluster, the prompt should be: \"Glasskube will be updated to version [version] in cluster [cluster]. Continue?\" \r\n\r\nAs in #719, if the `--yes` flag is set, the prompt should not appear. \r\n\r\nThere is already a check in place, whether the installation would be downgraded. This check should be done first. If the installation would not be downgraded, then the prompt for installing/updating should appear, because only at this point we know if glasskube is already installed and in which version. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\n\r\n",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "`glasskube bootstrap` should show different prompt when updating"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThe description of a package value can be a longer text so having support for some formatting, like emphasis, links and so on would be beneficial for package authors.\r\n\r\n**Describe the solution you'd like**\r\nWe already support markdown in the package long description, so it would be consistent to use the same markup language.\r\n\r\n**Additional context**\r\n\r\nRelevant template file: `internal/web/templates/components/pkg-config-input.html`\r\n\r\nThe description should be passed through the `Markdown` function.\r\n\r\n",
        "component: ui": true,
        "enhancement": true,
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Add markdown support in package value description"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nCurrently it is not possible to determine via the ui, if a repository is configured as default repository:\r\n\r\n![image](https://github.com/glasskube/glasskube/assets/3041752/151388de-c4b4-4b42-ba7d-8aa22061780c)\r\n\r\n\r\n**Describe the solution you'd like**\r\nAdd an indication to the UI that a repository is configured as default repository.\r\n\r\n**Describe alternatives you've considered**\r\nCurrently it is necessary to describe the custom resource.\r\n\r\n\r\n**Additional context**\r\nWhether a given `PackageRepository` is marked as the default repository can be determined by checking  [`IsDefaultRepository()`](https://pkg.go.dev/github.com/glasskube/glasskube/api/v1alpha1#PackageRepository.IsDefaultRepository).\r\n",
        "component: ui": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Indicate default repository via UI"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nCurrently it is not possible to determine via the cli, if a repository is configured as default repository:\r\n\r\n```\r\n➜ glasskube repo list\r\nNAME       URL                                         AUTHENTICATION  STATUS  MESSAGE\r\nglasskube  https://packages.dl.glasskube.dev/packages  None            Ready   repo has 12 packages  \r\nlocal      http://host.minikube.internal:8088          None            Ready   repo has 12 packages\r\n``` \r\n\r\n**Describe the solution you'd like**\r\nAdd a default column so it is possible to see if a repo is configured as default repo.\r\n\r\n**Describe alternatives you've considered**\r\nCurrently it is necessary to describe the custom resource.\r\n\r\n**Additional context**\r\nWhether a given `PackageRepository` is marked as the default repository can be determined by checking  [`IsDefaultRepository()`](https://pkg.go.dev/github.com/glasskube/glasskube/api/v1alpha1#PackageRepository.IsDefaultRepository).",
        "component: cli": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Add `default` column to `glasskube repo list` command"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWe rerender the whole package detail page at any package update. If a user is working in the package configuration and changes a few values without having saved yet, and package update is coming in, the page is being rerendered and the changes are lost. \r\n\r\n**Describe the solution you'd like**\r\nThe config form should not be reset when only the status changes. It is probably fine to still reset it in these cases:\r\n* package has been installed or uninstalled\r\n* package configuration has changed elsewhere\r\n* package version/repository has changed\r\n\r\nOld and new package are both known at the time of the update, so the config should be comparable. Since the package detail page is quite bloated already anyway, it might make sense to somehow split it into separate components/endpoints, which would have the benefit that separate components can be reloaded instead of the whole page. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\n\r\n",
        "component: ui": true,
        "title": "Package Config Form should not be reset when only package status updates"
    },
    {
        "body": "",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "help wanted": true,
        "title": "Add `--dry-run` support for `glasskube bootstrap`"
    },
    {
        "body": "",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "help wanted": true,
        "title": "Add `--output` support for `glasskube bootstrap`"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThe bootstrap command starts it's work right away, which can be dangerous if a user has the wrong kubeconfig context selected.\r\n\r\n**Describe the solution you'd like**\r\nBefore doing anything, `bootstrap` should ask the user for confirmation, the prompt should include the current context name. For example:\r\n\r\n    Glasskube will be installed in context [name-of-current-context].\r\n    Continue? (Y/n)\r\n\r\nThere should also be a `--yes` flag, that skips this step.\r\n\r\nIf the bootstrap process is triggered via the UI, the confirmation prompt MUST NOT be shown!\r\n",
        "component: cli": true,
        "enhancement": true,
        "help wanted": true,
        "title": "Add confirmation to `bootstrap` command"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nAuto-updates can only be enabled/disabled at the time of installation, but not afterwards. \r\n\r\n**Describe the solution you'd like**\r\nOn the package detail page, there should be a switch to turn on/off auto-updates. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\nFollow-Up of #716\r\n",
        "component: ui": true,
        "enhancement": true,
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Enable/disable auto-updates for installed packages in UI"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\nAs user I want to change the version of an installed package (and even install the package from a different repository)\n\n**Describe the solution you'd like**\nIntroduce a new repository dropdown for not yet installed and already installed packages and add a version select to already installed packages, which changes the package version.\nI also want to be able to change the auto upgrade checkbox for already installed packages.\n\n**Describe alternatives you've considered**\nIt is already possible to install / configure specific versions from the cli (`glasskube install keptn --version=v2.0.0-rc.1+1`)\n\n**Additional context**\nI already created a mockup of the app detail page:\n\n![Glasskube package version and repo switch](https://uploads.linear.app/df577539-a424-4cdd-a9e7-429a979eefe9/909db2df-a19b-47a7-929f-5b9b31d7fd74/5ebc4cc9-514b-4793-bb9b-6ff0bcd5e914?signature=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJwYXRoIjoiL2RmNTc3NTM5LWE0MjQtNGNkZC1hOWU3LTQyOWE5NzllZWZlOS85MDlkYjJkZi1hMTliLTQ3YTctOTI5Zi01YjliMzFkN2ZkNzQvNWViYzRjYzktNTE0Yi00NzkzLWJiOWItNmZmMGJjZDVlOTE0IiwiaWF0IjoxNzE3MTQ4MjgxLCJleHAiOjMzMjg3NzA4MjgxfQ.AbfeL2tRVRgRJUPATJ4T_nmHrf9Lcf8uvmZy8SqpHGg)",
        "component: client": true,
        "component: ui": true,
        "enhancement": true,
        "title": "Implement specific (multi repository) package upgrades / downgrades"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nAt the moment there is no guide/instruction/way to remove glasskube from a cluster\r\n\r\n**Describe the solution you'd like**\r\nglasskube bootstrap uninstall or similar\r\n\r\n**Describe alternatives you've considered**\r\nWorst case a list of manifests etc to uninstall in a readme etc\r\n\r\n",
        "component: cli": true,
        "enhancement": true,
        "help wanted": true,
        "title": "Add `purge` command to remove Glasskube from a cluster"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nAs we introduced autoated tests in our ci enviornment (e.g. https://github.com/glasskube/packages/actions/runs/9266452356/job/25492645517) our progress spinners are quite noise (printing 10 lines every second)\r\n\r\n**Describe the solution you'd like**\r\nGlobally introduce a `--no-progress` cli flag that prevents progress logging to the cli.\r\n\r\n**Additional context**\r\nThis will also be used in our automated testing infrastrucutre.\r\n",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Add `--no-progress` cli flag"
    },
    {
        "body": "**Describe the bug**\r\nDiscussion page is broken for packages that do not appear in the public glasskube repo.\r\n\r\n**Expected behavior**\r\nThe discussion page should be disabled and not linked to for such packages. ",
        "bug": true,
        "component: ui": true,
        "needs-triage": true,
        "title": "Discussion page is broken in multi repo environment"
    },
    {
        "body": "**Describe the bug**\r\nWhen using multiple repositories the ui is not able to determin the correct repository to fetch the `versions.yaml` file from.\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Add a second repository\r\n2. Add a package in the second repository that does not exist in the first one\r\n3. start the ui\r\n4. try to go to the detail page\r\n\r\n**Expected behavior**\r\nSee the package details of the package from the correct package repository\r\n\r\n**Screenshots**\r\n![image](https://github.com/glasskube/glasskube/assets/3041752/a5c9942b-b219-4b1a-92d7-9fef5fe0047d)\r\n\r\n![image](https://github.com/glasskube/glasskube/assets/3041752/d990ddab-5c26-441d-b3ee-1df52808e67b)\r\n\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: minikube v1.32.0\r\n - Version: 1.28.3\r\n\r\n**Glasskube Info (please complete the following information):**\r\n> glasskube version\r\nglasskube: v0.5.1\r\npackage-operator: v0.5.1\r\n\r\n\r\n**Additional context**\r\n - Installing the package via the cli works\r\n - If only one repository exists the problem does not occur\r\n",
        "bug": true,
        "component: ui": true,
        "title": "An error occurred fetching package index of [package] in repository"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nOne can configure cycles in a package configuration, leading to endless loops and crashes of both the client and the operator.\r\n\r\nExample A:\r\nPackage `P` has a value configuration for value `x`, that is simply a reference to package `P`'s value `x` (i.e. a reference to itself). Referring from a package to itself could be a real use case, when someone wants to re-use a value (for example a domain) and only define it once. Actually referring to the exact same value is not useful, but could still happen by accident, and the crash would lead to the user having to manually resolve it in the CRD.\r\n\r\nExample B:\r\nPackage `P` has a value configuration for value `x`, that is a reference to the value configuration `y` of another package `Q`. Somebody could (accidentally or not) set `Q`'s value `y` to be a reference to `P`'s `x`. This would also result in a cycle and an endless loop.\r\n\r\n**Describe the solution you'd like**\r\nThere should be some sort of validation, which makes it impossible to store such faulty configuration in the first place. The self-references could be catched easier (simply check if the reference package is \"itself\", and if so, check whether it's actually the same name). However, this doesn't prevent cycles. For cycles, during resolving we need to store the path we are walking along, and then check if we come to a point we have been before. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\n",
        "component: client": true,
        "component: package-operator": true,
        "enhancement": true,
        "needs-triage": true,
        "title": "Validate cycles in configuration references"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nCurrently, there is no way to update a `PackageRepository` custom resource via our CLI.\r\n\r\n**Describe the solution you'd like**\r\nThere should be a `repo`-subcommand `delete`, which can be used like this:\r\n\r\n`glasskube repo update [repositoryName]`\r\n\r\nIt should support the same flags as the `repo add` command, and additionally the `--url` flag to make changing the url possible. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\nRef #195 \r\n",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "help wanted": true,
        "title": "Support repo updates with `glasskube repo update [repoName]`"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nCurrently, there is no way to delete a `PackageRepository` custom resource via our CLI, one would have to delete the resource manually instead.\r\n\r\n**Describe the solution you'd like**\r\nThere should be a `repo`-subcommand `delete`, which can be used like this:\r\n\r\n`glasskube repo delete [repositoryName]`\r\n\r\nThe command should verify whether no packages are currently installed from this repository. If there are packages installed from the repo, the deletion should be aborted with this error message: \"Repository [repoName] cannot be deleted, because the following packages are installed from this repository: [list of package names]\". \r\n\r\nBefore deleting, the user should be asked to confirm deleting the repository, by using the existing Yes/No prompt, where `No` should be the default. The prompt should be: \"[repoName] will be removed from your current cluster ([current-context]). Continue? (y/N)\"\r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\nRef #195 \r\n",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "help wanted": true,
        "title": "Support repo deletion with `glasskube repo delete [repoName]`"
    },
    {
        "body": "See #629 for details.\r\n\r\nThe `--dry-run` flag can be used by users, who want to simulate configuring a package, but don't actually want to configure it.",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "title": "Add `--dry-run` support for `glasskube configure`"
    },
    {
        "body": "See #629 for details.\r\n\r\nThe `--dry-run` flag can be used by users, who want to simulate updating a package, but don't actually want to update it.",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "title": "Add `--dry-run` support for `glasskube update`"
    },
    {
        "body": "See #629 for details.\r\n\r\nThe `--dry-run` flag can be used by users, who want to simulate installing a package, but don't actually want to install it. ",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "help wanted": true,
        "title": "Add `--dry-run` support for `glasskube install`"
    },
    {
        "body": "See #629 for details.\r\n\r\nSince `configure` modifies a resource, the output of the command should be the configured package.",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "help wanted": true,
        "needs-triage": true,
        "title": "Add `--output` support for `glasskube configure`"
    },
    {
        "body": "See #629 for details.\r\n\r\nSince `update` modifies a resource, the output of the command should be the updated package.\r\n",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "help wanted": true,
        "title": "Add `--output` support for `glasskube update`"
    },
    {
        "body": "See #629 for details.\r\n\r\nSince `install` modifies a resource, the output of the command should be the created package. ",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "help wanted": true,
        "title": "Add `--output` support for `glasskube install`"
    },
    {
        "body": "See #629 for details. ",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "help wanted": true,
        "title": "Add `--output` support for `glasskube describe`"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nAs a follow up of #456 we should also show \"uninstalling\" in the CLI, i.e. `list` and `describe` commands, in order to keep CLI and UI consistent. \r\n\r\n**Describe the solution you'd like**\r\nAs defined in #456, when a package is in the progress of being uninstalled, its status should be \"Uninstalling\" instead of \"Pending\". \r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\n#456\r\n",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Show uninstalling state in `list` and `describe` command"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWe use the `packages.glasskube.dev/auto-update` label to decide whether a package should be updated automatically or not. However, labels are used to attach identifying information to a custom resource, see https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/. Non-identifying information should be attached by using annotations: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/ \r\n\r\n**Describe the solution you'd like**\r\nWherever the auto-update label is being used in the code base, it should be changed to use an annotation instead. \r\n\r\n**Additional context**\r\nThis came up here: https://github.com/glasskube/glasskube/pull/618#discussion_r1598377945\r\n",
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Auto-Update label should be an annotation"
    },
    {
        "body": "All CLI commands should support specifying an output format if applicable. This can be done using the `--output` flag (short: `-o`). This flag is optional (default: empty) and can be set to \"json\" or \"yaml\". Output should be written to STDOUT.\r\n\r\nIf a command modifies some resources, the output should be of the resource after modification. \r\nThose commands should also provide a `--dry-run` option. \r\n\r\n### Examples\r\n```\r\n# list packages as yaml\r\nglasskube ls -o yaml\r\n# simulate install and write json output to a file\r\nglasskube install foo-pkg --dry-run --output=json > foo.json\r\n```\r\n\r\n### Subtasks\r\n- [x] https://github.com/glasskube/glasskube/issues/465\r\n- [x] #655 \r\n- [x] #656\r\n- [x] #659\r\n- [x] #657\r\n- [x] #660\r\n- [x] #658\r\n- [x] #661\r\n- [x] #724\r\n- [x] #725\r\n",
        "epic": true,
        "title": "JSON/YAML output for CLI commands"
    },
    {
        "body": "**Package Information**\r\n - Name: Quickwit\r\n - Source Code: https://github.com/quickwit-oss\r\n - Helm Chart: https://github.com/quickwit-oss/helm-charts\r\n - Website: https://quickwit.io/\r\n\r\n**If you are an author of this project, let us know**\r\nI am not the author of the package, but we already had a call with @fmassot about the package integration and will support him with an initial version.\r\n\r\n\r\n**Additional information:**\r\nQuickwit requires an s3 bucket and a postgres database for storage.\r\n\r\nFor the postgres can create a dependency on the cnpg-operator and but a manifest in the Glasskube package and than reference the access credentials from the cnpg secret.\r\n\r\nFor the S3 bucket we need to find a solution.\r\n\r\n**More information:**\r\n - https://quickwit.io/docs/deployment/kubernetes/helm",
        "packages": true,
        "title": "Quickwit package integration"
    },
    {
        "body": "**Describe the bug**\r\nWhen using `glasskube bootstrap` to upgrade the cluster components from version 0.2 to 0.3 there is an error because the webhook cert job cannot be updated.\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Setup a fresh cluster\r\n2. Bootstrap an older version\r\n3. Bootstrap a newer version\r\n\r\n**Expected behavior**\r\nIf a job with the same name already exists, do one of the following:\r\n- It is not updated\r\n- It is deleted and re-created using the updated manifest\r\n\r\nThis should not be limited to the webhook cert job, it should work for any potential job we might add.\r\n\r\n**Additional context**\r\n\r\n",
        "bug": true,
        "component: cli": true,
        "help wanted": true,
        "title": "Error updating using `bootstrap`"
    },
    {
        "body": "**Describe the bug**\r\nWhen opening the details page of a package, which has a boolean value definition without a default value, the following error appears in the server log: `strconv.ParseBool: parsing \"\": invalid syntax`.\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior: Open kube-prometheus-stack detail page. The error will be shown twice (once for each such value). \r\n\r\n**Expected behavior**\r\nThe error should not appear. \r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: 1.28\r\n - Provider: minikube\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: v0.2.1\r\n - CLI version: v0.2.1\r\n\r\n**Additional context**\r\nQuite low priority since no functionality is affected at all, it's just confusing. ",
        "bug": true,
        "component: ui": true,
        "needs-triage": true,
        "title": "Boolean parsing error on UI details page for value definitions without a default value"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWhile using the UI, the connection to the API server (especially in the watch loops) could be lost. I had this issue recently when using glasskube in my OVH cluster, and then running a security patch of the kubernetes cluster, where the watch loop seems to have been disturbed at least:\r\n\r\n```\r\nW0423 13:21:29.949641   75118 reflector.go:462] pkg/mod/k8s.io/client-go@v0.29.4/tools/cache/reflector.go:229: watch of *v1alpha1.Package ended with: Internal error occurred: rpc error: code = Unknown desc = context canceled\r\nW0423 13:30:29.677213   75118 reflector.go:462] pkg/mod/k8s.io/client-go@v0.29.4/tools/cache/reflector.go:229: watch of *v1alpha1.Package ended with: an error on the server (\"unable to decode an event from the watch stream: http2: client connection lost\") has prevented the request from succeeding\r\nW0423 13:30:29.677265   75118 reflector.go:462] pkg/mod/k8s.io/client-go@v0.29.4/tools/cache/reflector.go:229: watch of *v1alpha1.PackageInfo ended with: an error on the server (\"unable to decode an event from the watch stream: http2: client connection lost\") has prevented the request from succeeding\r\n```\r\n\r\nInterestingly, it seems that afterwards the connection has come back up automatically. Either way, we should investigate this (maybe there are also other cases where the watch loop is cancelled / terminated) and find a way to show this information and how to resolve it to the user on the UI, e.g. \"It seems that your Kubernets API server is not reachable – please check again and restart with glasskube server\". \r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\n\r\n",
        "component: ui": true,
        "enhancement": true,
        "needs-triage": true,
        "title": "Kube API server connection indicator on UI"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWhen testing in a cluster with existing components, it could happen that `glasskube install` overrides/changes existing components.\r\n\r\n**Describe the solution you'd like**\r\nThe user should be warned and/or asked for confirmation whether to proceed. \r\n\r\nTo be discussed how exactly this should look like and work. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\n\r\n",
        "enhancement": true,
        "needs-triage": true,
        "title": "User confirmation when existing resources are going to be modified"
    },
    {
        "body": "**Describe the bug**\r\nWhile a package is being uninstalled, it is expected that the disabled Pending button is shown (although this should change with #456 – the problem would most likely still be the same). This works fine in minikube clusters, but seems to be different in a proper cluster (like in this case, OVH). Here the Pending button is shown for a very short time, and then it switches back to the Open/Uninstall button again. When uninstallation is finished, these buttons are removed correctly. \r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Uninstall a package via UI\r\n\r\n**Expected behavior**\r\nPending button is shown during uninstallation. \r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: 1.27.4-0\r\n - Provider: OVH\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: v0.2.1\r\n - CLI version: v0.2.1\r\n\r\n**Additional context**\r\n\r\n* The events/updates arrive in the correct order at the client via the websocket, so it must be some client-side issue. \r\n* The issue does not arise when using the dev build or a locally built binary, only when using the released build. ",
        "bug": true,
        "component: ui": true,
        "title": "Uninstalling via UI does not show pending in OVH cluster"
    },
    {
        "body": "**Describe the bug**\r\nWhen during the same UI process a package has been opened, uninstalled, then installed again and opened again, the open fails. The tab is being opened, but it stays empty. There is also no error message on the UI, but one in the server console:\r\n\r\n```\r\nE0423 13:10:02.367041   75118 portforward.go:409] an error occurred forwarding 3000 -> 80: error forwarding port 80 to pod 1157c257cc625a8eaac376e63d2bb482f9da8fe66b9c891319d5e72e2896b8b0, uid : failed to find sandbox \"1157c257cc625a8eaac376e63d2bb482f9da8fe66b9c891319d5e72e2896b8b0\" in store: not found\r\n```\r\n\r\nThere might also be other triggers which cause the forwarded-to pod to be deleted (e.g. config changes?). \r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Open a package via UI\r\n2. Uninstall the package\r\n3. Install the package again\r\n4. Open the package via UI\r\n\r\n**Expected behavior**\r\nOpen works. \r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: 1.28\r\n - Provider: minikube\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: v0.2.1\r\n - CLI version: v0.2.1\r\n",
        "bug": true,
        "component: ui": true,
        "title": "Open via UI fails when pod changes"
    },
    {
        "body": "**Describe the bug**\r\nIf a YAML file contains multiple documents separated with a `---` document separator, it can optionally start with a document separator as well. If this is done, though, GitHub pages skips the first (or more?) documents.\r\n\r\n**To Reproduce**\r\nMust be reproduced on GitHub pages\r\n\r\n**Expected behavior**\r\nFull YAML is returned.\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: 0.2.1\r\n - CLI version: 0.2.1\r\n\r\n**Additional context**\r\nDiscovered by @pmig.\r\n\r\nThis bug is possibly caused by the Jekyll pre-processor that GitHub pages uses when the default workflow is used. This can probably be prevented by simply running the action in a custom workflow without any preprocessing (since we don't need any).",
        "bug": true,
        "packages": true,
        "title": "GitHub Pages does not always render multi-document YAML files correctly"
    },
    {
        "body": "**Describe the bug**\r\nWhen uninstalling a package, when the package has been deleted from the cluster the buttons on the top of the page disappear but the \"install\" part is still missing. After refreshing the page, it is there.\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Run the UI with `glasskube serve`\r\n2. Go to an installed package\r\n3. Press the uninstall button\r\n4. Wait for completion\r\n\r\n**Expected behavior**\r\nthe install form appears at the bottom of the page.\r\n\r\n**Screenshots**\r\n![image](https://github.com/glasskube/glasskube/assets/16959694/c36863e0-ba3e-454f-84c3-d854c696e9da)\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: v1.28.3\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: 0.2.0\r\n - CLI version: 0.2.0\r\n\r\n**Additional context**\r\nAdd any other context about the problem here.\r\n",
        "bug": true,
        "title": "UI: Details page incomplete after uninstall completed"
    },
    {
        "body": "**Describe the bug**\r\nIt seems that glasskube and certain other tools using goreleaser use the same location for their copyright file: `/usr/share/doc/nfpm/copyright`. \r\n\r\nOutput of trying to install glasskube v0.2.0 via `dpkg -i`:\r\n\r\n```\r\nPreparing to unpack glasskube_v0.2.0_amd64.deb ...\r\nUnpacking glasskube (0.2.0) ...\r\ndpkg: error processing archive glasskube_v0.2.0_amd64.deb (--install):\r\n trying to overwrite '/usr/share/doc/nfpm/copyright', which is also in package k9s 0.32.4\r\nErrors were encountered while processing:\r\n glasskube_v0.2.0_amd64.deb\r\n```\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Install k9s binary\r\n2. Try to install glasskube\r\n\r\n**Expected behavior**\r\nInstallation should work – the copyright file should probably put into a glasskube subdirectory instead. \r\n\r\n**Screenshots**\r\nIf applicable, add screenshots to help explain your problem.\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: 1.28.3\r\n - Provider: minikube\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: -\r\n - CLI version: v0.2.0\r\n\r\n**Additional context**\r\n* https://nfpm.goreleaser.com/tips/#the-copyright-file\r\n* https://github.com/opentofu/opentofu/issues/805\r\n* https://github.com/k8sgpt-ai/k8sgpt/issues/878\r\n",
        "bug": true,
        "title": "dpkg install not possible: \"trying to overwrite '/usr/share/doc/nfpm/copyright'\""
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\n`glasskube version` shows an error when not bootstrapped yet, but it's a valid case to not have it bootstrapped yet and check the client version.\r\n\r\n**Describe the solution you'd like**\r\nInstead of the error it should show an information that it's not bootstrapped yet, and a hint that it can be done with the `bootstrap` command. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\n\r\n",
        "bug": true,
        "component: cli": true,
        "good first issue": true,
        "help wanted": true,
        "title": "`glasskube version` should not show an error when not bootstrapped"
    },
    {
        "body": "**Describe the bug**\r\nBy default the bootstrap command downloads the Glasskube manifest from a GitHub release. If there is a HTTP error response (e.g. 404), the app should show the error code and exit without trying to parse the response as YAML.\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Run `glasskube bootstrap --url ...` with a URL that leads to a 404 error\r\n\r\n**Expected behavior**\r\nA helpful error message.\r\n\r\n",
        "bug": true,
        "component: cli": true,
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "HTTP errors not handled correctly when calling `glasskube bootstrap`"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThere might be issues if the local port is already in use when using the `open` command. It should be possible to change the default if desired.\r\n\r\n**Describe the solution you'd like**\r\nOn the CLI, a different port can be specified with `--port`. If the flag is used and there are multiple entrypoints for the package and no single entrypoint is specified via CLI argument, the command should exit with an error. If the flag is not specified, the default from the manifest should be used.\r\n\r\n**Describe alternatives you've considered**\r\nAdding logic to pick a different random port (similar to what we already to for the `serve` command), but I think this would be more complicated an error prone in this situation, since the listener can not be reused. We might have to extract the port from the listener, then close it and reuse the same port for another listener… OTOH there is no reason why both features shouldn't exist.\r\n\r\n**Additional context**\r\nNo idea how to do this on the UI :thinking: \r\n",
        "component: cli": true,
        "enhancement": true,
        "go": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Changing the local port for `glasskube open`"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nI have a similar issue as described in https://github.com/glasskube/glasskube/issues/306#issuecomment-1976360853:  \r\n\r\nI am trying to open cyclops via `glasskube open` which is not working because `cyclops v0.3.1` (and prior versions) sets its [service type to LoadBalancer](https://github.com/cyclops-ui/cyclops/blob/v0.3.1/install/cyclops-install.yaml#L405-L407) so that cyclops already runs on port 3000 on localhost.\r\n\r\nSee:\r\n```sh\r\n$ glasskube serve\r\nglasskube UI is available at http://localhost:8580\r\ncould not open cyclops: could not open entrypoint ui: tcp port 3000 is not free\r\n\r\n$ kubectl get -n cyclops svc\r\nNAME           TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE\r\ncyclops-ctrl   LoadBalancer   10.99.206.129   localhost     8080:30599/TCP   3h\r\ncyclops-ui     LoadBalancer   10.111.35.252   localhost     3000:31474/TCP   3h\r\n\r\n$ glasskube open cyclops\r\n❌ Could not open package cyclops: could not open entrypoint ui: tcp port 3000 is not free\r\n```\r\n\r\n**Describe the solution you'd like**\r\nHow about patching the package manifests with some sane defaults before adding them to the glasskube packages?\r\n\r\n_TBH I believe the package should not be exposed to some port per default as I want to put it on another port or serve it under some domain maybe._\r\n\r\n**Describe alternatives you've considered**\r\nI just tried a poc editing the cyclops manifests, but the changes were obviously reset after a short time 😄\r\n\r\nTest run: \r\n```sh\r\n$ kubectl -n cyclops edit services cyclops-ui\r\n\r\n$ glasskube open cyclops\r\nui\t |I| Forwarding from 127.0.0.1:3000 -> 80\r\nui\t |I| Forwarding from [::1]:3000 -> 80\r\n✅ cyclops is now reachable at http://localhost:3000\r\nui\t |I| Handling connection for 3000\r\n^C👋 Received interrupt signal\r\n🛑 Terminating forwarders...\r\n\r\n$ glasskube open cyclops\r\n❌ Could not open package cyclops: could not open entrypoint ui: tcp port 3000 is not free\r\n```\r\n\r\n**Additional context**\r\nSee error in UI:\r\n![grafik](https://github.com/glasskube/glasskube/assets/22871352/ef4e0b78-6489-4d77-bd9d-2f6e35fb85b4)\r\n\r\nVersions:\r\n```\r\n$ glasskube version\r\nglasskube: v0.1.0\r\npackage-operator: v0.1.0\r\n```\r\n\r\nPS: This probably does not happen to cyclops only but other packages too. Could be considered a install.yaml design issue??\r\n",
        "enhancement": true,
        "title": "Patch the package manifests prior to adding them in the package ecosystem?"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nCreate an ArgoCD guide \r\n\r\n\r\n**Additional context**\r\nRef #307 \r\n",
        "documentation": true,
        "enhancement": true,
        "title": "ArgoCD Guide"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nA user can enter different kinds of references to choose config values for a package (e.g. ConfigMap, Secret, Package Config), both on the UI and CLI. They don't yet see whether the entered reference (e.g. namespace + name + key in the case of a ConfigMap) can be resolved and is valid (at least on the UI). \r\n\r\n**Describe the solution you'd like**\r\nFor a reference input, the user should see some hint of whether the entered reference is:\r\n* existing and passes validation\r\n* existing but does not pass validation\r\n* not existing\r\n\r\n**To be discussed**: This kind of hint should probably not be a strict validation? As also described in #495, when a referenced object gets changed or deleted, the configuration could become invalid. We need a way to deal with this. \r\n\r\nThere are lots of ways in which a reference could become invalid:\r\n* a referred value changes, and the new value is not valid according to the glasskube package anymore\r\n* a referred value is deleted (e.g. because the ConfigMap, Secret or Package has been removed)\r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\nFollow-Up of #121 \r\nRelated to #495 \r\n",
        "component: cli": true,
        "component: ui": true,
        "enhancement": true,
        "title": "Dealing with broken configuration references"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nOn the package configuration page, the user can enter reference values (ConfigMap, Secret, Package Config), but the input fields are classic text fields without any additional support to show which options there are. \r\n\r\n**Describe the solution you'd like**\r\nFor ConfigMap and Secret inputs, the namespace field should show the namespaces of the cluster, and if a namespace has been entered, the name field should show the config maps of this namespace. If possible, once the namespace + name have been entered, the key field shows the possible keys to select from. \r\n\r\nFor Package inputs, the package field should show all installed packages, and if a package has been selected, the value field should show the possible values. \r\n\r\nAll of the inputs should support having just plain text too (i.e. none of the available options): Even if we don't allow users to input non-existing objects (to be discussed), someone could always delete some config map or secret afterwards – but the reference should still be visible in the UI.\r\n\r\n**Describe alternatives you've considered**\r\nClassic select without text input field – easier to implement but more difficult for the user if there are a lot of items. Also has the downside that it cannot display broken references (e.g. a reference that has become invalid because a referred config map was deleted). \r\n\r\n**Additional context**\r\nFollow-Up of #121 \r\n\r\nThe most basic way to do this would be an html datalist element, which has text filtering on statically defined options out of the box. But there are certainly more advanced ways to implement this too. ",
        "component: ui": true,
        "enhancement": true,
        "title": "Search/Autocomplete in Package Configuration Page"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\n\r\nWhen the user is not connected to the internet and `glasskube bootstrap` is used the bootstrap fails and returns a memory invalid or nil pointer deference error but instead we should print a message as glasskube is not connected to the internet. Something like this\r\n\r\n```\r\n~$ glasskube bootstrap\r\n⚠️ Glasskube is not connected to the internet, cannot bootstrap.\r\n```\r\n\r\n**Describe the solution you'd like**\r\nImprove error handling for `cmd/bootstrap.go`\r\n\r\nAddition from @christophenne: I think the error message doesn't necessarily have to be \"not connected to internet\", but can be more generic. The point where the first call to some http endpoint is made, is when fetching the lastest version of glasskube. It should be fine to do the same error handling as used in `clientutils.FetchResources`.\r\n\r\n**Describe alternatives you've considered**\r\n\r\n**Additional context**\r\n",
        "component: client": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Handle bootstrap errors gracefully when glasskube is not connected to the internet"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThe logos located in the [package section](https://glasskube.dev/packages/) of the website fail to render on Firefox\r\n![image](https://github.com/glasskube/glasskube/assets/38757612/1fe1efe0-c515-425e-8edd-500ef7066729)\r\n\r\nIt seems to fail due to the following\r\n```\r\nThe resource at “https://pbs.twimg.com/profile_images/1092805171938234371/CeyfzQLG_400x400.jpg” was blocked because content blocking is enabled.\r\n```\r\n**Describe the solution you'd like**\r\nMake sure all visual assets render on Firefox\r\n\r\n**Additional context**\r\nReference: https://developer.mozilla.org/en-US/docs/Web/Privacy/Firefox_tracking_protection\r\n",
        "good first issue": true,
        "help wanted": true,
        "title": "Enable logo rendering on Firefox",
        "website": true
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nAs can be seen in the screenshot the filter search bar in the [website's package section](https://glasskube.dev/packages/) is in a peculiar spot. A better place would be on the opposite side beside the `Filters` title for example. We are open to different options for the positioning of the search bar as long as it is intuitive and improves the sites usability. \r\n\r\n<img width=\"1381\" alt=\"Screenshot 2024-04-05 at 16 53 47\" src=\"https://github.com/glasskube/glasskube/assets/38757612/5fa183b8-e4c9-46b8-957a-33642c71bdda\">\r\n\r\n**Describe the solution you'd like**\r\nA functioning filters search bar in a more user friendly position\r\n\r\n",
        "good first issue": true,
        "help wanted": true,
        "title": "Move the search bar in the package section of the website",
        "website": true
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThe [package catalogue](https://glasskube.dev/packages/) of supported and planned tools has two distinct problems, it would be great to address them both:\r\n1. Logos sizing and padding is not standardised. We would like for all logos to have the same measurements and padding.\r\n2. The logo marks are not configured to handle dark mode. Docusaurus enables image switching depending on the light mode in use. Please configure and enable it. \r\n\r\n**Describe the solution you'd like**\r\nStandardise the size and spacing of the logos in the package section and make them responsive to dark mode.\r\n\r\n**Additional context**\r\nDocusaurus documentation: https://docusaurus.io/docs/api/themes/configuration\r\n",
        "good first issue": true,
        "help wanted": true,
        "title": "Fix logo images in the package section of the website",
        "website": true
    },
    {
        "body": "**Describe the bug**\r\nWhen having 2.7.0+1 installed, and updating to 2.7.0+2 (changing from manifest to helm chart), the package kubernetes-dashboard has status \"InstallationFailed\" and stays there. Error message: \r\n\r\n\"An error occurred during the update: package update for kubernetes-dashboard failed: Package is not ready (reason InstallationFailed): flux: Helm install failed for release kubernetes-dashboard/kubernetes-dashboard with chart kubernetes-dashboard@6.0.8: Unable to continue with install: ServiceAccount \"kubernetes-dashboard\" in namespace \"kubernetes-dashboard\" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key \"app.kubernetes.io/managed-by\": must be set to \"Helm\"; annotation validation error: missing key \"meta.helm.sh/release-name\": must be set to \"kubernetes-dashboard\"; annotation validation error: missing key \"meta.helm.sh/release-namespace\": must be set to \"kubernetes-dashboard\"\"\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Install kubernetes-dashboard in 2.7.0+1\r\n2. When installation succeeded, update to 2.7.0+2\r\n\r\n**Expected behavior**\r\nUpdate should work.\r\n\r\n**Screenshots**\r\n![Screenshot from 2024-04-05 13-34-49](https://github.com/glasskube/glasskube/assets/7556574/e7ee453e-e196-4338-ab0a-4090a0bcb54b)\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: 1.28\r\n - Provider: minikube\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: dev\r\n - CLI version: dev\r\n \r\n**Additional context**\r\n\r\n",
        "bug": true,
        "title": "kubernetes-dashboard update from 2.7.0+1 to 2.7.0+2 is broken",
        "wontfix": true
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\n\"latest\" version does not always mean \"newest\" version. This is very confusing.\r\n\r\n**Describe the solution you'd like**\r\nDocument how we use the term \"latest\" version. \r\n\r\n**Describe alternatives you've considered**\r\nRename \"latest\" to \"stable\" instead?\r\n\r\n**Additional context**\r\n\r\n",
        "component: cli": true,
        "component: ui": true,
        "enhancement": true,
        "title": "Change \"Latest version\" to \"Stable version\" for packages everywhere"
    },
    {
        "body": "Looks like there is no way to make package install from script.\r\nI cant install package without keyboard console interaction, there is no `--yes` option like in `apt/yum`.\r\nMaximum what I achieved \r\n\r\n```\r\nyes | glasskube install argo-cd --enable-auto-updates\r\n```\r\n\r\nbut thats ugly and will not work on Windows...",
        "component: cli": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Too \"GUIsh\" install, need --yes option"
    },
    {
        "body": "When doing \"open\" two times for one app it fails.\r\n\r\nExpected that second `glasskube open argo-cd` will open in browser already existed tunnel instead of fail.",
        "component: cli": true,
        "enhancement": true,
        "needs-triage": true,
        "title": "When doing \"open\" two times for one app it fails."
    },
    {
        "body": "When running `glasskube install argo-cd` on not bootstrapped cluster, CLI asking if I want to bootstrap instead of error message and non-zero exit code.\r\n\r\nIf you're making `glasskube` in idea of Linux package managers, it should not ask anything by default, too \"GUIsh\".",
        "bug": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Install not returning error message if cluster not bootstrapped"
    },
    {
        "body": "Please refer to the parent issue for more info, specification and related tasks\r\n\r\n### Original issue text\r\n\r\nHey folks,\r\n\r\ndoing integration of your app in my solution and faced one thing - lack of JSON output for `glasskube list`, want something like `... --format json` like in Helm.\r\n\r\nThanks.",
        "component: cli": true,
        "enhancement": true,
        "help wanted": true,
        "needs-triage": true,
        "title": "Add `--output` support for `glasskube list`"
    },
    {
        "body": "Hey folks,\r\n\r\ntrying to make \r\n\r\n```\r\nglasskube bootstrap\r\nglasskube install argo-cd\r\n\r\nAn error occurred during installation:\r\n\r\nInternal error occurred: failed calling webhook \"vpackage.kb.io\": failed to call webhook: Post \"https://glasskube-webhook-service.glasskube-system.svc:443/validate-packages-glasskube-dev-v1alpha1-package?timeout=10s\": no endpoints available for service \"glasskube-webhook-service\"\r\n```\r\n\r\nMeanwhile deployment:\r\n![image](https://github.com/glasskube/glasskube/assets/469388/bc62e8bb-9869-4125-8155-f63b9c7314c4)\r\n\r\nExpected behaviour:\r\n* boostrap waiting for deployment to be ready\r\n* install waiting for returning error message",
        "bug": true,
        "help wanted": true,
        "title": "bootstrap/install not waiting for operator to be ready"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\n`install` and `update` commands offer the possibility to update to a specific verison with the `-v` flag. The version entered must have the `v` prefix, or otherwise the package will not be found in the package repo. That's not the greatest user experience.\r\n\r\nExample:\r\n`glasskube install keptn -v v2.0.0-rc.1+1` works, because the version number has the `v` prefix.\r\n`glasskube install keptn -v 2.0.0-rc.1+1` does not work, because the version number is missing the `v`.\r\n\r\n**Describe the solution you'd like**\r\nThe user should be able to enter their version without the `v` prefix. This should work for the install command and also for the update command. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\n#412 is still in progress. \r\n",
        "component: cli": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Handle `v` prefix in versions in install and update command"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nOnce #412 is done, the `glasskube update` command is able to update a package to a specific version. However, it does not yet support shell completion yet like the install command does. \r\n\r\n**Describe the solution you'd like**\r\nWhen the user enters `glasskube update <package-name> -v` and then presses the tab key, a list of possible versions should appear, from which the user can choose. This is similar to what the install command already does when the `-v` flag is given, however its not exactly the same: the update command completion should only show those versions of the package, which are newer then the currently installed version. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\nFollow up of #412\r\n\r\nAs an entrypoint, you can take a look at the `install` command, specifically the function `completeAvailablePackageVersions`. It will have to be adapted to only show versions that are newer than the currently installed one (meaning that the package also needs to be fetched first).\r\n\r\nTo be fair, its a trickier \"good first issue\". As always, you can contact us any time in case of questions or problems. ",
        "component: cli": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "CLI version completion when updating to specific version"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nA lot of open source projects (e.g. [keptn](https://keptn.sh/stable/) habe an interactive widget on the top right corner to display the up to the GitHub Star count (as well as the amount of forks and the latest release).\r\n\r\n**Describe the solution you'd like**\r\nAdd an interactive star counter that links to GitHub.\r\n\r\n\r\n",
        "enhancement": true,
        "title": "Add GitHub Star counter to Website",
        "website": true
    },
    {
        "body": "Currently, a package is displayed as \"pending\" after starting an uninstall action, provided that the package-operator is running in the cluster. If no package-operator is running, the displayed state doesn't change until the package is finally removed after GC has completed (we use foreground deletion for Glasskube packages).\r\n\r\nIt would be better to detect if a package has been marked for deletion and display a different button state on the overview and details pages if it is. To start with, the button could look like the \"pending\" button but with a different text, e.g. \"uninstalling\". It is important that the button is also `disabled`.\r\n\r\nA resource can be considered marked for deletion if it has a `DeletionTimestamp`:\r\n```go\r\nif !pkg.DeletionTimestamp.IsZero() {\r\n  // pkg is being deleted ...\r\n}\r\n```",
        "component: ui": true,
        "enhancement": true,
        "help wanted": true,
        "title": "Show a different button state if a package is currently being uninstalled"
    },
    {
        "body": "**Describe the bug**\r\nThe `bootstrap` command does not always overwrite / reset all Glasskube resources, which lead to an inconsistent state. \r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Use a cluster for local development and execute  `make install webhook cert`\r\n2. Execute `glasskube bootstrap` \r\n3. See that the service type of the webhook service is still `External`\r\n\r\n**Expected behavior**\r\nGlasskube resources should be applied as defined\r\n\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: 1.28\r\n - Provider: minikube\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: v0.1.0\r\n - CLI version: v0.1.0\r\n\r\n**Additional context**\r\nServer side apply probably will not update fields it's not the owner of.\r\n",
        "bug": true,
        "title": "`glasskube bootstrap` does not always apply all changes"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThe package client is already cached, the package info one not yet. This came up in #415, where we noticed that when having at bigger number of packages (at least 4) results in a lot of calls to get package infos from the API server. The go client throttles the requests to the server with its [default settings](https://pkg.go.dev/k8s.io/client-go/rest#pkg-constants). \r\n\r\n**Describe the solution you'd like**\r\nApply the same caching mechanism to the package info client to reduce the number of requests.\r\n\r\n**Describe alternatives you've considered**\r\nIn the specific use case mentioned above, we could also tweak the client side throttling settings to allow more requests.\r\n\r\n**Additional context**\r\n\r\n",
        "component: client": true,
        "enhancement": true,
        "title": "Cached PackageInfo Client"
    },
    {
        "body": "The update transaction returned by `updater.Prepare()` already contains a list of items with conflicts but we don't use them yet. \r\n\r\nHow to display these items: TBD",
        "component: cli": true,
        "component: ui": true,
        "enhancement": true,
        "title": "Show packages that can not be updated due to a conflict"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nOutput of `glasskube ls` when having installed keptn in a later version than latest:\r\n```\r\n go run cmd/glasskube/main.go ls\r\nNAME                  STATUS         VERSION                              AUTO-UPDATE\r\nargo-cd               Not installed                                         \r\ncert-manager          Ready          v1.14.2+1                              \r\ncyclops               Not installed                                         \r\ningress-nginx         Not installed                                         \r\nkeptn                 Ready          v2.0.0-rc.1+1 (v0.10.0+1 available)    \r\nkubernetes-dashboard  Not installed                                         \r\n```\r\n\r\n**Describe the solution you'd like**\r\nIn the above scenario, \"(v0.10.0+1 available)\" should not be shown because the version marked as latest is older than the version installed. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\n\r\n",
        "component: cli": true,
        "enhancement": true,
        "help wanted": true,
        "title": "`glasskube ls` should not show latest available version if installed version is newer than latest"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nComments are currently not supported by docusaurus.\r\n\r\n**Describe the solution you'd like**\r\nA GitHub based comment solution like https://giscus.app/\r\n\r\n**Describe alternatives you've considered**\r\n\r\n**Additional context**\r\n",
        "enhancement": true,
        "title": "Integrate giscus.app for blog comments"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nA clear and concise description of what the problem is. Ex. I'm always frustrated when [...]\r\n\r\n**Describe the solution you'd like**\r\nA clear and concise description of what you want to happen.\r\n\r\n**Describe alternatives you've considered**\r\nA clear and concise description of any alternative solutions or features you've considered.\r\n\r\n**Additional context**\r\nAdd any other context or screenshots about the feature request here.\r\n",
        "enhancement": true,
        "needs-triage": true,
        "title": "Refactor to client-side dependency resolution"
    },
    {
        "body": "**Describe the bug**\r\nIf there is a Package resource in the cluster that has an empty `.Status.OwnedPackageInfos`, the `serve` command panics when trying to access the list page.\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Stop the operator, if it is running and delete the `ValidatingWebhookConfiguration`\r\n2. Start UI\r\n3. Install any package\r\n4. Reload the page\r\n\r\n**Expected behavior**\r\nPage loads\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: v1.28.3\r\n - Provider: Minikube\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: n/a\r\n - CLI version: 0.1.0\r\n\r\n**Additional context:**\r\nThe panic occurs here: \r\n\r\nhttps://github.com/glasskube/glasskube/blob/a86fc04017ef0066ad289abac110cfcfcfedd827/pkg/list/list.go#L124\r\n\r\nReferenced here: https://github.com/glasskube/glasskube/pull/413#pullrequestreview-1954359619",
        "bug": true,
        "title": "UI panics if a Package has no PackageInfo"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nA user can only update an outdated version to the latest version. However when they are on a version newer than latest (e.g. some prerelease of the next major version) they cannot update anymore. Also when dependency requirements make it impossible to update to the latest version from an older version, it might still make sense to update to a version below latest. \r\n\r\n**Describe the solution you'd like**\r\nThe `update` command should provide a `-v` version flag like the `install` command. Invalid updates to a smaller version than the one installed must be prohibited.\r\nThis version flag is only allowed in combination with updating a single package, as it would make no sense in the \"update all\" scenario.\r\n\r\nRight now there are no plans to offer this on the UI explicitly. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n**Additional context**\r\nRelated #344 (the missing glue will probably be \"calculating\" the maximum possible version to update to)\r\n",
        "component: cli": true,
        "enhancement": true,
        "title": "Update to specific package version in CLI"
    },
    {
        "body": "**Describe the bug**\r\nWhen defining a dependency with a version range which includes a build number, e.g. \">= 1.13.3+2\", the build number is ignored and version 1.13.3+1 would also be considered as compatible. \r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. use local package repo, where kubernetes-dashboard depends on cert-manager > 1.13.3+1\r\n2. install cert-manager in version 1.13.3+1\r\n3. install kubernetes-dashboard: cert-manager will not be updated, although it would be required when installing kubernetes-dashboard\r\n\r\n**Expected behavior**\r\nUp for discussion: When checking a version against a version constraint, the build number should be considered too. Alternatively, we can also disallow using build numbers in the dependency version ranges, which would make things a lot easier. \r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: dev\r\n - CLI version: dev\r\n\r\n**Additional context**\r\nSimilar to #397\r\n",
        "bug": true,
        "documentation": true,
        "title": "Build numbers not considered in dependency ranges"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nLet `P` and `D` be packages, each with two versions: `v1` and `v2`, where `Pv1 depends on Dv1` and `Pv2 depends on Dv2`. \r\n\r\nA user that has installed `Pv1` (and therefore got `Dv1` installed automatically), cannot perform an update to `Pv2`. \r\n\r\nThis because such an update attempt would cause two conflicts:\r\n* `P` update to `v2` is not possible, because it would require `Dv2`, but the actual `D` version is `v1`.\r\n* `D` update to `v2` is not possible, because `Dv1` is required by `Pv1`.\r\n\r\nThis is according to the update mechanism we currently have. It's intended to update one package at a time, and only updates that are valid changes to the current state, are allowed. So while technically correct, this could lead to update deadlocks where a user cannot update a package anymore. \r\n\r\nTemporarily we should avoid such a situation to be possible in the package repository, but in the long term this will not be sufficient and not easy to understand. \r\n\r\n**Describe the solution you'd like**\r\nTo be discussed.\r\n",
        "component: cli": true,
        "component: package-operator": true,
        "component: repo": true,
        "component: ui": true,
        "enhancement": true,
        "needs-triage": true,
        "title": "Resolve Update Deadlocks"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nDuring every update or uninstall its possible that required packages are going to be uninstalled as well. The user does not see which packages are going to be removed at all.\r\n\r\n**Describe the solution you'd like**\r\nUI and CLI should list the pruned packages to the user. \r\n\r\nOn the UI we currently have the browser-built-in confirmation, this will have to be changed to the same bootstrap modal as in installation and update. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\n\r\n",
        "component: cli": true,
        "component: ui": true,
        "enhancement": true,
        "title": "Show pruned packages at update and uninstall"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWe show the uninstall button on the package detail page, even though the operation is not possible because another package depends on it. When clicking uninstall, nothing happens except for the webhook validator error message in the server log.\r\n\r\n**Describe the solution you'd like**\r\nThe uninstall button should not be visible in such cases. \r\n\r\nIn the CLI command we could also abort earlier and state right away that uninstall is not possible. \r\n\r\n**Describe alternatives you've considered**\r\nShowing an error message on the UI if the operation fails. \r\n\r\n**Additional context**",
        "component: cli": true,
        "component: ui": true,
        "enhancement": true,
        "title": "Disallow uninstall when there are dependent packages"
    },
    {
        "body": "**Describe the bug**\r\nWhen creating a new latest version of a package in the package repo, which only differs to its predecessor in the build number (i.e. previously latest version: 2.7.0+1, new latest version: 2.7.0.+2), the package is not marked as updatable. \r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n0. use a local package repo\r\n1. install kubernetes-dashboard in 2.7.0+1 for simplicity via CLI\r\n2. in a local package repo, copy version 2.7.0+1 of kubernetes-dashboard, with version number 2.7.0+2\r\n3. make 2.7.0+2 the latest version in the repo index and package index\r\n4. run `glasskube update`: kubernetes-dashboard will not be in the list of updatable packages.\r\n\r\n**Expected behavior**\r\n`glasskube update` should probably show kubernetes-dashboard as updatable, even though this is not perfectly following the semver specification (see additional context below).\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: 1.29\r\n - Provider: minikube\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: dev\r\n - CLI version: dev\r\n\r\n**Additional context**\r\nThe underlying comparison of versions is done with the semver package, and according to semver spec, this comparison is correct: the build number (or what we interpret as build number) could be any string. See https://github.com/helm/helm/issues/6710#issuecomment-558711082\r\n",
        "bug": true,
        "needs-triage": true,
        "title": "Build numbers are not considered in version comparison"
    },
    {
        "body": "**Describe the bug**\r\nWhen the flag --skip-update-check is used in cli, it should check for updates and print the update message but the flag seems to fail in dev builds.\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\nUse the --skip-update-check flag followed by a command\r\n`glasskube <command> --skip-update-check=false`\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: 0.0.4\r\n - CLI version: dev\r\n\r\n\r\n",
        "bug": true,
        "needs-triage": true,
        "title": "Flag --skip-update-check fails in dev build "
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nA user might install a different from the latest version of some package from the package detail page. When they entered this page, it was rendered based on the manifest of the latest version. After installation, update or uninstallation, the page is outdated (e.g. manifest link is wrong, dep because it shows a different version. \r\n\r\n**Describe the solution you'd like**\r\nThe detail part of the page should be reloaded in some smart htmx way. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\n\r\n",
        "component: ui": true,
        "enhancement": true,
        "title": "Re-Render Package Detail Page after install, uninstall and update"
    },
    {
        "body": "For most of these renovate PRs we only verify that all pipeline checks are green we merge them, we can automate this step. ",
        "dependencies": true,
        "title": "Automatically merge minor and patch dependency updates for github-actions and npm modules"
    },
    {
        "body": "[follow-up with keptn logo](https://github.com/keptn/lifecycle-toolkit/pull/3267#discussion_r1524911825)",
        "title": "Update keptn logo"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThe dependency manager checks only dependencies \"downwards\" (i.e. dependencies of a package), but not \"upwards\" (i.e. packages that are dependent on a package). This means that currently it's possible to update a package to a version that is invalid for a dependant package, leading to a dependency conflict. \r\n\r\n**Describe the solution you'd like**\r\nAlso check parent packages during validation. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\n\r\n",
        "component: client": true,
        "enhancement": true,
        "title": "Prevent invalid updates"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWe are only managing direct dependencies right now. \r\n\r\n**Describe the solution you'd like**\r\nDependencies of dependencies (in arbitrary depth) should also be supported at every use case.\r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\n\r\n",
        "component: cli": true,
        "component: client": true,
        "component: package-operator": true,
        "component: ui": true,
        "enhancement": true,
        "title": "Support transitive dependencies"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nGlobal update notification is only evaluated when the package overview page is rendered, and it might be (incorrectly) hidden dynamically by the update dialog. However, this is wrong and has many edge cases. \r\n\r\n**Describe the solution you'd like**\r\nInstead, like the update buttons of each package, the global update notification should appear/disappear at every package status change. For that, we need to hold all installed packages on the server and evaluate the state at every status change. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\nThis will fix #355 \r\n",
        "component: ui": true,
        "enhancement": true,
        "title": "Sync global update notification correctly"
    },
    {
        "body": "**Describe the bug**\r\nWhen updating from the package overview page, while the update notification is not present yet, the update does not do anything. This scenario shouldn't happen in the first place, but it happens because the update notification is not properly synced with the update buttons per package. \r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Open package overview and make sure the \"global\" update notification is not present. \r\n2. Install a package, not in latest version but in an older one.\r\n3. When the package is installed, the update button appears\r\n4. Clicking the update button opens the modal correctly, but the update button there does not trigger the update.\r\n\r\n**Expected behavior**\r\nUpdate should work, but also the global update notification should be properly in sync with the update button per package. \r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: \r\n - Provider: minikube\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: latest\r\n - CLI version: latest\r\n\r\n**Additional context**\r\n\r\nBrowser console says: \"htmx:targetError\". This means that the backend request is not even sent by htmx, because the target (the div of the update notification) is not present. This is why nothing happens. ",
        "bug": true,
        "needs-triage": true,
        "title": "Update not working when global update notification not present"
    },
    {
        "body": "**Describe the bug**\r\nOpening a package entry-point can fail for a multitude of reasons, but in no case we display an error message in the UI.\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n0. Open UI\r\n1. Install a package that has an entrypoint (e.g. cyclops)\r\n2. Stop the package-operator\r\n3. Delete all deployments in the package namespace\r\n4. Click \"open\"\r\n\r\n**Expected behavior**\r\nAn error message that no pod is ready to handle the entrypoint.\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: v1.28.3\r\n - Provider: minikube\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: 0.0.4\r\n - CLI version: 0.0.4\r\n",
        "bug": true,
        "needs-triage": true,
        "title": "No error message in UI when opening entry-point fails"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWe currently already have packages available in [`glasskube/packages`](https://github.com/glasskube/packages) that are not compatible with the current release, but only with the `main` branch. This will also happen in future as we are rapidly evolving.\r\n\r\n**Describe the solution you'd like**\r\nAdd a `requiredVersion` SemVer range to our package manifest, which is evaluated during package installation and package updates against the client _and_ controller version.\r\n\r\n**Describe alternatives you've considered**\r\nIntroduce a more sophisticated merge / release workflow, but it is hard to fully control this as users might use different versions of Glasskube along the way. \r\n\r\n**Additional context**\r\nThis ticket is slightly related to https://github.com/glasskube/glasskube/issues/112\r\n",
        "enhancement": true,
        "title": "Introduce min `glasskube` version for packages"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWe have the check in place once #205 is done, but there is no way to see it for the UI user. \r\n\r\n**Describe the solution you'd like**\r\nIf glasskube is bootstrapped, but the operator is in an older version, the user should get redirected to a page where they see the hint that their operator is outdated (similar to what they see on the CLI commands). Like on the regular bootstrap page, there should be a button to upgrade. \r\n\r\nNeeds discussion about what to do with \"custom\" installations (i.e. slim-bootstrapped environments). \r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\nRelated #205 \r\n",
        "component: ui": true,
        "enhancement": true,
        "title": "Show and resolve version mismatch between client and operator on the UI"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nCurrently, we show the update notification on the package overview whenever there is a package where latestVersion != spec.version, not taking the status into account. \r\n\r\n**Describe the solution you'd like**\r\nTake package status into account, such that the notification only appears when at least one package is ready. \r\n\r\n**Describe alternatives you've considered**\r\nNot implementing this could cause confusion, but it's probably not such a big deal.\r\n\r\n**Additional context**\r\n#329 #344 \r\n",
        "component: ui": true,
        "enhancement": true,
        "needs-triage": true,
        "title": "Show global Update Notification only when at least one ready package can be updated"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nAs of now, we show the update button (and the \"vX.Y.Z available\" in the CLI) whenever the latestVersion is not the installed version. The first problem with this is, that the user might be on a more current version than latest (see #329). The second one is, that it might not be possible to update to the latest version, because the package is required as a dependency by another package, or because a dependent package cannot be updated. Maybe there are even more cases where an update is not possible – TBD.\r\n\r\n**Describe the solution you'd like**\r\nUI/CLI should only offer the user to only show the updates that are possible in their cluster. This means that a package might not be able to be updated to latest version but to a version below that, or maybe not be able to be updated at all.\r\n\r\nParts of this have been done in #401 – but right now we don't offer the latest possible version to update to, we just don't offer an update at all.\r\n\r\n**Describe alternatives you've considered**\r\nNot implementing this and instead showing an error to the user that the update is not possible. This would still be possible but be a bit confusing and inconsistent. Also, it would not be possible to update to a lower version than latest. \r\n\r\n**Additional context**\r\nKind of related in terms of same code that will be touched: #329 \r\nPrior work on this: #401\r\n",
        "component: cli": true,
        "enhancement": true,
        "needs-triage": true,
        "title": "Offer only allowed updates on UI/CLI"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nIn #311 we found that the auto-updating process handling is not the correct way to approach this. Instead we want a separate component (operator) doing such updates by patching the Package version, instead of the package to have an empty version. See also #338. \r\n\r\n**Describe the solution you'd like**\r\nBecause of this change, the Package Version should be mandatory in the schema, and consequently all places where the Package Version is being used (operator, CLI, UI) must be refactored to the new logic. A package that should be auto-updated should get a label \"glasskube/auto-updated\". A package with such a label will then be picked up by the new controller (#338). \r\n\r\nDocumentation must be updated too.\r\n\r\n**Describe alternatives you've considered**\r\nNone\r\n\r\n**Additional context**\r\nSee #311, #338\r\n",
        "component: cli": true,
        "component: client": true,
        "component: package-operator": true,
        "component: ui": true,
        "enhancement": true,
        "title": "Mandatory Package Version"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWhen Glasskube is used in the GitOps approach (i.e. some git repository holds the desired `Package` custom resources), the users do not get notified when there is an update to on of their packages. \r\n\r\n**Describe the solution you'd like**\r\nGlasskube should offer some tool to open Pull requests in this Git repository, where package versions are updated, similar to what renovate/dependabot do. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\nThis idea originated when implementing #311, where we decided to do auto-updates in a different way (i.e. Packages always need to have `Spec.Version` set. \r\n",
        "enhancement": true,
        "needs-triage": true,
        "title": "Package Updates in GitOps installation"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nSo far we designed auto-updated packages to simply have no `Spec.Version` set. However, this leads to a lot of added complexity and coupling everywhere in the codebase. \r\n\r\n**Describe the solution you'd like**\r\nWe still want to support auto-updates, but we want to have the logic of checking for updates in a separate operator. This decouples the package reconciliation from the auto update aspect, and also it's easier to turn off this feature globally by shutting down this operator/deployment. \r\n\r\nAt the bootstrapping process, the user should be asked whether the auto-update-operator should be installed (default yes).\r\n\r\nAs a consequence, this means that all packages must have `Spec.Version` set at all times (see #341). The new controller will only check if an update is available, and then patch the version field, such that the update is also more transparent to the user. \r\n\r\nAs always, documentation should be updated. \r\n\r\n**Additional context**\r\n* This idea originated when implementing https://github.com/glasskube/glasskube/issues/311, where we decided to do auto-updates in a different way (i.e. Packages always need to have Spec.Version set.)\r\n* Also see #341\r\n* In GitOps installations this controller would not be used, as instead the package versions will be set in a git repository. For this we created #339 for a later milestone. ",
        "component: cli": true,
        "component: package-operator": true,
        "component: ui": true,
        "enhancement": true,
        "title": "Separate controller for automatic updates"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nSome applications (e.g. `argo-cd`) require [resources being applied to a specific namespace](https://argo-cd.readthedocs.io/en/stable/getting_started/#1-install-argo-cd).\r\n\r\n**Describe the solution you'd like**\r\nExtend `PlainManifest` with an namespace attribute. We can then even check if this namespace exists, before applying a resource. In addition we need patch objects of a `PlainManifest` with this namespace if no namespace is already present.\r\n\r\n**Describe alternatives you've considered**\r\nUsing the `defaultNamespace` of the `PackageManifest` for all `PlainManifests`, similar to how `FluxHelmAdapter` works.\r\n\r\n**Additional context**\r\nArgoCD works fine after manually patching the namespace of resources in the `reconcilePlainManifest` loop.\r\n",
        "component: package-operator": true,
        "enhancement": true,
        "title": "Namespace support for plain manifests"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nIt is not possible to determine which package is currently installed via the UI.\r\n\r\n**Describe the solution you'd like**\r\n- Similar to the `list`  command the installed version of a package should be displayed on the overview and detail page.\r\n- On the detail page also display the latestVersion.\r\n- If an update is available display the update path e.g. `v0.0.1` -> `v0.0.2`\r\n\r\n**Describe alternatives you've considered**\r\nAlso always display the latest version.\r\n",
        "component: ui": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Display installed version of a package in the UI"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nIf a new version of a package is installed than the `latestVersion` defined in the `package.yaml` the update warning gets displayed, but this is incorrect.\r\n\r\n**Describe the solution you'd like**\r\nBe aware of semantic versioning and only display the warning if applicable.\r\n\r\n**Describe alternatives you've considered**\r\nAn alternative warning / note can be displayed if a newer version is installed.\r\n\r\n**Additional context**\r\nRelated to: https://github.com/glasskube/glasskube/issues/308\r\nDepends on: https://github.com/glasskube/glasskube/issues/311 \r\n",
        "component: cli": true,
        "component: client": true,
        "component: ui": true,
        "enhancement": true,
        "needs-triage": true,
        "title": "Don't display outdated warning if a new version of a package is installed than the latest version"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nUsing cert-manager.io as an alternative to the `keptn-certifcate-operator` requires the manual creation of certificates as described in the [official keptn documentation](https://keptn.sh/stable/docs/installation/configuration/cert-manager/).\r\n\r\n\r\n**Describe the solution you'd like**\r\nAllow the possibility to inject local manifests which can be stored next to the package manifest file in addition to manifests hosted on GitHub.\r\n\r\nIn the case of `keptn` these manifests need to be created before the `HelmRelease` creation, else the installation will not succeed.\r\n\r\n**Describe alternatives you've considered**\r\nInstead of using `localManifests` we could have used `manifestUrls` and host them in our package repository and make sure manifests and helm releases can get installed together.\r\n\r\n**Additional context**\r\nThis feature blocks: https://github.com/glasskube/packages/pull/32 and is required for the `keptn` installation guide.\r\n",
        "component: package-operator": true,
        "enhancement": true,
        "title": "Support additional manifests"
    },
    {
        "body": "It is not allowed to set a version on a `Package`, that is not compatible with versions that dependent packages require. This should be implemented as webhook. ",
        "component: package-operator": true,
        "enhancement": true,
        "title": "Validate Package Updates via Webhook"
    },
    {
        "body": "Given `P -> D`, but an update of `P` removes the dependency on `D`, `D` should be removed if it is not needed by any other package and if it has not been installed manually (and has not been \"made\" manually, see #315 ).\r\n\r\nTBD",
        "component: package-operator": true,
        "enhancement": true,
        "title": "Prune unused dependencies after package update"
    },
    {
        "body": "Document how dependency management works. ",
        "documentation": true,
        "title": "Document Dependency Management"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nA user might want to install a package `X` that already exists, but only because it is a dependency of another package `P`. If this other package `P` is removed, then `X` is also removed, which the user might want to prevent by installing `X` manually before removing `P`. \r\n\r\n**Describe the solution you'd like**\r\nInstalling such a package should ask the user if they want to \"mark as explicit installation\" or something like that. Implementation-wise this means that the owner references of the package need to be removed. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\nRelated #430 \r\n",
        "component: cli": true,
        "component: client": true,
        "component: ui": true,
        "enhancement": true,
        "needs-triage": true,
        "title": "Automatically installed packages can become manually installed packages"
    },
    {
        "body": "The package dependency graph must not have cycles. Scout should prohibit such cycles from being submitted to the repository. ",
        "enhancement": true,
        "title": "Prohibit dependency cycles in package repository"
    },
    {
        "body": "Follow-Up of #111 – the manifest should support dependent packages in version ranges following semantic versioning. ",
        "component: client": true,
        "component: package-operator": true,
        "enhancement": true,
        "title": "Support versions for dependent packages"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nCurrently versions are sorted ascending in the UI version dropdown.\r\n\r\nSee:\r\n![image](https://github.com/glasskube/glasskube/assets/3041752/2ade63e2-6c94-4e6e-b87e-a30708284a99)\r\n\r\n\r\n**Describe the solution you'd like**\r\nThe latest version should be on top of the list and other releases should be sorted [semver](https://semver.org/) DESC.\r\n\r\n**Additional context**\r\nCurrently blocked by #311\r\n",
        "component: ui": true,
        "enhancement": true,
        "title": "Sort package versions DESC in UI"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nGlasskube packages can also directly applied to the cluster using the GitOps approach. This is also often requested, but not yet documented on our website.\r\n\r\n**Describe the solution you'd like**\r\nAdd a new section on how to install packages directly via the custom resource.\r\n\r\n**Additional context**\r\nWe can also evaluate if [`glasskube/scout`](https://github.com/glasskube/scout) or [`renovate`](https://github.com/renovatebot/renovate/) could be supported for package manifest upgrades.",
        "documentation": true,
        "enhancement": true,
        "title": "Add documentation on how to use Glasskube using the GitOps approach with ArgoCD or Flux"
    },
    {
        "body": "It is assumed that port 3000 can be used in the forwarding. In my case, however, a Docusaurus process is already running on port 3000. An error should occur at this point or another port should be used. Instead, the browser was simply opened on port 3000 (where Docusaurus was running)\r\n\r\n```\r\nui\t |I| Forwarding from 127.0.0.1:3000 -> 80\r\n```",
        "enhancement": true,
        "needs-triage": true,
        "title": "Check if port 3000 is already in use"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nIf the latest newer version of the package operator is installed in the Kubernetes cluster the `bootstrap` command should just get executed, which will lead to a breaking change.\r\n\r\n**Describe the solution you'd like**\r\nAdd a confirmation input [y/N] and ask the user if he is sure that we wants to downgrade the package-operator and potentially break the system.\r\n\r\n**Describe alternatives you've considered**\r\nCompletely disallow it.\r\n\r\n**Additional context**\r\nThis ticket is related to: #205\r\nIt is still possible install a specific manifest via the `--url`  flag. \r\n",
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Prevent accidental bootstrapping of an older package-operator version"
    },
    {
        "body": "**Describe the bug**\r\nDuring package uninstall the detail page of a package is blank\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Open the UI with `glasskube serve`\r\n2. Uninstall a package\r\n3. Reload the detail page\r\n4. See error\r\n\r\n**Expected behavior**\r\nEither a message should be shown or the user should get redirected to the overview page.\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: v1.28.3\r\n - Provider: minikube\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: v0.0.3\r\n - CLI version: v0.0.3\r\n\r\n**Additional context**\r\nFollowing errors are printed in the logs:\r\n\r\n```\r\nAn error occurred fetching package details of cyclops: \r\npackageinfos.packages.glasskube.dev \"cyclops--v0.0.1-alpha.14--1\" not found\r\n```\r\n",
        "bug": true,
        "component: ui": true,
        "title": "Package detail page is blank if a package gets currently uninstalled"
    },
    {
        "body": "**Describe the bug**\r\nWe don't check if a pod is ready to accept connections before we initiate the port-forward.\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Install a package that has an entry-point (e.g. kubernetes-dashboard)\r\n2. Immediately click on the Open button. \r\n3. See error\r\n\r\n**Expected behavior**\r\nThe port-forward should only be initiated if the pod is ready and wait until the pod gets ready for some time (e.g. 5 seconds), else the port-forward should not be initiated and will be initiated by the next attempt.\r\n\r\n**Screenshots**\r\nIf applicable, add screenshots to help explain your problem.\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: Kubernetes\r\n - Version: v1.28.3\r\n - Provider: minikube\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: v0.0.3\r\n - CLI version: v0.0.3\r\n\r\n**Additional context**\r\n\r\nCommand line logs:\r\n\r\n```\r\nglasskube UI is available at http://localhost:8580\r\nInstalling kubernetes-dashboard...\r\n\t |I| Forwarding from 127.0.0.1:8443 -> 8443\r\n\t |I| Forwarding from [::1]:8443 -> 8443\r\n\t |I| Handling connection for 8443\r\nE0227 16:13:58.327794  511974 portforward.go:409] an error occurred forwarding 8443 -> 8443: error forwarding port 8443 to pod 19fc729545d02f7843941851518089c54ffc826361cb9d6d627b5bcfec9d5269, uid : exit status 1: 2024/02/27 15:13:58 socat[45310] E connect(5, AF=2 127.0.0.1:8443, 16): Connection refused\r\n```\r\n\r\n",
        "bug": true,
        "help wanted": true,
        "title": "Package `open` can fail if target pod is not yet ready to accept connections"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThe command does not require a valid kubeconfig or bootstrapped Glasskube at all – instead it can always show the details of any package.\r\n\r\n**Describe the solution you'd like**\r\nDo not require bootstrap and kubeconfig for the `glasskube describe` command.\r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\n\r\n",
        "component: cli": true,
        "enhancement": true,
        "title": "`glasskube describe` should work without kubeconfig",
        "wontfix": true
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThe user doesn't see which entrypoints an installed package has.\r\n\r\n**Describe the solution you'd like**\r\nShow the entrypoints of the installed manifest and the hint that these can be opened with `glasskube open`.\r\nIn the describe command, the installed manifest is already being used to display some information. The goal of this ticket is to also display a list of entrypoints, which are stored in the manifest. \r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\n",
        "component: cli": true,
        "enhancement": true,
        "help wanted": true,
        "needs-triage": true,
        "title": "Show entrypoints in `glasskube describe`"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\n`glasskube describe` command and the package detail page do not show yet whether a package is marked for auto updates.\r\n\r\n**Describe the solution you'd like**\r\nShow whether auto updates are enabled at a package or not. This should be done for both CLI (ls and describe command) and UI (package detail page).\r\n\r\nPackages are marked for auto updates if they have a label `packages.glasskube.dev/auto-update` with value `true`.\r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\nRef #338 #341 \r\n",
        "component: cli": true,
        "component: ui": true,
        "enhancement": true,
        "help wanted": true,
        "title": "Show whether a package is auto-updated"
    },
    {
        "body": "When updating packages, the UI currently creates a transaction for showing the outdated packages and another transaction when applying the updates. \r\n\r\nIn an edge case where a package is updated between the time the dialog is opened and the time the confirm button is pressed, another version than the one the user has agreed to will be installed. \r\n\r\nThis could be mitigated by using the same transaction for both but it is not so straight forward, since multiple connected clients doing the same thing should be (however unlikely, given our use-case) considered and handled correctly. ",
        "component: ui": true,
        "enhancement": true,
        "help wanted": true,
        "title": "Reuse the transaction from the update dialog when applying updates via UI"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWe request some resources of the package repository quite often, these could be cached. In one case this has been implemented already, see here: https://github.com/glasskube/glasskube/pull/286#discussion_r1502544043 . But this served just as a temporary solution, and we want a solution that is easier to re-use for other repo caching purposes too. \r\n\r\n**Describe the solution you'd like**\r\n* Research caching solutions and libraries\r\n* Implement caching for queries to the package repo for CLI commands and package operator.\r\n\r\n**Describe alternatives you've considered**\r\n\r\n**Additional context**\r\n",
        "component: client": true,
        "enhancement": true,
        "go": true,
        "needs-triage": true,
        "title": "Persistent Repo Client Cache"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThe `update` command in the CLI supports updating all packages at once, but the UI does not.\r\n\r\n**Describe the solution you'd like**\r\nSupport Update-All via UI.\r\n\r\n**Describe alternatives you've considered**\r\n\r\n\r\n**Additional context**\r\nRelated #269 \r\n",
        "component: ui": true,
        "enhancement": true,
        "title": "Update-All via UI"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\n`pkg/bootstrap/validate.go:IsBootstrapped` function checks whether the two necessary custom resource definitions are available in the cluster. The `crdExists` function is called two times in sequence, but this could easily be done in parallel instead.\r\n\r\n**Describe the solution you'd like**\r\nCheck the two CRDs in parallel. ",
        "component: client": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Parallelize `IsBootstrapped` function"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThe install command does not show the current kube context to the user. \r\n\r\n**Describe the solution you'd like**\r\nLike in the uninstall command, there should be a prompt to ask the user whether they really want to install the given package to the given cluster. The prompt should be \"[package] will be installed into your cluster ([context-name]). Are you sure? (y/N)\"\r\n\r\n**Describe alternatives you've considered**\r\nNone\r\n\r\n**Additional context**\r\nAlso see #270 \r\n",
        "component: cli": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Show current context in install command"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nThe uninstall command does not show the current kube context to the user. \r\n\r\n**Describe the solution you'd like**\r\nAt the prompt \"... Are you sure? (y/N)\" there should be an additional hint about which cluster is being used. The prompt should be \"[package] will be removed from your cluster ([context-name]). Are you sure? (y/N)\"\r\n\r\n**Describe alternatives you've considered**\r\nNone\r\n\r\n**Additional context**\r\nThe name of the current context is available from the raw config of the context of the command (`client.RawConfigFromContext(cmd.Context())`). Of this raw config, the `CurrentContext` should be used.\r\n",
        "component: cli": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Show current context in uninstall command"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nUsers cannot install a praticular version of a package via UI yet.\r\n\r\n**Describe the solution you'd like**\r\n* On click on the install button, a modal should appear, where the user can select whether they want to have the latest version and auto-updates (default enabled), or a specific version. This should happen on both pages where the Install button is present\r\n* When a package is installed in a pinned version, and this version is outdated, the user should see that their version is outdated and have the possibility to update their package too. \r\n\r\n**Describe alternatives you've considered**\r\nOnce we have configuration in place, we need a separate page anyway, but for now an extra page would look too empty and unnecessary. \r\n\r\n**Additional context**\r\nLatest version of a package might need to be persisted in the package repo `index.yaml` – otherwise we would have to select the `versions.yaml` for each package. Probably scout will handle the repo update automatically. ",
        "component: ui": true,
        "enhancement": true,
        "title": "Support package version handling in UI"
    },
    {
        "body": "**Describe the bug**\r\nWhen building the `glasskube` locally with go version of `1.22` it fails and gives the error shown in screenshot below\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Clone the repo\r\n2. Run `make`\r\n3. See error\r\n\r\n**Expected behavior**\r\n`glasskube` should support the latest stable go version `1.22`\r\n\r\n**Screenshots**\r\nIf applicable, add screenshots to help explain your problem.\r\n![Screenshot from 2024-02-17 20-07-56](https://github.com/glasskube/glasskube/assets/75031769/5f312161-506f-4433-a98f-8d0d0d3b3f28)\r\n\r\n**Additional context**\r\nI downgraded my go version to `1.21.7` and its working fine\r\n",
        "bug": true,
        "needs-triage": true,
        "title": "Error while building `glasskube` locally on go version `1.22`"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nOrigins in https://github.com/glasskube/glasskube/pull/260#issuecomment-1948288228 - The user might want to have a hint in to which cluster the UI is \"connected\".\r\n\r\n**Describe the solution you'd like**\r\ncurrent context name should appear in the navbar\r\n\r\n**Describe alternatives you've considered**\r\nNone\r\n\r\n**Additional context**\r\nRelated issues #270 #271 \r\nWe already show the current context on the bootstrap page, see #123 ",
        "component: ui": true,
        "enhancement": true,
        "help wanted": true,
        "title": "Show current context on the UI in Navbar"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nCurrently the generated schema files must be copied manually between repositories. \r\n\r\n\r\n**Describe the solution you'd like**\r\nWe should make them publicly available via our website: e.g. `https://glasskube.dev/schema(s)?/package/schema.json` \r\n\r\n**Additional context**\r\nSlightly related to: https://github.com/glasskube/glasskube/pull/256",
        "enhancement": true,
        "title": "Expose schema files via our website"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nA version command comes in handy to get the version of all glasskube components\r\n\r\n**Describe the solution you'd like**\r\nSimilar to [flux version command](https://github.com/fluxcd/flux2/blob/main/cmd/flux/version.go#L157):\r\n\r\n```shell\r\n$ flux version\r\nflux: v2.2.3\r\ndistribution: flux-v2.2.3\r\nhelm-controller: v0.37.4\r\nkustomize-controller: v1.2.2\r\nsource-controller: v1.2.4\r\n```\r\n\r\nA glasskube version command could look like\r\n\r\n```shell\r\n$ glasskube version\r\nglasskube: v0.0.3\r\npackage-operator: v0.0.2\r\n```\r\n\r\nIf the glasskube deployment could not be found an error message should be printed:\r\n\r\n> ✗ no deployments found in the glasskube-system namespace\r\n\r\n**Additional context**\r\nAs linked above flux parses image name and tag and prints it in a list. We could to the same which would result in the needed result.  Also the `glasskube -v` command does not need to change.\r\n\r\nThis issue is related to #210 and can help #205",
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Add `version` command to glasskube"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nPackage Maintainers cannot format the long description of their package yet - anything in the long description will just be printed as one long text.\r\n\r\n**Describe the solution you'd like**\r\nWe want to support markdown formatting in the long description. This has to be done on both UI (package detail page) and CLI (`describe` command)\r\n\r\n**Describe alternatives you've considered**\r\nNone\r\n\r\n**Additional context**\r\n* Should only be implemented on top of #172 (UI) and #241 (CLI)\r\n* These packages could be of interest: https://github.com/gomarkdown/markdown, https://github.com/yuin/goldmark, further research to be done\r\n",
        "component: cli": true,
        "component: ui": true,
        "enhancement": true,
        "needs-triage": true,
        "title": "Markdown Support in Package Long Description"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nOn the UI, when uninstalling a package, we immediately show \"Install\" again, no matter how long the uninstallation takes. When clicking install again afterwards, the system can run into errors because the package has not been properly uninstalled yet.\r\n\r\n**Describe the solution you'd like**\r\nThe UI should show \"Pending\" or something similar, until the uninstallation is done. This depends on the blocking uninstall we should get from issues #133 / #168.\r\n\r\n**Describe alternatives you've considered**\r\nNone\r\n\r\n**Additional context**\r\nDepends on #133 / #168.\r\n",
        "component: ui": true,
        "enhancement": true,
        "title": "Show Pending status during uninstallation on UI"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWe are working on the package detail page on the UI (#172 ), so there should be an equivalent command for the CLI to show all relevant package details. Just like on the UI, this should work for both uninstalled and installed packages, and the status of the package should be shown. \r\n\r\n**Describe the solution you'd like**\r\n`glasskube describe [package-name]` should print the same package details to the console as we show in the UI. \r\n\r\n**Additional context**\r\nDepends on #172 to develop the client functionality that can be used by both layers. \r\n\r\nFor implementing this task, reuse `DescribePackage` from `pkg/describe/describe.go`, which contains all the logic to fetch all the relevant data which should be displayed.",
        "component: cli": true,
        "enhancement": true,
        "help wanted": true,
        "title": "`glasskube describe` command"
    },
    {
        "body": "**Describe the bug**\r\n  I tried setting up glasskube in my local have been getting this error when I run the bootstrap command using the binary .\r\n  \r\n\r\n\r\n\r\n**To Reproduce**\r\nSteps to reproduce the behavior:\r\n1. Clone the project\r\n2. Run the `make` command\r\n3. Go to the `dist` directory\r\n4. Run the command `./glasskube bootstrap`\r\n\r\n**Expected behavior**\r\nBootstrapping should be working as expected\r\n\r\n**Screenshots**\r\n![image](https://github.com/glasskube/glasskube/assets/98258627/6dca4d56-beee-472a-aecf-40f829c022c5)\r\n\r\n**Cluster Info (please complete the following information):**\r\n - Type: kubernetes\r\n - Version: 1.27\r\n - Provider: Minikube\r\n\r\n**Glasskube Info (please complete the following information):**\r\n - Package Operator version: [e.g. v0.0.1]\r\n - CLI version: [output of `glasskube --version`]\r\n\r\n**Additional context**\r\nAdd any other context about the problem here.\r\n",
        "bug": true,
        "help wanted": true,
        "title": "`bootstrap` command not working for development builds"
    },
    {
        "body": "**Describe the bug**\r\n\r\nWhen trying to bootstrap glasskube on MacOS with `darwin/arm64` architecture (Apple Silicon), the `glasskube-controller-manager` won't come up.<br />\r\nInstead, the container `manager` using the `package-operator:v0.0.2` image from this repository crash-loops with the error message below.\r\n\r\n```sh\r\nexec /package-operator: exec format error\r\n```\r\n\r\nThis is probably because the go binary `package-operator` gets built for amd64 only?\r\n\r\n**To Reproduce**\r\n\r\n```sh\r\nbrew install glasskube/tap/glasskube\r\nkind create cluster --name glasskube\r\nglasskube bootstrap\r\nwatch kubectl get deploy -n glasskube-system\r\nkubectl logs deploy/glasskube-controller-manager -n glasskube-system\r\n```\r\n\r\n**Expected behavior**\r\n\r\nProviding multi-arch images would be great for the sakes of being able to test the project locally, running demos, etc. Also, more and more clusters are run on ARM, so having multi-arch images in general wouldn't hurt in the long run.\r\n\r\n**Cluster Info (please complete the following information):**\r\n\r\n - Type: Kubernetes\r\n - Version: v1.29.1\r\n - Provider: kind\r\n\r\n**Glasskube Info (please complete the following information):**\r\n\r\n - Package Operator version: v0.0.2\r\n - CLI version: v0.0.2\r\n",
        "bug": true,
        "needs-triage": true,
        "title": "[Bug]: exec /package-operator: exec format error"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWe could a footer section in our UI displaying the version and also indicating if a new version is available.\r\n\r\n**Describe the solution you'd like**\r\nIt could just be div with a gray small centered text (no boxes, nothing)\r\n\r\n**Describe alternatives you've considered**\r\na bulkier footer.\r\n\r\n**Additional context**\r\nThe GitHub footer actually looks nice\r\nrelated to #210 ",
        "component: ui": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Add footer to the GUI"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWhen you quit the server process or it's unavailable for whatever reason, the UI doesn't inform the user about that. That could lead to the user believing they are up to date and everything works fine, when it's actually disconnected. \r\n\r\n**Describe the solution you'd like**\r\nThe UI could show a warning to the user, something like \"You are disconnected - Please make sure to run the `glasskube serve` command and refresh this page.\". \r\n\r\nMaybe another information/warning makes sense, for when the user has restarted the server and the UI is back online. The message could be \"You have been disconnected for a while - Please make sure to refresh this page to be up to date.\". \r\n\r\n**Describe alternatives you've considered**\r\nNone so far.\r\n\r\n**Additional context**\r\nOnline/Offline detection has to be done in JS on the client. There are htmx-events for that: https://htmx.org/extensions/web-sockets/#events. \r\n\r\nIn the long term, when we have multi-user support and stream updates from the cluster into the client as well, we could enhance this indicator to show whether the server is properly connected to the cluster too.",
        "component: ui": true,
        "enhancement": true,
        "needs-triage": true,
        "title": "WebSocket Connection Indicator in UI"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nI would like to use glasskube together with ArgoCD.\r\n\r\n**Describe the solution you'd like**\r\nInstead glasskube apply manifest, glasskube could apply a single ArgoCD Application and ArgoCD may take care of apply the manifests. ArgoCD als natively supports helm and compared to helm, it can handle CRD upgrades.\r\n\r\nThis is useful to observe and ensure the desired state.\r\n\r\n**Describe alternatives you've considered**\r\nN/A\r\n\r\n**Additional context**\r\nAdd any other context or screenshots about the feature request here.\r\n",
        "enhancement": true,
        "needs-triage": true,
        "title": "ArgoCD Backend"
    },
    {
        "body": "**Package Information**\r\n - Name: Kong\r\n - Source Code: https://github.com/Kong/kong & https://github.com/Kong/gateway-operator-docs\r\n - Website: https://docs.konghq.com/gateway-operator/1.1.x/get-started/konnect/install/\r\n\r\n**Why we should add this package to our registry**\r\nBriefly describe what this package does and why it would be useful to install it via Glasskube\r\n\r\n**If you are an author of this project, let us know**\r\n - [ ] I am an author of this project\r\n",
        "packages": true,
        "title": "Kong"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nCurrently there is no hint that a new version of glasskube got released, so users might miss the latest features of Glasskube.\r\n\r\n**Describe the solution you'd like**\r\n - An internal version util should be created that is able to fetch the latest version from the hour website.\r\n - For the GUI there should be an element in nav bar that hints that a new version is available\r\n - For the CLI we should print a warning that looks something like:\r\n \r\n\r\n>  ```\r\n> $ glasskube ls\r\n>     --------------------------------------------------------------------------------------------------------------- \r\n>                                                                                                                     \r\n>                                             Update available 0.0.1 → 0.0.2                                          \r\n>                                Please update glasskube to the latest version                                     \r\n>\r\n>     --------------------------------------------------------------------------------------------------------------- \r\n> \r\n> NAME                  STATUS         \r\n> cert-manager          Pending          \r\n> cyclops               Not installed    \r\n> ingress-nginx         Not installed    \r\n> keptn                 Ready            \r\n> kubernetes-dashboard  Ready  \r\n> \r\n> ```\r\n\r\n**Describe alternatives you've considered**\r\nWe could host a static file either \r\n\r\n**Additional context**\r\nrelated to https://github.com/glasskube/glasskube/issues/205\r\ndepends on: https://github.com/glasskube/glasskube/pull/209\r\n",
        "component: cli": true,
        "component: client": true,
        "component: ui": true,
        "enhancement": true,
        "help wanted": true,
        "title": "Client is outdated detection "
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nPackage managers like the App Store, Play Store or [Arch User Repository](https://aur.archlinux.org/) provide a possibility to comment or upvote a package.\r\n\r\n**Describe the solution you'd like**\r\nWe could start with a discussion threads for every package on the packages repo which we then could either link to it from the website or the GUI or get these comments via the GitHub API.\r\n\r\n**Additional context**\r\nThis is not something we would start immediately but more a ticket the will get more important in the longrun. \r\n",
        "enhancement": true,
        "title": "Add user feedback to packages"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nWe needed to fix @thschue contribution for [@keptn](https://github.com/keptn) due to the fact that ui is not yet able to display svg images. The svg is not visible in the UI.\r\n\r\n**Describe the solution you'd like**\r\nAlso support `iconUrl`s that link to an svg.\r\n\r\n**Additional context**\r\nOnce we fixed this issue we can revert following commit: https://github.com/glasskube/packages/commit/2037ef97a2a655915b11724d548b2f692fd566b4\r\n",
        "component: ui": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Support svg images via `iconUrl` of package manifest"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nAfter an update of the `glasskube` client the `PackageOperator` doesn't get updated automatically. A user must execute `glasskube bootstrap` to update the `PackageOperator`.\r\n\r\n**Describe the solution you'd like**\r\nSimilar to #196 `glasskube` should not only detect if it wasn't already bootstrapped, but also if the `PackageOperator` matches the client version. If there is a version mismatch a message should be printed in the  after executing any cli command like:\r\n\r\n> Glasskube `PackageOperator` needs to be updated. Please run `glasskube bootstrap` again to Glasskube from `0.0.1` (`PackageOperator` version) to `0.0.2` (client version)\r\n\r\n**Describe alternatives you've considered**\r\nThe server component of Glasskube itself could be a glasskube package and managed via glasskube, so updating Glasskube would look like: `glasskube upgrade glasskube`\r\n\r\n**Additional context**\r\nThis ticket can use the version util of: #254",
        "enhancement": true,
        "help wanted": true,
        "title": "Detect version mismatch between the client and `PackageOperator`"
    },
    {
        "body": "There are multiple ways this could be done:\r\n - `glasskube install package@v1.0.0`\r\n - `glasskube install package --version=v1.0.0`\r\n - … something else?\r\n\r\nWe need to decide. Input welcome!\r\n\r\nWhen no version i specified, the latest version should be installed.",
        "component: cli": true,
        "enhancement": true,
        "title": "Extend `glasskube install` to support installing a particular version of a package ( Version pinning )"
    },
    {
        "body": "`glasskube update` should update all packages installed in the current cluster.\r\n`glasskube update [package...]` should update the specified packages.",
        "component: cli": true,
        "enhancement": true,
        "title": "Add `glasskube update` cmd to update packages"
    },
    {
        "body": "",
        "component: cli": true,
        "enhancement": true,
        "title": "Add `--outdated` flag to `glasskube list` to only shows outdated packages"
    },
    {
        "body": "Example output:\r\n```\r\nNAME        STATUS         VERSION  \r\npackage-a   Ready          v1.0.0 \r\npackage-b   Ready          v1.0.0 (v1.1.0 available)\r\n```",
        "component: cli": true,
        "enhancement": true,
        "title": "Add a column for installed version and update status in `glasskube list` output"
    },
    {
        "body": "Automatic updates can be enabled per package by specifying an empty `Version`.",
        "component: cli": true,
        "component: package-operator": true,
        "component: ui": true,
        "enhancement": true,
        "title": "Implement enabling and disabling automatic updates"
    },
    {
        "body": "See https://github.com/glasskube/glasskube/blob/9a6dbccb6c19f205767dfd395decd658b71c4daa/website/docs/03_components/02_package-operator.md for details.\r\n\r\nThe operator should be able to either install a specific version of a package, or determine the latest version and install that.",
        "enhancement": true,
        "packages": true,
        "title": "Add Repository support for multiple versions of a package"
    },
    {
        "body": "Currently, all packages are always kept at the latest version and there is no way to prevent this. Even though [suspension](https://github.com/glasskube/glasskube/issues/131) is on the roadmap, upgrading should require manual approval by default, with the option to enable automatic updates.\r\n\r\nThis entails the following features:\r\n - [x] #198\r\n - [x] #199\r\n - [x] #200\r\n - [x] #201\r\n - [x] #202\r\n - [x] #203\r\n - [x] #269 \r\n",
        "epic": true,
        "title": "Update Management"
    },
    {
        "body": "**Is your feature request related to a problem? Please describe.**\r\nIf glasskube is not bootstrapped, any CLI command (except for `serve`) shows an error message with the command that the user needs to execute manually.\r\n\r\n**Describe the solution you'd like**\r\nIn such a case, it would be easier for the user when the CLI command asks the user whether glasskube should be bootstrapped, along with the information that it is not bootstrapped yet. Something like the message we currently have, and additionally the Yes/No promt (which already exists in `cliutils`) to have the user input his decision.\r\n\r\nThis should be done for all commands that currently only show the error message, but e.g. not for the `serve` command. \r\n\r\n**Additional context**\r\nRelated #123 #149",
        "component: cli": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Automatic Bootstrap in CLI"
    },
    {
        "body": "",
        "epic": true,
        "needs-triage": true,
        "title": "Multi-Repository Support"
    },
    {
        "body": "Apache Kafka is a distributed event store and stream-processing platform. It is an open-source system developed by the Apache Software Foundation written in Java and Scala.",
        "packages": true,
        "title": "Add Apache Kafka package"
    },
    {
        "body": "There are some typos in the \"Features\" section of the README doc. Particularly:\r\n- Keep track of all your packages in one central repository, **which** a [planned](https://glasskube.dev/roadmap/?utm_source=github) feature for custom repositories.\r\n- With a future version, Glasskube will introduce Version Pinning, **gives** you control over your package versions.",
        "title": "Typos in README Doc"
    },
    {
        "body": "The package overview is great, but I'd like to see a more detailed description to the packages and additional information like links to the website or github. I would expect a separate detail page for each package that can be entered from the overview.",
        "component: ui": true,
        "enhancement": true,
        "title": "Show Package Details on separate page"
    },
    {
        "body": "I noticed that when changing something on the server code or in the UI templates, one has to restart the server every time in order for these changes to be applied. That's a bit tedious and bad for developer experience.\r\n\r\nThe dev stack should support hot reload without manual restarts. Otherwise cool project! :-)",
        "component: ui": true,
        "enhancement": true,
        "help wanted": true,
        "title": "Hot reload for UI development"
    },
    {
        "body": "the bootstrap command has nice visual effects in the terminal, it would be good to do something similar for install/uninstall comands to achiever higher consistency amongst the various commands",
        "component: cli": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "add progress bar and spinner in all CLI commands"
    },
    {
        "body": "The package overview page should update itself when a package installation is finished, instead of having the user manually refresh it. ",
        "component: ui": true,
        "enhancement": true,
        "title": "Refresh installation status on the UI automatically"
    },
    {
        "body": "",
        "component: cli": true,
        "component: client": true,
        "component: ui": true,
        "title": "Validate that Glasskube is bootstrapped for CLI commands and UI"
    },
    {
        "body": "When trying to install cert-manager via the UI and CLI, the app installation doesn't finish.\r\n\r\n## Steps to reproduce\r\n* Set up a new cluster (exoscale)\r\n* Install Glasskube (`brew install glasskube/tap/glasskube`)\r\n* Open UI and install cert-manager package or `glasskube install cert-manager`\r\n\r\n## Expected result\r\n* cert-manager gets installed\r\n\r\n## Current result\r\ncert-manager is not installed and fails after some time. It seems like the fqdn source-controller.flux-system.svc.cluster.local. is not reachable\r\n\r\n## Additional Info\r\n![image](https://github.com/glasskube/glasskube/assets/38893055/e4ff9157-a771-4138-85a2-a5e88f80735b)\r\n",
        "bug": true,
        "component: package-operator": true,
        "title": "Bug: Can't install cert-manager"
    },
    {
        "body": "",
        "component: cli": true,
        "component: package-operator": true,
        "component: ui": true,
        "title": "Make repository URL configurable"
    },
    {
        "body": "",
        "component: ui": true,
        "title": "Configure Backups via UI"
    },
    {
        "body": "A command for handling everything related to backups - TBD.",
        "component: cli": true,
        "title": "`glasskube backup` command"
    },
    {
        "body": "Follow-Up of #31: The user should be able to drag-and-drop/upload their kubeconfig file if none was found - the UI will copy the given file into the recommended path and re-initializes itself, such that the user doesn't need to do anything anymore. \r\n\r\nThe user has two choices: \"Only for this session\" or \"Globally\" - that means they can either use the provided kubeconfig only for the current session (i.e. the time the sever process is running), or for all upcoming times until changed (i.e. the kubeconfig file is copied into the recommended home path, possibly affecting other kubernetes-tools too). \r\n\r\nAdditional tasks:\r\n- [ ] refactor to not store the `ctx`, see https://github.com/glasskube/glasskube/pull/260#discussion_r1492332245\r\n\r\nDepends on #126",
        "component: ui": true,
        "title": "Extended Kubeconfig Support Page"
    },
    {
        "body": "",
        "component: package-operator": true,
        "title": "Make errors available as events"
    },
    {
        "body": "- [ ] #60 \r\n- [x] #139 ",
        "epic": true,
        "title": "Error Handling"
    },
    {
        "body": "",
        "packages": true,
        "title": "Support keptn"
    },
    {
        "body": "",
        "packages": true,
        "title": "Support mariadb-operator"
    },
    {
        "body": "",
        "packages": true,
        "title": "Support cloudnative-pg"
    },
    {
        "body": "Support for existing clusters - TBD.",
        "epic": true,
        "title": "Cluster Scan"
    },
    {
        "body": "The CLI should have a consequent default behaviour for all commands that have some long-running operation in the background (like install, uninstall). This default behaviour (either wait or not-wait) should be changeable by the user with a command line flag. \r\n\r\n- [x] install command\r\n- [ ] uninstall command",
        "component: cli": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Add CLI-Flag to not await install/uninstall commands"
    },
    {
        "body": "",
        "epic": true,
        "title": "Support Apps with the Glasskube Apps Operator"
    },
    {
        "body": "Suspend Glasskube - TBD.",
        "epic": true,
        "needs-triage": true,
        "title": "Glasskube Suspension"
    },
    {
        "body": "",
        "title": "Version Pinning"
    },
    {
        "body": "TBD",
        "component: cli": true,
        "component: client": true,
        "component: package-operator": true,
        "component: repo": true,
        "component: ui": true,
        "title": "Handle Secrets"
    },
    {
        "body": "",
        "component: repo": true,
        "packages": true,
        "title": "Add Velero Support"
    },
    {
        "body": "- [ ] #128 \r\n- [ ] #129\r\n- [ ] #141\r\n- [ ] #142",
        "epic": true,
        "title": "Backups"
    },
    {
        "body": "For the MVP we took some shortcuts to get the UI presentable quickly (e.g. no real build steps, full page reloads, duplicating templates and re-usable components, copying the CSS theme and inline style definitions). \r\n\r\nBefore adding too many new features on top of this prototype, we should think about the UI in the long-term from a technology and architecture perspective, taking into account the upcoming features.  \r\n* Do we want to continue with server-side rendered templates? If so, how do we manage more interactive use-cases?\r\n* Do we need application state on the client?\r\n\r\nThis is to be decided and then implemented. ",
        "component: ui": true,
        "title": "UI Revamp - Introduce htmx.org"
    },
    {
        "body": "We already have some colors and progress bars in the bootstrap command - this should also be done for all the other commands we have. ",
        "component: cli": true,
        "duplicate": true,
        "title": "Prettify CLI feedback"
    },
    {
        "body": "- [x] #125 \r\n- [x] #168 \r\n- [x] #133\r\n- [x] #252  \r\n- [x] #140\r\n- [x] #123 \r\n- [x] #196 ",
        "component: cli": true,
        "component: ui": true,
        "epic": true,
        "title": "Extended CLI & UI"
    },
    {
        "body": "We already have the `glasskube bootstrap` command (#68), but we should also give UI users the possibility to bootstrap glasskube. That means, that the UI has to detect whether it already is bootstrapped, and if not, show an information page + a button to run bootstrap. \r\n\r\nRelated #149 #196\r\n\r\nDepends on #126 ",
        "component: ui": true,
        "title": "Bootstrap via UI"
    },
    {
        "body": "The configuration provided for a package (see #118 ) should be validated in the same way on both CLI and UI. ",
        "component: client": true,
        "title": "Reusable package configuration validation"
    },
    {
        "body": "Similar to the CLI (#119 , #120), the UI needs to take user input for package configuration. Also see #122 ",
        "title": "Configure packages via UI"
    },
    {
        "body": "The CLI should provide a way to change the configuration of a package that has already been installed and configured.",
        "component: cli": true,
        "title": "Configure existing packages via CLI"
    },
    {
        "body": "When installing a package with configuration, the CLI should ask the user for input for the package's configuration, defined in #118 . This could be either via command line arguments but also with a loop over the configuration properties where the CLI asks the user to input each value. \r\n\r\nAlso see #122 ",
        "component: cli": true,
        "title": "Configure new packages via CLI"
    },
    {
        "body": "The package repo has to provide a way to make parts of a package configurable. The fields and of which type they can be, needs to be speced first. ",
        "component: package-operator": true,
        "component: repo": true,
        "title": "Support package configuration in operator and repo"
    },
    {
        "body": "When uninstalling a package which has dependent packages, the latter have to be uninstalled as well. ",
        "component: package-operator": true,
        "title": "Uninstall dependent packages"
    },
    {
        "body": "A package that is a dependency of another package should not be uninstallable. This should be implemented via webhook validation. \r\n\r\nNote that checking owner references only will not be sufficient, because a package could have existed before the dependent package has been installed. ",
        "component: package-operator": true,
        "title": "Dependent packages should not be uninstallable"
    },
    {
        "body": "- [x] #118 \r\n- [x] #119\r\n- [x] #120\r\n- [x] #121\r\n- [x] #122\r\n\r\nFollow-Up issues:\r\n- [x] #495 \r\n- [x] #496 ",
        "epic": true,
        "title": "Package Configuration"
    },
    {
        "body": "The UI should provide a way for the user to see which dependencies a package includes. ",
        "component: ui": true,
        "title": "Show package dependencies in UI"
    },
    {
        "body": "The CLI should provide a way for the user to see which dependencies a package includes. ",
        "component: cli": true,
        "title": "Show package dependencies in CLI"
    },
    {
        "body": "Core Functionality:\r\n- [x] #111 \r\n- [x] #117 \r\n- [x] #311 \r\n- [x] #116 \r\n- [x] #322\r\n- [x] #113 \r\n- [x] #114\r\n- [x] #316\r\n- [x] #318 \r\n- [x] #341\r\n- [x] #364 \r\n\r\nExtended Functionality (can be done in a later milestone):\r\n- [x] #363 \r\n- [x] #338 \r\n- [x] #339\r\n- [ ] #344\r\n- [ ] #312\r\n- [ ] #315\r\n- [x] #397 \r\n- [x] #398 \r\n- [ ] #399 \r\n- [ ] #400\r\n- [ ] #430\r\n- [x] #443 ",
        "epic": true,
        "title": "Dependency Management"
    },
    {
        "body": "This needs further specification, but the idea is that every package can have other packages as dependencies. When installing such a package, the dependencies need to be installed too.\r\n\r\n- [ ] Adapt package manifest to support dependencies\r\n- [ ] Implement installation",
        "component: package-operator": true,
        "title": "Install packages with dependencies"
    },
    {
        "body": "",
        "packages": true,
        "title": "Add kubernetes-dashboard package"
    },
    {
        "body": "The UI should provide a link to an application, similar to #108 . Related: #107 ",
        "component: ui": true,
        "title": "Link to a deployed application from the UI"
    },
    {
        "body": "The CLI should support the user in opening a kubernetes application in the browser. \r\n\r\nExample:\r\n\r\n`glasskube open cyclops` should take care of the port-forwarding to get a URL to the application, which is then automatically opened in the browser and printed into the console as a fallback.\r\n\r\nRelated: #107 ",
        "component: cli": true,
        "title": "`glasskube open` command"
    },
    {
        "body": "The client package should provide functionality to make a deployed application available via an URL (e.g. proxy to the kubernetes-dashboard, portforwarding, ...).",
        "component: client": true,
        "title": "Support port-forwarding and proxying to kubernetes applications"
    },
    {
        "body": "Fix the Links for CloudNative PG and Maria DB Operator in: https://glasskube.dev/roadmap#packages-and-apps-schedule\r\n![Bildschirm­foto 2024-01-29 um 17 41 26](https://github.com/glasskube/glasskube/assets/130456438/8c9e41ac-671c-49d6-9f65-79218b758259)\r\n",
        "bug": true,
        "documentation": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Fix 2 Links in Roadmap ",
        "website": true
    },
    {
        "body": "There is a logging-workaround, which should be refactored, see https://github.com/glasskube/glasskube/pull/97#discussion_r1469395170",
        "component: client": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Remove logger dependency from repo client"
    },
    {
        "body": "Our website is currently not optimized for mobile devices.\r\n\r\nSadly https://infima.dev/ doesn't provide nice utilities.",
        "title": "Improve website for mobile devices",
        "website": true
    },
    {
        "body": "Currently, the only method of installing a package is via a HelmManifest. Because not every component requires installing a helm chart, it should also be possible for a package to specify a list of URLs for plain k8s manifests.",
        "component: package-operator": true,
        "component: repo": true,
        "enhancement": true,
        "title": "Add support for arbitrary manifests"
    },
    {
        "body": "If the app fails to bind to port 8085 (the default port), it should prompt the user if it should use a different port. The operating system should assign the listener an arbitrary new port, which can be achieved by trying to listen on port `0`. In order to also be able to retrieve the used port later, `http.ListenAndServe` must be replaced with subsequent calls of `net.Listen` and `http.Serve`.\r\n\r\n```\r\n$ glasskube serve\r\nPort 8580 is already in use.\r\nShould glasskube use a different port? (Y/n)\r\n```\r\n\r\nIf a custom port was specified via `--port`, the app should just `Exit(1)` instead.",
        "component: cli": true,
        "enhancement": true,
        "good first issue": true,
        "title": "Use a different port for \"glasskube serve\" when default port is already in use"
    },
    {
        "body": "Currently, the CLI will listen on port 8580, but there is no way to change this. \r\n\r\nIt should be possible to specify a different port via a command line flag, like so:\r\n\r\n```shell\r\nglasskube serve --port=8581\r\nglasskube serve -p 8581\r\n```",
        "component: cli": true,
        "enhancement": true,
        "good first issue": true,
        "help wanted": true,
        "title": "Changing the port for \"glasskube serve\""
    },
    {
        "body": "We currently use the auto generated side bar in the docs section.\r\n\r\nIt would be nice for our guides to have an auto generated category index page: https://docusaurus.io/docs/sidebar/items#category-link",
        "good first issue": true,
        "help wanted": true,
        "title": "Create category link for website guide section",
        "website": true
    },
    {
        "body": "Docusaurus provides an eslint plugin: https://docusaurus.io/docs/api/misc/@docusaurus/eslint-plugin\r\n\r\nAlso this article describes how to implement eslint for a react / typescript application: https://dev.to/anukr98/setting-up-eslint-with-tsjs-in-your-react-project-in-2023-57o",
        "good first issue": true,
        "help wanted": true,
        "title": "Configure eslint for website",
        "website": true
    },
    {
        "body": "We are using parts of the `controller-runtime` package when setting up the client in the CLI. This adds quite a few MB to the built native binary, which could be reduced if we set up the client/scheme manually, i.e. without the controller-runtime.\r\n\r\nThis might be tricky to avoid though, since in the glasskube client and therefore the CLI, we are relying on the `Package` struct in the `v1alpha1` package, which also uses a controller-runtime `SchemeBuilder` as a global variable. \r\n\r\nWe would probably have to find a way to decouple the `Package` struct definition from the scheme building. ",
        "component: cli": true,
        "title": "Remove controller-runtime dependency from CLI binary",
        "wontfix": true
    },
    {
        "body": "Test releases should be:\r\n\r\nv0.0.1-alpha.1 ... 2 :-) so we can release v0.0.1 on February first.",
        "documentation": true,
        "enhancement": true,
        "title": "Add release-please to automate changelog creation for releases"
    },
    {
        "body": "",
        "title": "Update packages index file via GitHub action"
    },
    {
        "body": "- [ ]  Create basic deployment manifest files for\r\n  - glasskube-system namespace\r\n  - package-controller\r\n- [ ] Deploy Flux (2.2) Helm & Source controller if not present",
        "component: cli": true,
        "component: client": true,
        "documentation": true,
        "title": "glasskube `bootstrap`"
    },
    {
        "body": "All package manifests in https://github.com/glasskube/packages follow the json schema files: https://github.com/glasskube/packages/blob/main/packages/schema.json\r\n\r\nOn all pull requests the package manifests should be validated against the schema.",
        "packages": true,
        "title": "Add schema validation for pull requests in packages repo"
    },
    {
        "body": "Currently, when the installation of a package fails, the install command fails as well, printing an error message to the user.\r\n\r\n* Example 1: `glasskube install nginx-ingress` could fail because of some network error or unavailable package repository. The user would see the error message, unaware that in the background the controllers will try the installation over and over again until the package repository is back up. This is an example of an error, where it could be beneficial for the user, when the command blocks until the error is gone. \r\n* Example 2: `glasskube install non-existent-package` will always fail, and therefore retrying will never work. The user should see the error message again.\r\n\r\nThings that have already been mentioned:\r\n* In any error case, the command line tool could delete the recently created `Package` custom resource to break the reconciliation loop. \r\n* Alternatively we could listen to the \"type\" of error and whether it is resolvable by retrying. \r\n* Once we have an `wait` or `no-wait` option, and the user chooses not to wait, they won't get the end result anyway.\r\n\r\nWe should discuss the best possible error handling strategy here, based on different kind of errors and use cases. ",
        "component: client": true,
        "component: package-operator": true,
        "help wanted": true,
        "title": "Improve error handling for package installation"
    },
    {
        "body": "-  [x] integrate lottie player to reuse our favorite animation\r\n-  [x] Add reactnative.dev inspired star and follow on X buttons\r\n-  [x] add missing features from readme to website\r\n-  [x] add newsletter signup as last section on website\r\n-  [x] add top banner that links to newsletter / github (as soon as it is live)\r\n-  [x] add \"Get Started\" and \"Join the community\" buttons",
        "title": "Website improvements",
        "website": true
    },
    {
        "body": "- [ ] add video above \"Why Glasskube\" \r\n- [ ] add step-by-step onboarding screenshot of UI under \"How to install you first package\"",
        "title": "Update Readme"
    },
    {
        "body": "Related #34",
        "component: ui": true,
        "title": "Show list of installed `Package`s in UI"
    },
    {
        "body": "Related #34 ",
        "component: cli": true,
        "title": "Show list of installed `Package`s in CLI"
    },
    {
        "body": "See: https://docs.brew.sh/Taps & https://goreleaser.com/customization/homebrew/\r\n\r\nrelated to: https://github.com/glasskube/glasskube/issues/38",
        "distribution": true,
        "documentation": true,
        "title": "Create Homebrew tap repository"
    },
    {
        "body": "We want to make all packages available via a glasskube.dev Domain so we can change the real location of the package locations afterwards.\r\n\r\n**PackageSpec:** (#20 )\r\nhttps://packages.dl.glasskube.dev/packages/[package-name]/packageinfo.yaml --> github packages\r\n\r\n**Images:**\r\nhttps://oci.dl.glasskube.dev/glasskube/operator:0.13.0 --> github package registry\r\n\r\n**Charts:** \r\nhttps://charts.dl.glasskube/dev/glasskube-operator-0.10.12.tgz --> github pages\r\n\r\n**Binaries:**\r\nhttps://releases.dl.glasskube.dev/v0.0.1/glasskube_386.apk --> https://github.com/glasskube/glasskube/releases/download/v0.0.1/glasskube_386.apk (release artifacts)\r\n\r\n**Homebrew tap:**\r\nhttps://tap.pgks.glasskube.dev/glasskube.rb --> GitHub raw file  (or pages)\r\n\r\n\r\nuse dl.glasskube.dev\r\n\r\n",
        "distribution": true,
        "documentation": true,
        "title": "Download Proxy"
    },
    {
        "body": "The client needs to support a method to set up the kubernetes client to the API for a given kube config. \r\n\r\nSee for example https://github.com/kubernetes/client-go/blob/master/examples/out-of-cluster-client-configuration/main.go#L58C6-L58C6",
        "component: client": true,
        "title": "Client initialization"
    },
    {
        "body": "",
        "component: client": true,
        "title": "List all installed `Package`s"
    },
    {
        "body": "Related: #30 ",
        "component: ui": true,
        "title": "Uninstall packages via UI"
    },
    {
        "body": "Related #30",
        "component: cli": true,
        "title": "`glasskube uninstall` for CLI"
    },
    {
        "body": "If there is no kubeconfig given, CLI and UI should show a warning to the user, and provide help in how to fix the problem (e.g. \"download the file from XY and copy it into the ~/.kube/ directory\").",
        "component: cli": true,
        "component: ui": true,
        "title": "Support user in how to set up kubeconfig"
    },
    {
        "body": "",
        "component: client": true,
        "title": "Uninstall package"
    },
    {
        "body": "The UI should support the installation of packages, which\r\n- do not require any configuration input by the user\r\n- do not require any dependencies to be installed\r\n\r\nRelated: #23 ",
        "title": "Install trivial packages via the UI"
    },
    {
        "body": "The CLI should support the command `install <package-name>` for packages, which\r\n- do not require any configuration input by the user\r\n- do not require any dependencies to be installed\r\n\r\nRelated: #23 ",
        "component: cli": true,
        "title": "`glasskube install` for trivial `PackageInfo`s"
    },
    {
        "body": "Related: #22 ",
        "component: ui": true,
        "title": "Show list of all available PackageInfos in UI"
    },
    {
        "body": "Related: #22 ",
        "component: cli": true,
        "title": "`glasskube ls`: Show list of all available `PackageInfo`s in CLI"
    },
    {
        "body": "The `serve` command should \r\n- spin up a webserver and block the terminal\r\n- open the locally running web application in the default browser\r\n- display a text in the console where the web app can be accessed (i.e., localhost:1234)",
        "component: cli": true,
        "component: ui": true,
        "title": "Start local webserver with `glasskube serve`"
    },
    {
        "body": "- [x] #25 \r\n- [x] #26\r\n- [x] #27\r\n- [x] #28\r\n- [x] #29\r\n- [x] #31\r\n- [x] #32 \r\n- [x] #33\r\n- [x] #41 \r\n- [x] #42",
        "component: cli": true,
        "component: ui": true,
        "epic": true,
        "title": "Simple CLI & UI"
    },
    {
        "body": "The client library should provide a method to install simple packages (e.g. `cert-manager`), which \r\n- do not require any configuration input by the user\r\n- do not require any dependencies to be installed",
        "component: client": true,
        "title": "Install trivial package"
    },
    {
        "body": "The client library should provide a method to list all available `PackageInfo`s for a predefined package repository. ",
        "component: client": true,
        "enhancement": true,
        "title": "List all available `PackageInfo`s"
    },
    {
        "body": "",
        "component: repo": true,
        "invalid": true,
        "title": "Package API Endpoint"
    },
    {
        "body": "https://repo.pgks.glasskube.dev/packages/[package-name]/packageinfo.yaml",
        "title": "Create and document URL endpoint"
    },
    {
        "body": "Following format for the package repo:\r\n\r\n```\r\nglasskube/packages/\r\n├─ packages/\r\n│  ├─ ingress-nginx/\r\n│  │  ├─ packageinfo.yaml\r\n│  ├─ kubernetes-dashboard/\r\n│  │  ├─ packageinfo.yaml\r\n├─ README.md\r\n```\r\n\r\n\r\n",
        "title": "Package repository"
    },
    {
        "body": "Naming suggestion: `glasskube/packages`\r\n\r\nRelated: https://github.com/glasskube/charts.glasskube.eu/issues/1",
        "title": "Create a GitHub repository"
    },
    {
        "body": "- [x] #18\r\n- [x] #19\r\n- [x] #20\r\n- [x] #21",
        "epic": true,
        "title": "Package repository"
    },
    {
        "body": "- [x] #35\r\n- [x] #22 \r\n- [x] #23\r\n- [x] #30\r\n- [x] #34 ",
        "component: client": true,
        "epic": true,
        "title": "Client Operations"
    },
    {
        "body": "When reconciling a `PackageInfo`, the `PackageInfoController` should pull the package's spec from the package repository only if the time elapsed since the `PackageInfo`'s last update date is greater than a configurable duration.",
        "component: package-operator": true,
        "enhancement": true,
        "title": "Implement PackageInfoController regularly checks Package Repository for updates"
    },
    {
        "body": "When a `PackageInfo`'s status has changed, the PackageController should ensure that the package spec is applied to the server, watch the resulting resources status and update the `Package`'s status accordingly.\r\n\r\nAs a first step, only helm releases must be supported. \r\n\r\nIt should be relatively easy to swap out the underlying helm controller implementation.",
        "component: package-operator": true,
        "enhancement": true,
        "title": "Implement PackageController applies resources if `PackageInfo` is ready"
    },
    {
        "body": "When reconciling a `PackageInfo`, the `PackageInfoController` should pull the specified package from the repository and update the `PackageInfo`'s status fields accordingly.",
        "component: package-operator": true,
        "enhancement": true,
        "title": "Implement PackageInfoController pulls Package Spec from Package Repository"
    },
    {
        "body": "When reconciling a `Package` the `PackageController` should ensure that a `PackageInfo` exists for the package and add the `Package` to the `PackageInfo`'s owner references.",
        "component: package-operator": true,
        "enhancement": true,
        "title": "Implement PackageController checks `PackageInfo` and creates it if necessary"
    },
    {
        "body": "The Package Spec is the information pulled by the PackageInfoController from the Package Repository and represents everything the `PackageController` needs to know in order to install a package.\r\n\r\nA Package Spec contains at least the following information:\r\n- installation type (helm/manifest)\r\n- installation type dependent info (helm repo/chart name, etc.)\r\n- entrypoint for the `open` command of the cli\r\n- version\r\n\r\nThe following aspects needs to be designed/specified:\r\n- Format (YAML, JSON, gzip?)\r\n- Field names and types",
        "component: package-operator": true,
        "enhancement": true,
        "title": "Package Manifest Design"
    },
    {
        "body": "A `Package` represents the intent to install a component in the cluster. \r\n\r\n`Package` is implemented as a Custom Resource Definition (CRD).\r\n\r\nA `Package`'s spec needs the following information:\r\n- package name\r\n- package repository url (optional)\r\n\r\nA `Package`'s status needs the following information:\r\n- conditions (pending, failed, ready, etc.)\r\n",
        "component: package-operator": true,
        "enhancement": true,
        "title": "`Package` CRD Design & Implementation"
    },
    {
        "body": "A `PackageInfo` serves two purposes:\r\n1. A way to tell the PackageInfoController to pull a package's specification from a repository\r\n2. A way for the PackageInfoController to store a snapshot of a package's specification, ready for others to consume\r\n\r\n`PackageInfo` is implemented as a Custom Resource Definition (CRD). \r\n\r\nA `PackageInfo`'s `spec` needs at least the following information:\r\n- package name (needed for lookup)\r\n- package source repository (optional, default is the primary repository)\r\n\r\nA `PackageInfo`'s `status` needs the following information:\r\n- conditions (failed, ready, pending, etc.)\r\n- package spec\r\n- last pulled date",
        "component: package-operator": true,
        "enhancement": true,
        "title": "`PackageInfo` CRD Design & Implementation"
    },
    {
        "body": "- [x] Create approximate architecture design\r\n- [x] #9\r\n- [x] #10\r\n- [x] #11\r\n- [x] #12\r\n- [x] #13\r\n- [x] #14\r\n- [x] #15",
        "component: package-operator": true,
        "epic": true,
        "title": "Package Operator - Initial Implementation"
    },
    {
        "body": "- [x] Create a visual appealing README.md\r\n- [x] Create templates\r\n- [x] Create code of conduct\r\n- [x] Create a security policy",
        "title": "Repository best practices"
    },
    {
        "body": "This issue lists Renovate updates and detected dependencies. Read the [Dependency Dashboard](https://docs.renovatebot.com/key-concepts/dashboard/) docs to learn more.\n\n## Open\n\nThese updates have all been created already. Click a checkbox below to force a retry/rebase of any.\n\n - [ ] <!-- rebase-branch=renovate/github.com-yuin-goldmark-1.x -->[fix(deps): update module github.com/yuin/goldmark to v1.7.8](../pull/1344)\n\n## Ignored or Blocked\n\nThese are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.\n\n - [ ] <!-- recreate-branch=renovate/eslint-9.x -->[chore(deps): update dependency @types/eslint to v9](../pull/1031)\n - [ ] <!-- recreate-branch=renovate/major-eslint-monorepo -->[chore(deps): update dependency eslint to v9](../pull/889)\n\n## Detected dependencies\n\n<details><summary>dockerfile</summary>\n<blockquote>\n\n<details><summary>Dockerfile</summary>\n\n - `golang 1.23`\n\n</details>\n\n<details><summary>glasskube.Dockerfile</summary>\n\n\n</details>\n\n<details><summary>package-operator.Dockerfile</summary>\n\n\n</details>\n\n</blockquote>\n</details>\n\n<details><summary>github-actions</summary>\n<blockquote>\n\n<details><summary>.github/workflows/build.yaml</summary>\n\n - `actions/checkout v4@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871`\n - `actions/setup-go v5@0a12ed9d6a96ab950c8f026ed9f722fe0da7ef32`\n - `actions/setup-node v4.0.4@0a44ba7841725637a19e28fa30b79a866c81b0a6`\n - `actions/cache v4.1.2@6849a6489940f00c2f30c0fb92c6274307ccb58a`\n - `actions/upload-artifact v4.4.3@b4b15b8c7c6ac21ea08fcf65892d2ee8f75cf882`\n\n</details>\n\n<details><summary>.github/workflows/commit-lint.yaml</summary>\n\n - `actions/checkout v4@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871`\n - `actions/setup-node v4.0.4@0a44ba7841725637a19e28fa30b79a866c81b0a6`\n\n</details>\n\n<details><summary>.github/workflows/release.yaml</summary>\n\n - `actions/checkout v4@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871`\n - `googleapis/release-please-action v4.1.3@7987652d64b4581673a76e33ad5e98e3dd56832f`\n - `actions/checkout v4@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871`\n - `docker/login-action v3@9780b0c442fbb1117ed29e0efdff1e18412f7567`\n - `docker/setup-qemu-action v3`\n - `actions/setup-go v5@0a12ed9d6a96ab950c8f026ed9f722fe0da7ef32`\n - `actions/setup-node v4.0.4@0a44ba7841725637a19e28fa30b79a866c81b0a6`\n - `azure/setup-kubectl v4@3e0aec4d80787158d308d7b364cb1b702e7feb7f`\n - `goreleaser/goreleaser-action v6@286f3b13b1b49da4ac219696163fb8c1c93e1200`\n\n</details>\n\n<details><summary>.github/workflows/schema.yaml</summary>\n\n - `actions/checkout v4@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871`\n - `cardinalby/schema-validator-action v3`\n\n</details>\n\n<details><summary>.github/workflows/semantic-pr.yaml</summary>\n\n - `amannn/action-semantic-pull-request v5@0723387faaf9b38adef4775cd42cfd5155ed6017`\n\n</details>\n\n<details><summary>.github/workflows/website.yaml</summary>\n\n - `actions/checkout v4@eef61447b9ff4aafe5dcd4e0bbf5d482be7e7871`\n - `actions/setup-node v4@0a44ba7841725637a19e28fa30b79a866c81b0a6`\n - `aws-actions/configure-aws-credentials v4@e3dd6a429d7300a6a4c196c26e071d42e0343502`\n\n</details>\n\n</blockquote>\n</details>\n\n<details><summary>gomod</summary>\n<blockquote>\n\n<details><summary>go.mod</summary>\n\n - `go 1.23.0`\n - `github.com/Masterminds/semver/v3 v3.3.0`\n - `github.com/denisbrodbeck/machineid v1.0.1`\n - `github.com/evanphx/json-patch/v5 v5.9.0`\n - `github.com/fatih/color v1.18.0`\n - `github.com/fluxcd/helm-controller/api v1.1.0`\n - `github.com/fluxcd/source-controller/api v1.4.1`\n - `github.com/fsnotify/fsnotify v1.7.0`\n - `github.com/go-logr/logr v1.4.2`\n - `github.com/google/go-containerregistry v0.20.2`\n - `github.com/gorilla/mux v1.8.1`\n - `github.com/invopop/jsonschema v0.12.0`\n - `github.com/onsi/ginkgo/v2 v2.20.2`\n - `github.com/onsi/gomega v1.34.2`\n - `github.com/posthog/posthog-go v1.2.24`\n - `github.com/schollz/progressbar/v3 v3.16.1`\n - `github.com/spf13/cobra v1.8.1`\n - `github.com/yuin/goldmark v1.7.6`\n - `go.uber.org/multierr v1.11.0`\n - `golang.org/x/term v0.25.0`\n - `k8s.io/api v0.31.1`\n - `k8s.io/apiextensions-apiserver v0.31.1`\n - `k8s.io/apimachinery v0.31.1`\n - `k8s.io/client-go v0.31.1`\n - `k8s.io/klog/v2 v2.130.1`\n - `sigs.k8s.io/controller-runtime v0.19.0`\n - `sigs.k8s.io/kustomize/api v0.18.0`\n - `sigs.k8s.io/kustomize/kyaml v0.18.1`\n - `sigs.k8s.io/yaml v1.4.0`\n\n</details>\n\n</blockquote>\n</details>\n\n<details><summary>kustomize</summary>\n<blockquote>\n\n<details><summary>config/autoupdater/kustomization.yaml</summary>\n\n - `ghcr.io/glasskube/glasskube v0.25.0`\n\n</details>\n\n<details><summary>config/default/kustomization.yaml</summary>\n\n - `ghcr.io/glasskube/package-operator v0.25.0`\n\n</details>\n\n</blockquote>\n</details>\n\n<details><summary>npm</summary>\n<blockquote>\n\n<details><summary>package.json</summary>\n\n - `@glasskube/theme 0.1.2`\n - `bootstrap 5.3.3`\n - `giscus ^1.5.0`\n - `htmx.org 2.0.3`\n - `htmx-ext-sse 2.2.2`\n - `htmx-ext-response-targets 2.0.1`\n - `@commitlint/cli 19.5.0`\n - `@commitlint/config-conventional 19.5.0`\n - `esbuild 0.24.0`\n - `prettier 3.3.3`\n - `prettier-plugin-go-template 0.0.15`\n\n</details>\n\n<details><summary>website/package.json</summary>\n\n - `@docusaurus/core 3.5.2`\n - `@docusaurus/plugin-content-blog ^3.5.2`\n - `@docusaurus/plugin-ideal-image ^3.1.0`\n - `@docusaurus/preset-classic 3.5.2`\n - `@docusaurus/theme-mermaid ^3.1.0`\n - `@fontsource/inter ^5.0.18`\n - `@fontsource/poppins ^5.0.14`\n - `@fortawesome/fontawesome-svg-core ^6.5.1`\n - `@fortawesome/free-brands-svg-icons ^6.5.1`\n - `@fortawesome/free-regular-svg-icons ^6.5.1`\n - `@fortawesome/free-solid-svg-icons ^6.5.1`\n - `@fortawesome/react-fontawesome ^0.2.0`\n - `@getcanary/docusaurus-theme-search-pagefind ^1.0.0`\n - `@getcanary/web ^1.0.0`\n - `@giscus/react ^3.0.0`\n - `@lottiefiles/react-lottie-player ^3.5.3`\n - `@mdx-js/react ^3.0.0`\n - `clsx ^2.0.0`\n - `docusaurus-plugin-matomo 0.0.8`\n - `posthog-docusaurus ^2.0.0`\n - `prism-react-renderer ^2.3.0`\n - `react ^18.0.0`\n - `react-dom ^18.0.0`\n - `react-github-btn ^1.4.0`\n - `typewriter-effect ^2.21.0`\n - `@docusaurus/eslint-plugin ^3.4.0`\n - `@docusaurus/module-type-aliases 3.5.2`\n - `@docusaurus/tsconfig 3.5.2`\n - `@docusaurus/types 3.5.2`\n - `@eslint/js ^9.5.0`\n - `@types/eslint ^8.56.10`\n - `eslint ^8.57.0`\n - `eslint-config-prettier ^9.1.0`\n - `eslint-plugin-import ^2.29.1`\n - `eslint-plugin-prettier ^5.1.3`\n - `eslint-plugin-react ^7.34.3`\n - `globals ^15.6.0`\n - `prettier ^3.3.2`\n - `typescript ~5.6.0`\n - `typescript-eslint ^8.0.0`\n - `node >=18.0`\n\n</details>\n\n</blockquote>\n</details>\n\n---\n\n- [ ] <!-- manual job -->Check this box to trigger a request for Renovate to run again on this repository\n\n",
        "title": "Dependency Dashboard"
    }
]