Hi, We had a discussion with Marek yesterday about how we can renew the way we build our templates. For example it would be very much convenient to have sample piece of file like a Dockerfile as an input to generate a VM. This is something I've already experimented and done in other projects. Even if it's very convenient for a building process, it is not in the standard for VMs. My opinion is that we can go further by using for example a more flexible and adopted format with several configuration backends like Vagrant with the use of Vagrantfile.
We see two subjects related to Vagrant:
1) Use a Vagrantfile as an input for what will be inside our templates. We need to adapt
our linux-template-builder + pieces in builder-{rpm,debian,archlinux,gentoo}. Here, it's
currently out of consideration to use pre-built images from somewhere like we would do
with Vagrant or even Docker by pulling external images. We recreate from scratch the
"box" then ship it as usual in a RPM as our current templates.
Of course, we would still support the legacy way somehow but this would be the
occasion to make our template builder maybe less qubes-builder dependent. Also,
it would allow to have a more standalone tool for which any user could benefit
in creating their own templates in place of post applying Salt formulas
directly on Qubes templates which are not all the time user friendly.
2) Share your AppVM!
We are thinking to add a way to create AppVM easily by using Vagranfile with a Qubes integration. A naive approach would be to use StandaloneVM cloned from Qubes templates then doing what's inside the Vagrantfile but this is something we don't want to do at first. We want to use advantage of AppVM and starting for example by: - identify instruction about which Qubes template to use, - identify persistent/non-persistent instructions. Every instructions like installing packages would be triggered into the underlying requested Qubes template then, the others in the AppVM (mostly configuration or local user installation). Thinking again of Salt formulas, we integrate a way of customization which is from my opinion very convenient (not speaking of Ruby syntax ;) ). But, as Vagrant supports Ansible, Salt, etc. as customization configuration, we don't lost our current Salt formulas at all! For those who want to keep them, just put the trigger to needed ones in the Vagrantfile. 3) Create complex Qubes infrastructure: We have several topics where we setup service infrastructure into Qubes (e.g. https://github.com/QubesOS/qubes-infrastructure or https://github.com/fepitre/qubes-mgmt-salt-qubes-server/tree/devel-140320). With a focus on services, currently I'm testing and use in production docker-compose to create services (e.g. https://github.com/fepitre/package-rebuilder). Switching this simple piece of file to more Salt formulas to use service in AppVM is not really something I want to do because it's not as user friendly as docker-compose when updating the services code, restarting, etc. That would be another example where using only a Vagrantfile to handle multiple VMs at once could be a benefit to use Qubes as a "secure services platform". Having a proper Qubes integration, we could think having/using a community hub where we could push/share Vagrantfiles for creating AppVMs/StandaloneVMs from Qubes templates. Once again, only the descriptive instructions would be used and all would be done locally like you would do it currently with Salt formulas. Any feedback is welcomed :) Best regards, Frédéric -- 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 qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/28331179-2235-a71f-16e0-4c49102b126c%40qubes-os.org.
OpenPGP_signature
Description: OpenPGP digital signature
