15:16 <apache3> thanks to everyone in marrakech, I had a great time!

16:00 <reynir> +1

16:05 <maker> hello there

16:07 <maker> I'm still trying to automatize the certificate generation in canopy. I'm at the reasonable point where I can hook up letsencrypt in the tls bootstrap, print out 'dude put this in your dns txt record", wait for letsencrypt to give out the certificate, and then bootstrap the tls server

16:07 <maker> now there's two problems

16:08 <maker> first one is updates, I need to schedule a thread for certificate renewal every three months. Now, is there a decent way of doing this? Do I have to create a thread and put it to sleep for 3 months? that's I time bomb

16:08 <maker> *that's a time bomb

16:08 <reynir> I've considered just restarting the VM every 3 months :v

16:10 <maker> second one is expecting the user to solve the challenge every time is bullshit, it should do that by itself. However, I'm not able to write on the key-value "tls/" since it's read-only and Canopy_store is meant to be for articles so it's a sin to put tls stuff in there

16:11 <maker> passing around this "token" for a few minutes, in order to solve a challenge proposed by the CA, would make the code a mess, plus it means I need to create an http server in order to get a certificate

16:12 <maker> while now http and/or https server are fired at the same time with a decent pattern matching

16:12 <maker> engil: ^^^^

16:27 <haesbaert> hannes: ?

18:09 <hannes> maker: on startup, I'd imagine sth to look into the expiration date of the certificate, and start a Lwt_engine.on_timer to go into letsencrypt mode.

18:10 <hannes> maker: r/w of a key-value store will hopefully happen soon :D

18:11 <hannes> maker: "for a few minutes" -- sounds to me that you would want to (instead of my earlier understanding/thoughts) integrate the dispatch with canopy's and once LE is finished, restart the HTTPS part with the fresh certificate...

18:11 <hannes> (where "restart" is harsh, instead use the new certificate for new connections)

23:12 <dmj`> so, mirage uses travis for CI, how does it perform tests if the container in which the build runs doesn’t have access to a hypervisor

23:15 <hannes> dmj`: travis only tests the build + unit tests for us, no end-to-end testing.

23:16 <hannes> it could work using a qemu on top of travis..

23:18 <dmj`> hannes: ah interesting, so if the xen kernel was loaded into qemu, and then when dom0 loaded, "sudo xl create main.config” was called.. might need to mount disks w/ the unikernels. Many levels of inception going on there

23:20 <hannes> yes, I suspect that's why (at least afaik) nobody does it

23:21 <dmj`> hannes: there’s no way to redirect the xen console output afaik. .. heh yea, the vms on xen would also need access to disks to write test results. Super hairy.

23:36 <dmj`> hannes: can I ask how large the unikernels that mirage creates typically are

23:37 <dmj`> greater than 10MB in size?

23:38 <hannes> ranging from 4 to 13 MB (without any dead code removal), at least those I run