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

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

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

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

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

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

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

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