Dynamic addition of specs post-startup

[xtrasimplicity]

Firstly, thanks for creating such an awesome platform - this looks like it satisfies almost all of my requirements!

One thing I'm looking for, though, is the ability to dynamically add specs post-startup, so that we don't have to manually restart the server to add a new app.

I can see that ProxySpecs and ContainerSpecs (upon which ShinyProxy is based) offer support for this using a POST request, but that it is explicitly unsupported in ShinyProxy. Is there a specific reason for this? Is this something that you'd be open to adding?

ProxySpecs and ContainerSpecs may also be provided at runtime, via the body of a POST request.
Note: ShinyProxy does not allow specs to be provided at runtime. Only specs from the application.yml file are accepted.
Source

My plan is to deploy this on a server and permit specific people within the organisation to register new applications on behalf of their project teams, without me having to take ShinyProxy offline (even for a few seconds) to add a new application. Ideally, this management interface would exist within ShinyProxy, but I'm happy to build my own little dashboard to handle this.

I'm happy to contribute some time toward assisting with the development of this, if required - just wanted to check to see whether there was any specific reason why this is unsupported, and whether you'd be open to having this functionality.

I've had a look around at some of the older tickets and have read that one of the concerns with this is that some of the other server configuration cannot be hot-reloaded, but I wonder whether this could be worked around by adding a dynamic_specs attribute to the application.yml file, so that users can choose whether they want to support dynamic specs or manually-defined (but not necessarily both, if that introduces significant complexity from an architectural perspective)?

e.g.

proxy:
  port: 8080
  ...
  dynamic_specs: true
  specs: # Left blank, if `dynamic_specs` is true.

Thanks so much!

[tverbeke]

Hi @xtrasimplicity This can be achieved using our ShinyProxy operator. A high-level description is offered in https://www.openanalytics.eu/blog/2020/10/12/shinyproxy-2.4.0/ and further documentation is available in its dedicated Github repository

[xtrasimplicity]

Thanks, @tverbeke. I had a quick look, but it seems more Kubernetes centric. Does this work with Docker swarm/engine, as well?

Edit: Also, it looks a bit more complex than what I had in mind. If I were to submit a PR for ShinyProxy which adds support for adding new apps using the admin UI (and persisting such config in a database), would you be open to merging it?

[xtrasimplicity]

Hi @tverbeke, I've had a bit more of a read of ShinyProxy Operator and I think I've got my head around it.

Whilst it would solve most of my issues, it'd be nice to be able to delegate the addition of new apps to specific users who may otherwise not be familiar with editing config files, etc - or in situations where I don't want to grant someone SSH access (in any form, no matter how restricted) to the server running ShinyProxy in order to edit the config file.

For this reason, it'd be great to be able to add new apps using the Admin UI.

Theoretically, and without having heavily reviewed the code, it should be as simple as:

1. Adding the ability to fetch spec definitions from a database (sqlite should be sufficient?), in addition to from the config file.
2. Updating the admin UI to support registering new spec definitions and storing them in the database.

Would you be open to a Pull-request adding such capabilities?

Thanks!

[tverbeke]

Hi @xtrasimplicity, Thanks a lot for thinking along. We are working on a mechanism to delegate addition of new apps, but in a first stage it will probably be driven by a GitOps approach rather than through a user interface.

[xtrasimplicity]

Thanks, @tverbeke. Do you know when the delegation mechanism is likely to be ready? Or can I somehow assist with development of this?

GitOps is useful, but being able to do this from the GUI would be really useful for environments where GitOps isn't really used, too!