can we make it devan’s
Might I suggest not putting all the parameters in one string, which can lead to annoying backslash/quoting problems, (and in any case using single quotes).
One alternative is to give the option multiple times:
--kernel-parameters --ipv4-gateway
--kernel-parameters 192.168.100.1
--kernel-parameters --ipv4
--kernel-parameters 192.168.100.43/24
--kernel-parameters '` $(delete everything) ! etc'
I’ve added a screencast to the top post. It’s not very readable at that size, so best to look at it here: https://dream.public.cat/uploads/dream/original/1X/1999d51f757b5e183a813205e796e9d66b6f6eaf.gif
I might try to re-render it so the font is larger.
I made a script to generate the content of the screencast, and committed it here: DREAM / SHRUTHI / Screencasts and Demos · GitLab
Font size looks fine to me, maybe a textual description of what the demo is doing might be useful, especially for accessibility. Would the following be useful ?
In this screencast, three steps to the deployment of a unikernel are shown ; the demo first verifies that the rhizome
service is running – it was started with the command ./rhizomesrv
from the Rhizome repository – and then proceeds to build a new HTTPS service unikernel from Mirage examples ; once the sample unikernel is ready – and it only takes seconds on a standard laptop – Rhizome can provision it, passing kernel parameters to declare an IP address and its local network gateway. Faster than it was to build the unikernel, a specific instance is deployed and can now serve its purpose, as demonstrated in the second part of the demo which shows on the left a view from within the unikernel, and on the right the client view querying the HTTPS service.
Cool @dvn.
I like the fullscreen version but then I can’t pause it by clicking on it. Probably a simple html file containing only the full-size gif would solve this.
Thanks much @dvn this is useful, @how 's description is indeed very welcomed.
I feel this release has opened a number of questions about the realities of running unikernels for DREAM.
As I read more about the different controversies around unikernels I feel there is indeed a lot to answer, and we need to document our process as it will be useful in that context.
This is how I imagine things will go in the next months please tell me if it makes sense:
-
First step might be to reference existing projects deploying unikernels and if there are any that use them at the scale that we are thinking about.
-
Next I imagine we will start implementing DROMEDAR and proper testing setup.
I think I can start a topic in the DREAM catcher’s category so we can engage larger then us in this.
Does it makes sense ?
Yes and also on the practical modalities of implementation for new comers, I think one of the argument for unikernel is that, although one needs to understand how to address its system, one does not need to have sysadmin knowledge to set them up.
Please see The Documentation System.
It totally makes sense to document properly.
P.S.: I added the screencast description to the first post.