I created an issue to capture the ideas in this thread: https://github.com/mirage/mirage/issues/443
Cheers, Dave > On 10 Aug 2015, at 10:57, Thomas Gazagnaire <[email protected]> wrote: > > Hi, > >> I can think of 2 general approaches: >> >> 1. during the existing build process, build both a kernel and a second >> binary blob containing data which will become a BLOCK device. The deployment >> scripts would simply have to attach the BLOCK devices in the VM >> configuration. >> >> 2. check in the data files into a subdirectory in the deployment tree, and >> make the deployment scripts perform the final conversion (to Irmin, FAT or >> tar). This has the disadvantage that it leaves some of the final ‘linking’ >> to the deployment scripts (which are currently outside the scope of the >> ‘mirage’ tool) but it has the advantage that the individual data files >> should be de-duped by git/Irmin, since their sha1 hashes should match. If >> this final assembly stage gets more complicated, should the ‘mirage’ tool >> gain some extra support for it (mirage configure; mirage build; … later on a >> different host …; mirage deploy?) > > For short-term I actually I quite like 1... it's simpler in a deployment > perspective: you don't have to install and rely on anything on the deployment > host (just set-up the right disk path in the `.xl` configuration file). But > yes, we loose dedup and flexibility so we don't want to stay there forever. > > About `mirage deploy`: I removed recently `mirage run`[1] because it was > impossible to keep it up-to-date with all the deployment backends we wanted > for mirage. I think it make sense instead to have backend-specific deployment > scripts (starting with xl and ec2) without trying too much to make them look > similar. The difficulty is to keep making them work ... As we need this to > deploy mirage.io using xl, I think I'll be happy if we just have a nice > `mirage-deploy-xl` script which takes care of 2. > > Thomas > > [1]: https://github.com/mirage/mirage/issues/348 > > >> >> There’s also the issue of how best to handle secret volumes such as those >> containing keys. >> >> What do you think? >> >> Cheers, >> Dave >> >> >> _______________________________________________ >> MirageOS-devel mailing list >> [email protected] >> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > _______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
