Re: [MirageOS-devel] deployment scripts: moving (e.g. mirage-www) away from crunch?

[Justin Cormack <justin@xxxxxxxxxxxxxxxxxxxxx>]

On 3 August 2015 at 15:26, Dave Scott <Dave.Scott@xxxxxxxxxx> wrote:
> I was wondering if we should move away from crunch, and use some other method 
> for static data. Mirage already supports static data

It is certainly useful for some applications not to use RAM.

> - from Irmin
> - from BLOCK devices formatted with FAT
> - from BLOCK devices containing tar-format data (new in Mirage 2.6.0)
>
> 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?)

The second seems preferable where possible; it allows direct mounting
via Irmin if the deployment tree is the Irmin repo, and can also be
served over nfs/9p or other file protocols, and as more tooling
friendly. Generally the first will still need a deployment stage as
the file may need to be copied to a (possibly remote) block device,
and adding a tar stage then is not an issue.

> Thereâs also the issue of how best to handle secret volumes such as those 
> containing keys.

Very deployment specific, and you want this to be out of scope of
build tools as the build process may not have key access.

Justin

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel