proposal: unik & cloud foundry


Idit Levine
 

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


Idit Levine
 

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


Michael Maximilien
 

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


Daniel Jones
 

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> 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


Michael Maximilien
 

Hi, Idit,

Is there any updates on the concerns Daniel raised? Also, note comments in
proposals.

According to our process, when comments are not addressed, proposals become
stalled and then are subject to be removed from CF-extensions consideration.

Thanks in advance for addressing all comments.

Best,

Max

On Fri, Mar 24, 2017 at 4:33 AM 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>
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


--
dr.max Sent from my iPhone http://maximilien.org


Idit Levine
 

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/>


Michael Maximilien
 

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-fqhE13
SSPaj4-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


Idit Levine
 

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 <mailto: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 <mailto: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 <tel:+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 <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/>



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


Chip Childers <cchilders@...>
 

We can do it at summit if we want to wait that long. Is that the path that
you'd like Idit? If so, I can get a place scheduled for an open community
discussion around it.

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


Ramiro Salas
 

I really, really like this Unikernel approach, and the proxy idea for CF is very clever. It would remove a lot of adoption roadblocks from the security perspective, since you are now dealing with fully hardware-protected instances.

I think my main concern is that in essence, you are now booting micro-VMs, not containers, so the artifact is now openly exposed and protected only by whatever security group the IaaS can provide. This can be appreciated in the video of the talk when the IPs for each running app instance can be clearly observed. So they can't take advantage of constructs like Cell NATing, ASGs or Isolation Segments, AppArmor, Seccomp, etc. At least not apparently.

Could unik-spawned AIs live in overlay space with Netman? that would work nicely with the new networking model. If policy can be applied to the AI and enforced by the CNI-based SDN layer, then it would be a nice adaptation.

On a similar note, we now shift the scheduling responsibility from Diego to the IaaS essentially. And albeit the images are very small, are all IaaS capable of handling the speed and the transient nature of AIs constantly scaling up and down? Can all IaaSs achieve the 250K instance capacity that we know Diego with Garden can?

--
Ramiro Salas | @ramirosalas | Ecosystem Engineering @ Pivotal


Chip Childers <cchilders@...>
 

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


Idit Levine
 

It does. Looking forward!

Sent from my iPhone

On Apr 28, 2017, at 4:43 PM, Chip Childers <cchilders(a)cloudfoundry.org> wrote:

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
@DanielJonesEB
EngineerBetter Ltd - 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


Michael Maximilien
 

Wonderful. I can give you up to 15 mins. We use Zoom so you can share your screen if you want to do demo / presentation.

Look forward to it. Let me know if you need anything from me.

Best,

dr.max

ibm cloud labs
sillicon valley, ca
usa
maximilien.org

Sent from my iPhone

On Apr 29, 2017, at 12:40 AM, Idit Levine <idit.levine(a)gmail.com> wrote:

It does. Looking forward!

Sent from my iPhone

On Apr 28, 2017, at 4:43 PM, Chip Childers <cchilders(a)cloudfoundry.org> wrote:

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
@DanielJonesEB
EngineerBetter Ltd - 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


Idit Levine
 

Great, looking forward and thanks for your help.

On Apr 29, 2017, at 4:19 PM, Michael Maximilien <maxim(a)us.ibm.com> wrote:

Wonderful. I can give you up to 15 mins. We use Zoom so you can share your screen if you want to do demo / presentation.

Look forward to it. Let me know if you need anything from me.

Best,

dr.max

ibm cloud labs
sillicon valley, ca
usa
maximilien.org <http://maximilien.org/>

Sent from my iPhone

On Apr 29, 2017, at 12:40 AM, Idit Levine <idit.levine(a)gmail.com <mailto:idit.levine(a)gmail.com>> wrote:

It does. Looking forward!

Sent from my iPhone

On Apr 28, 2017, at 4:43 PM, Chip Childers <cchilders(a)cloudfoundry.org <mailto:cchilders(a)cloudfoundry.org>> wrote:

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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <tel:+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 <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/>



--
max
http://maximilien.org <http://maximilien.org/>
http://blog.maximilien.com <http://blog.maximilien.com/>
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815