Idit,

I spoke with Dr. Max about this proposal, and he and I both think that
walking through the project and proposal live with the community would be
best done during the monthly CAB call. The next call is on 5/17 at 11 AM
Eastern US Time.

Hopefully that works for you!

-chip

On Thu, Apr 13, 2017 at 11:39 AM Idit Levine <idit.levine(a)gmail.com> wrote:

Sounds good. I reply to the BOSH comment and it should defiantly be part
of the discussion.
It make a lot of sense to held a f2f discussion at Cloud foundry summit.
Chip, thoughts ?

I believe I reply to all the comments.

Cheers,
Idit


On Apr 13, 2017, at 4:29 AM, Michael Maximilien <mmaximilien(a)gmail.com>
wrote:

Could we use time at the CF summit for f2f discussions?

There are also some comments in the docs. I added one more today w.r.t. to
the BOSH CPI and interface in Unik.

Anyhow, we could of course have more than one discussion.

Best,

Max

On Thu, Apr 13, 2017 at 6:11 AM, Idit Levine <idit.levine(a)gmail.com>
wrote:

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 <+44%207980%20009153>
@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>
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>
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>

wrote:

Hi all,

We at Dell EMC would like to propose to contribute project unik (

https://github.com/emc-advanced-dev/unik) and its integration with
Cloud Foundry (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

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

--
max
http://maximilien.org
http://blog.maximilien.com


--

Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815