Sorry to piggyback on the thread, but I've been meaning to ask this. Have there been any notable usecases of end users using salt to coordinate Qubes VM lifecycles with salt, and orchestra/publish them into services? I imagine something like Joanna/Marek's <https://github.com/QubesOS/qubes-app-linux-pdf-converter> qubes-app-linux-pdf-converter <https://github.com/QubesOS/qubes-app-linux-pdf-converter> which coordinates multiple VMs to produce a stronger security guarantee than a single VM could produce.
I am unfamiliar with the structure of salt formulas and pillars, or whether the end goal of a salt configuration can be to publish some service endpoint (though I'd imagine the answer is yes), nor am I certain the exact use salt has seen in qubes so far (it has been my impression that salt helps compose qubes VMs in a way not fully encouraged for end user, but looking at the documentation that might have simply been my impression given my level of understanding at the time - it certainly seemed intimidating.) What I'm more familiar with is Docker, where most configuration management is done via Docker file, and coordination is done through Docker-Compose declarations. Maybe I can show you guys such a file and see if Salt can do similar tasks? This <https://github.com/haugene/docker-transmission-openvpn/blob/master/docker-compose.yml> Docker-Compose specification defines a pair of containers that run in tandem - one is a container which sets up an openvpn link to a VPN provider and runs a torrent client through that tunnel, and the other container is a reverse proxy server that allows the local user to access the torrent client's web interface. The definitions for the component containers (in qubes they would be VMs) are referenced from a repository of container definitions via the "image" command, while the other commands determine the configuration parameters of the containers - their internal environment variables, ports that are open and the port forwardings for such, the external file resources that will be mounted in the containers, and also things like the behaviors of the containers - for example the the "transmission" container will "restart: always", meaning that if there is an internal error in the container, the execution engine should attempt to restart it, while the "proxy" container's "links: transmission" directive specifies that the transmission container will be visible to the proxy container via the hostname "transmission". All in all it's a very light weight but surprisingly flexible ethod of coordinating apps that are built of multiple units, and I'm wondering if we can do similar declarative definitions of multiple VM systems via salt. A couple motivating usecases that I can think of go as follows: 1. Specifying a proxy VM for a given VM, and optionally injecting a "man in the middle" utility VM which can do things like: - Provide packet/protocol capture and analysis (for example for testing whether a proxy VM leaks) - Provide a TLS termination proxy/mitmproxy 2. Easily define application specific processing pipelines and use them to compose/abstract services that span multiple VMs in a way that - Lets you specify very light, application specific VMs for individual steps - Lets you set up complex life cycles and data flows between these vms - Where all VM configurations are pulled automatically from a repository Anyways, this is all kind of all over the place, and might need to be posed elsewhere, but I'm just wondering whether salt as deployed on qubes can covers these kinds of usecases in a fairly light weight way. Regards, Max On Sunday, March 19, 2017 at 2:31:32 AM UTC-7, Jean-Philippe Ouellet wrote: > > Hello, > > I am not criticizing the choice of salt, I am just curious about why > exactly it was chosen over the alternatives. From the list archives it > appears that it was just suddenly being worked on, and I'd be > interested to know what lead to choosing it instead of > {ansible,chef,puppet,etc.}. I could not find any public discussion on > our list archives evaluating their relative merits. > > Regards, > Jean-Philippe > -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/f23def44-5ae9-4374-8778-545f370fdb4b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
