> > Perhaps the file(s) could then be renamed once completed so that they > aren't processed on subsequent container startups. > I like how it works in Grafana. The Application may work at the same time with dashboards/datasources stored in db and in filesystem. The ones stored on disk can not be edited (there is badge "Provisioned") in the UI. Since these provisioned configs are not saved in db, configs can be uploaded on disk, edited or deleted. Application just monitores the filesystem changes and reloads provisioned dashboards/datasources. . But, at the same time, there is a more agile approach - k8s operators. It is a pod (service) in k8s, which uses API calls to upload/edit/remove configurations in applications. Mentioned Grafana has one. I will describe in short the idea of operators for the ones who don't work with k8s a lot: 1. User deployx configuration manifest (for example connection config in yaml format). 2. Operator discovers this manifest using k8s api-server. 3. Operator converts the yaml manifest into an http API request and sends it to the app. 4. Operator has a reconciliation loop + additionally there are k8s hooks which inform the operator when something changes. If we start to use guacamole and discover we really need such a way of delivering configs, we will consider writing such an extension for k8s for guacamole 😅
сб, 14 сент. 2024 г. в 00:02, Nick Couchman <vn...@apache.org>: > On Fri, Sep 13, 2024 at 10:15 AM Anakien Skywalker <njuhaand...@gmail.com> > wrote: > >> Nick Couchman, >>> >>> * You can set up the database extensions to auto-create users when >>> they are successfully authenticated by another module: >>> https://guacamole.apache.org/doc/gug/jdbc-auth.html#auto-creating-database-users >> >> Have no idea how I missed this 😱 It seems to answer my >> question completely. >> >> I'm not sure exactly what you mean when you say that "connection >>> provisioning is not supported" >>> >> You are correct. I chose the wrong word. I was thinking about (grafana, >> clickhouse postgres)-like provisioning, when the xml (yaml/json) is put in >> a specific directory of a pod and changes are monitored by the application. >> This basically allows git to use the source of config files and easily >> mount them via a common helm mechanism. >> But thank you very much. Indeed REST API and DB operations are pretty >> simple alternative options. GUACAMOLE-926 sounds tempting. >> >> > Ah, yes - this actually might be a good thing for us to think about adding > to the guacamole/guacamole container - instead of using the GUI or REST > API, drop the [JSON|YAML|CSV] file into a directory and have the client > pull in the contents of the file(s). Perhaps the file(s) could then be > renamed once completed so that they aren't processed on subsequent > container startups. > > -Nick > >>
