@tg-x could you help with answering these questions?
After pasting it out of my editor where it’s been sitting over the weekend, I feel like it’s obvious the “Why SHRUTHI?” section should come before “Provisioning DREAM Software”… What do you think @how?
I moved “Why SHRUTHI”, and added some more to that section.
I would like some more info about how our unikernels should work together, so that I can properly fill out the “Provisioning DREAM Software” section to be more specific to our components. @tg-x could we have a chat?
I also plan to add a short section on what to do after the unikernel has been provisioned, tomorrow.
@pukkamustard @misterfish @natacha @Nemael @arie with that said, I would appreciate any feedback on the current state of the top post. 
1 Like
Yes, I’m going to give a pass about the economic model / incentives and try to provide some less technical context, expanding on the Docker, etc. stuff.
I’m also preparing an email to Mirko et al. for them to review the D1.* and validate the M2.
they should be able to talk to each other over IP, and the message router should also be able to talk to remote nodes on the internet.
we can talk about it today
I don’t have many comments, @dvn, just that, beyond fixing a part on the unikernel split within DREAM, we should probably add something about the economic model, and why not a screencast of setting up unikernels as a demo – since I don’t think it would make any sense to ‘demo’ a unikernel deployment as it would only show the result, not the process.
Maybe other team members have useful comments!
1 Like
We’re thinking alike - I’m working on this
1 Like
Good sell of Unikernels. I usually explain Unikernels by differentiating from Monolithic Kernels (like Linux) and Microkernels. I like the direct explanation.
Nice four bullet points.
What might be nice is to pick up this again (or maybe in another section “How does SHRUTHI help?”).
What are the things that would have to be done manually if one does not use SHRUTHI. What exactly are the things that SHRUTHI does that makes hosting DREAM stuff (or other stuff) easier?
It would also be nice to highlight the extent of SHURTHI and what SHRUTHI expects as given. E.g. SHRUTHI is not a build system. You will need a way to build the Unikernels before SHRUTHI can provision them.
I guess a complete example also solves my point above.
I can compile both server and client (Go makes this easy) and start the server using the configuration given in the top post. 
Is there further documentation on Rhyzome? It was unclear to me what the ImageHost and CloudInit configurations do. Both options are present in the Readme, but not in the top post (good choice of configuration in the top post, btw).
To deploy some unikernels, you must first invent the universe build some unikernels. I guess we need to do more work to prepare DREAM unikernels and document them (Crafting Unikernels). Should the top post use the example mirage-skeleton in order to have a end-to-end running example?
Are there ways planned of encoding this information in a file (e.g. JSON)? This would allow parameters used to start a Unikernel to be checked in to a Git repo.
Related to question above (what does SHRUTHI do): Does Rhyzome restart a Unikernel if it crashes?
I see that there is a rhyzomectl instance list command. What are other planned commands? Will there be a stop command?
Btw, while running the command ./rhyzomectl --server http://127.0.0.1:8080 instance list I get following panic:
2021/05/18 17:28:24 Error fetching instance list from http://127.0.0.1:8080
panic: invalid character 'v' looking for beginning of value
I share this feeling. Great to have this in the considerations!
All in all, looks fantastic. Great work!
I’ll try and get the mirage-skeleton running to have something really running on Rhyzome. Is there something else I could use to easily test it? Maybe something fun from the qemu advent calendar or so?
1 Like
I’ve added the top-post to a new git repo, as a markdown file. Easier for me to work on it this way, and keep track of the edits.
Really nice work, @dvn. And great comments by @pukkamustard.
Which branch should we be on when trying rhyzome? I’m in boot-parameters because I clicked on the readme that’s the default.
I made a rhyzome.conf (and got a message saying it’s being successfully read) but I’m not sure the values are really being used? If I change the bind port it still appears to use 8080.
Doesn’t crash on mine. Maybe it’s because of the branch. Output:
Good point, hopefully we can develop a feeling for this as the months go by and/or work out some back-of-the-envelope intuitions. Could one run a core node on a Raspberry PI for example? If so, how many topics / subscriptions / connected edge nodes?
Aside from the electricity, some other things we could think about: how many unikernels (let’s say, using a small amount of memory), could a modern server concurrently execute using this system? As an order of magnitude estimate. And does each one in this system get a static amount of memory and then crash if it tries to use more, or can it request more (and release it?) ?
1 Like
Since people seem to appreciate the reference to “Jevons Paradox”, I wanted to point out that the addition of that section was all @how → Integrate additions and changes from @hellekin (36c8615c) · Commits · DREAM / SHRUTHI / Documentation and Specs · GitLab
That’s the correct branch for now. I set it as the default branch on the gitlab, so it should go there when you navigate to the project page.
That is odd, and sounds like a bug. I will investigate, thanks.
@pukkamustard you have excellent points, and I will integrate my answers into the next updates to the top post. I think a lot of it will be answered via a more detailed and elaborate installation example.
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
3 Likes
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.
1 Like
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.
1 Like
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.
2 Likes
Please see The Documentation System.
It totally makes sense to document properly.
P.S.: I added the screencast description to the first post.
1 Like