On Monday, 25.05.2015 at 19:41, Andrew Stuart wrote: > > >>The failure of the Xenstore-style configuration was expected, sorry if I > >>didn't make that clear. > It’s ok that’s what I expected. I expected we were going to tackle storage > later. > > I’m guessing you’re thinking two (or more) types of storage as in the ability > to connect to read/write devices such as EBS volumes and also storage as in > the ability to bake in read only static files into the unikernel image, > perhaps as an iso9660. > > Or is there a more direct way to embed files in a rump kernel? I notice > there is an etc directory - is it possible to directly include static files > somehow?
Not currently. As I already wrote, in the "someone should" department, someone needs to do the work to make this happen. It's not a huge amount of work but I already have a long enough backlog on my TODO list :-/ So, currently you'll need at least one block device with a filesystem on it that you can mount. See below. > > >>Can you point me to the script you used to generate the EC2 kernel? I'm > >>sure it's somewhere on the Mirage site but I can't seem to find it. > https://github.com/mirage/mirage/blob/master/scripts/ec2.sh > > It is possible to launch micro instances with some more faffing around. I > didn’t bother - I just launched as m1.small instance types. > > >>I'm assuming that there is a way to modify / generate the PVGRUB > >>configuration used in the image. If so, we can use the commandline (JSON) > based configuration for EC2, and bake the command line parameters for the > unikernel into the image. > > Maybe, not so sure about that. I've read the script, it just generates an image file with the GRUB configuration in it, so it could be done this way, yes. However, I'd still like some more time and input from others to think about whether or not we want to get rid of the existing Xenstore-based configuration mechanism. What I've done for now to get you at least something to try out is made a patch which will let you call the rumprun_config_* and rumprun_deconfig_* functions statically from within the code: https://gist.github.com/mato/757b8adb9d6eb299f53f (I unintentionally set the gist to "secret", it's not. No idea how to make it public after the fact.) To get a build of rumprun-xen with this applied: 1) Download and apply the patch to rumprun. 2) make -C platform/xen 3) Re-link your unikernel. If you look at what the patch does, it just changes the configuration/deconfiguration to be embedded in the code: + rumprun_config_net("0", "inet", "dhcp", NULL, NULL, NULL); + rumprun_config_blk("0", "etfs", "/etc", "cd9660"); and + rumprun_deconfig_net("0", "inet", "dhcp", NULL, NULL, NULL); + rumprun_deconfig_blk("0", "etfs", "/etc", "cd9660"); So, this will get you a single network interface with DHCP and attempt to mount the first Xen block device on /etc with CD9660. > Anything else you would like to set me to work on? I’m happy to dig around > and do general gofer stuff. Try my patch, eg. with nginx or mathopd, you'll need to modify the nginx configuration to expect all your static data somewhere in /etc. That should be enough to serve static files over HTTP. Martin
