Hi Daniel,
Sorry for the late reply and thank you for the comments. Please see my answers inline.
Cloud Foundry aside, how does Unik go from receiving some app code to know exactly which kernel features are needed for the application at run time? This is the part that seems most magical to me.
First, Unik is not the one who make that decision, this decision is being done by the tool that build the unikernel and it is different tool for each unikernel type.
For example in IncludeOS, the mechanism used for extracting only what is needed from the operating system, is the one provided by default by modern linkers. Each part of the OS is compiled into an object-file, such as ip4.o, udp.o, pci_device.o etc., which are then combined using ar to form a static library os.a. When a program links with this library, only what’s necessary will automatically be extracted by the linker and end up in the final binary. To facilitate this build process a custom toolchain has been created.
Hope that make sense.
Where is the Unik daemon running - presumably somewhere of the operators choice, mostly likely as a BOSH-deployed job?
Yes, it is the Operators jobs and it will be smart to create BOSH release to UniK - right now the install process is done by running 'make'.
What happens if the Unik daemon dies - is it stateful? Will unikernels continue to run and be manageable?
The unikernels will continue running but will not be managed by UniK until the daemon will be restarted - just like docker.
Does the unikernel image get created at app staging time?
If the image is not pre built it will be built it, otherwise the existence image will be used.
Has there been any discussion about how to strategically implement this alongside Diego, instead of the tactical solution of 'going through' Diego?
I am going to set time with Chip help and we can all discuss it together. I think that clean integration should be done in Garden. But it should be discussed and decided by the community.
I hope that clarify some of your concerns and please feel free to ask me any question.
Thanks,
Idit
On Mar 23, 2017, at 4:32 PM, Daniel Jones <daniel.jones(a)engineerbetter.com> wrote:
Hi Idit,
Thanks for sending out the proposal, and thanks for giving your talk in Santa Clara last year, which I attended and was excited by.
I've read the proposal and heard the talk, but I'll be frank - I still don't get it. That may well be because I'm a simpleton who doesn't know much about kernels, let alone unikernels, but if I don't ask some silly questions I'll probably never know.
Cloud Foundry aside, how does Unik go from receiving some app code to know exactly which kernel features are needed for the application at run time? This is the part that seems most magical to me.
Where is the Unik daemon running - presumably somewhere of the operators choice, mostly likely as a BOSH-deployed job?
What happens if the Unik daemon dies - is it stateful? Will unikernels continue to run and be manageable?
Does the unikernel image get created at app staging time?
Has there been any discussion about how to strategically implement this alongside Diego, instead of the tactical solution of 'going through' Diego?
I'm excited by the promise of unikernels - being able to cut out so much bloat and indirection would be a massive win for efficiency if they usurped containers as a unit of currency. I wonder how much CO2 emission we could avoid by stripping abstraction away, instead of piling it on!
Regards,
Daniel Jones - CTO
+44 (0)79 8000 9153
@DanielJonesEB <https://twitter.com/DanielJonesEB>
EngineerBetter Ltd <http://www.engineerbetter.com/> - UK Cloud Foundry Specialists
On 16 March 2017 at 21:09, Michael Maximilien <mmaximilien(a)gmail.com <mailto:mmaximilien(a)gmail.com>> wrote:
Thanks for this submission Idit and Dell/EMC.
I look forward to comments from community as we work this though the CF-extensions process.
Best.
On Thu, Mar 16, 2017 at 1:25 PM Idit Levine <idit.levine(a)gmail.com <mailto:idit.levine(a)gmail.com>> wrote:
One clarification, we propose it to the CF incubation program.
On Mar 16, 2017, at 3:59 PM, Idit Levine <idit.levine(a)gmail.com <mailto:idit.levine(a)gmail.com>> wrote:
Hi all,
We at Dell EMC would like to propose to contribute project unik (https://github.com/emc-advanced-dev/unik <https://github.com/emc-advanced-dev/unik>) and its integration with Cloud Foundry (https://github.com/emc-advanced-dev/cf-unik-buildpack <https://github.com/emc-advanced-dev/cf-unik-buildpack>) to Cloud Foundry community.
You can find the full official proposal at: https://docs.google.com/document/d/1Q9GakKpm6DMniJpWB-fqhE13SSPaj4-3sOWZ-I5nVyA/edit?usp=sharing <https://docs.google.com/document/d/1Q9GakKpm6DMniJpWB-fqhE13SSPaj4-3sOWZ-I5nVyA/edit?usp=sharing>
We of course welcome input and feedback on the proposal via inline commentary on the proposal document or directly to me.
Thanks,
Idit
--
dr.max Sent from my iPhone http://maximilien.org <http://maximilien.org/>
