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

[Dave Scott <Dave.Scott@xxxxxxxxxx>]

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 <thomas@xxxxxxxxxxxxxx> 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
>> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
>> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
> 

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