Akri installation via Glasskube

[jakepage91]

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

Is your feature request related to a way you would like Akri extended? Please describe.
Yes, the extension is around offering an alternative installation method via Glasskube.

Describe the solution you'd like
I have already added Akri support to Glasskube. (no additional work is needed, only for maintainers to test it)

Now Akri users can install Glasskube and configure, install and update Akri via the UI or CLI
CLI command:

glasskube install akri

By running this command, auto-updates will be enabled and every time a new Akri helm chart version is detected it will be applied to you Kubernetes cluster.

Package configuration:
Glasskube enables users to easily define both the containerRuntimeSocket and the useLatestContainers value without having to fiddle with the helm values.yaml file.

Below I will attach screenshots of what the Akri look like on Glasskube.
Additional context
I would love for maintainers to give the installation method a chance and let me know what you think. And after you do I would love to open a PR to add Glasskube as an alternative installation method for Akri.

[kate-goldenring]

Hi @jakepage91 I think we'd want to expose most of the values from the Akri Helm chart. Or, does Glasskube have another strategy for follow up installations of custom resources that could otherwise be scaffolded with Helm charts? the containerRuntimeSocket flag is going to be removed in the next release of Akri and could be omitted.

[jakepage91]

Hey there Kate. So I see that there are quite a few values exposed in the Akri values file. As a general rule, the way we imagine using Glasskube at this early stage isn't so much a 100% coverage of the packages values file since it would be hard to scale and maintain across all packages. At this early stage 1 of Glasskube we are taking more of an opinionated approach and exposing the values that cover a high number of use cases leaving many values set to their defaults. Of course if we were to stop Glasskube development here, this would not be a considerable improvement to the current package management options available. That is why we are currently working on the Glasskube configuration language that would remove the need for a helm template in the backend all together. We have an open discussion here <glasskube/glasskube#1018> on our GitHub, it would be great if you had any ideas here. In the meantime, would it make sense to select a subset of commonly used exposed values that cover a considerable amount of Akri use-cases? If so, send them over to me and I will be happy to add them. I will also remove containerRuntimeSocket. All the best, - Jake El mar, 6 ago 2024 a las 13:52, Kate Goldenring ***@***.***>) escribió:

…

Hi @jakepage91 <https://github.com/jakepage91> I think we'd want to expose most of the values from the Akri Helm chart. Or, does Glasskube have another strategy for follow up installations of custom resources that could otherwise be scaffolded with Helm charts? the containerRuntimeSocket flag is going to be removed in the next release of Akri and could be omitted. — Reply to this email directly, view it on GitHub <#699 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJHWJ3HBNKU3B4JJQYQJ5ADZQDBHPAVCNFSM6AAAAABLDDKQCGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZRGIYTONRZGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jakepage91]

Hey there @kate-goldenring just to continue the conversation. Would it make sense to propose a shortlist of values to expose via Glasskube that are used in a majority of use cases? Once we have the first version of the configuration language we'll be able to expose all values to cover all use cases.