Date   

Unify bootstrap scripts

Leandro David Cacciagioni
 

I would like to know if there is any plan to unify the bootstrap scripts? I
personally feel that the one for aws is not so good specially when deleting
deployments. I think it could be quite easy replaceable with terraform,
which can easily unify the way of deployment on all the officially
supported clouds (same for BOSH).
Please let me know if there is any plan to do this I would like to help.

Thanks,
Leandro.-


Re: Proposal for named service bindings

Peter Dotchev <dotchev@...>
 

Hi Zach,

I am glad you find this idea useful too.
Let me know if you need further input.

Happy Easter!
Peter

On Sat, Apr 15, 2017 at 2:55 AM Zach Robinson <zrobinson(a)pivotal.io> wrote:

Hey Peter,

I like the use-case that this proposal allows developers to set their
expected service name at development time. I think this is a nice explicit
contract and is also portable between Foundations, where services may have
different names.

I prefer that we find a way to keep VCAP_SERVICES backwards compatible and
that we keep binding names optional.

I will try drop a doc off on this thread in a couple days with a proposal
based on yours and with some cli stuff vetted by the cli team. Then we can
look at getting work prioritized

-Zach
CAPI Project Lead


Re: Proposal for named service bindings

Mike Youngstrom
 

Excellent. Thanks Zack!

Mike

On Fri, Apr 14, 2017 at 5:54 PM, Zach Robinson <zrobinson(a)pivotal.io> wrote:

Hey Peter,

I like the use-case that this proposal allows developers to set their
expected service name at development time. I think this is a nice explicit
contract and is also portable between Foundations, where services may have
different names.

I prefer that we find a way to keep VCAP_SERVICES backwards compatible and
that we keep binding names optional.

I will try drop a doc off on this thread in a couple days with a proposal
based on yours and with some cli stuff vetted by the cli team. Then we can
look at getting work prioritized

-Zach
CAPI Project Lead


Re: Proposal for named service bindings

Zach Robinson
 

Hey Peter,

I like the use-case that this proposal allows developers to set their expected service name at development time. I think this is a nice explicit contract and is also portable between Foundations, where services may have different names.

I prefer that we find a way to keep VCAP_SERVICES backwards compatible and that we keep binding names optional.

I will try drop a doc off on this thread in a couple days with a proposal based on yours and with some cli stuff vetted by the cli team. Then we can look at getting work prioritized

-Zach
CAPI Project Lead


Re: Loggregator Message Reliability Rates in CF253

Adam Hevenor
 

We have identified a fix for this issue and have released a fix in Loggregator 84. See the github issue linked this thread for more details.


NOTICE: Default version of Ruby in the Ruby buildpack will change to 2.4.x after 2017-05-14

Stephen Levine
 

Hi All,

The default version of Ruby in the Ruby buildpack will change from the
latest 2.3.x version (currently 2.3.4) to the latest 2.4.x version
(currently 2.4.1) in the first release of the Ruby buildpack after May 14,
2017. If you would like to continue using Ruby 2.3.x, please specify that
version line in your Gemfile. For more information, refer to the buildpack
documentation: http://docs.cloudfoundry.org/buildpacks/ruby/

Thanks,
Stephen Levine
Core CF Buildpacks PM


NOTICE: Default version of Go in the Go buildpack will change to 1.8.x after 2017-05-14

Stephen Levine
 

Hi All,

The default version of Go in the Go buildpack will change from the latest
1.7.x version (currently 1.7.5) to the latest 1.8.x version (currently
1.8.1) in the first release of the Go buildpack after May 14, 2017. If you
would like to continue using Go 1.7.x, please set the $GOVERSION
environment variable in your app, or use your choice of Go dependency
management utility to lock your version of Go to 1.7.5. For more
information, refer to the buildpack documentation:
http://docs.cloudfoundry.org/buildpacks/go/

Thanks,
Stephen Levine
Core CF Buildpacks PM


Re: cf create-service-auth-token for mongo db returns create-service-auth-token only works up to CF API version 2.46.0. Your target is 2.79.0.

Alex Irazabal
 

I tried it but got stuck here:
Deploying
---------

Director task 108
Deprecation: Ignoring cloud config. Manifest contains 'networks' section.

Started preparing deployment > Preparing deployment. Done (00:00:00)


it just sits there...not sure what is failing on.
Started preparing package compilation > Finding packages to compile


FYI: updates to CF-Extensions process and proposal template

Michael Maximilien
 

FYI...

The process (2 pages) and proposal template (1 page) have had a few updates since I released them earlier this year.

Changes are based on your feedback and Chip more recently. Thank you. Please peruse for correctness and add additional comments there.

Process: https://docs.google.com/document/d/1KaYuqNbPrr23d3OsAhi0NTwBNy-LRZK-FbN3LfBgqjw

Template: https://docs.google.com/document/d/1cpyBmds7WYNLKO1qkjhCdS8bNSJjWH5MqTE-h1UCQkQ

Lots coming in CF-Extensions this year and please know that I am always happy to chat with anyone with a CF-related OSS project that they would like to consider submitting.

Best,

dr.max

ibm cloud labs
sillicon valley, ca
usa
maximilien.org

Sent from my iPhone


Re: cf create-service-auth-token for mongo db returns create-service-auth-token only works up to CF API version 2.46.0. Your target is 2.79.0.

Lin, Lynn <Lynn.X.Lin@...>
 

If you only want to use mongodb service ,maybe you can have a try this one https://github.com/cloudfoundry-community/mongodb-bosh-release :)


Error 100: Unable to render instance groups for deployment. Errors are: - Unable to render jobs for instance group 'mongodb_gateway'. Errors are: - Unable to render templates for job 'mongodb_gateway'. Errors are: - Error filling in template 'mongodb_gateway.yml.erb' (line 5: undefined method `acls' for nil:NilClass)

Alex Irazabal
 

Here is the file in question: why does it fail for gateway.acls?
---
<%
service = "mongodb"
gateway = eval("properties.#{service}_gateway")
acls = gateway.acls
plan_enabled = properties.service_plans && properties.service_plans.send(service.to_sym)
plan_mgmt = plan_enabled && properties.service_plans.send(service.to_sym)
supported_plans = properties.supported_plans
if supported_plans
plan_mgmt.instance_eval("def fields; @table.keys.select { |v| #{supported_plans}.include? v.to_s }; end;") if plan_mgmt
else
plan_mgmt.instance_eval("def fields; @table.keys; end;") if plan_mgmt
end
supported_versions = gateway.supported_versions
version_aliases = gateway.version_aliases
version_aliases.instance_eval("def fields; @table.keys; end;") if version_aliases
nats_props_name = properties.nats_props || "nats"
nats_props = properties.send(nats_props_name)
nats = "nats://#{nats_props.user}:#{nats_props.password}@#{nats_props.address}:#{nats_props.port}"
lifecycle = properties.service_lifecycle
cc_api_version = gateway.cc_api_version || "v1"
unique_id = "8f4af9f9-0f29-4957-87a3-1039ce983ede"
%>
mbus: <%= nats %>
index: <%= spec.index %>

cloud_controller_uri: <%= properties.cc.srv_api_uri %>

service:
name: mongodb
unique_id: <%= unique_id %>
version: "1.8"
description: 'MongoDB NoSQL database'
provider: core
provider_name: 'Core'
plans:
<% if plan_enabled %>
<% for plan in plan_mgmt.fields.each %>
<% plan_description = plan_mgmt.send(plan.to_sym).description || "#{plan} plan" %>
<% plan_free_flag = plan_mgmt.send(plan.to_sym).free %>
<%= "'#{plan}':" %>
description: <%= "'#{plan_description}'" %>
unique_id: "<%= plan %>-<%= unique_id %>"
extra: ''
free: <%= !plan_free_flag.nil? && plan_free_flag.to_s || "true" %>
<% end %>
<% else %>
"free":
description: "free plan"
free: true
<% end %>
default_plan: '<%= gateway.default_plan || 'free' %>'
cf_plan_id:
<% plan_mgmt.fields.each do |pf| %>
<%= "'#{pf}': #{plan_mgmt.send(pf).configuration.cf_plan_id}" %>
<% end if plan_mgmt %>
tags: ['nosql', 'document', 'mongodb']
timeout: <%= properties.mongodb_gateway.service_timeout || 10 %>
<% if acls %>
<% if acls.is_a? String %>
acls: <%= acls %>
<% else %>
<% acls.plans.instance_eval("def fields; @table.keys; end;") if acls && acls.plans %>
acls:
<%= "users: ['#{acls.users.join("', '")}']" if acls.users %>
<%= "wildcards: ['#{acls.wildcards.join("', '")}']" if acls.wildcards %>
<% if acls.plans %>
plans:
<% acls.plans.fields.each do |plan|%>
<%= "#{plan}:"%>
<%= "users: ['#{acls.plans.send(plan.to_sym).users.join("', '")}']" if acls.plans.send(plan.to_sym).users %>
<%= "wildcards: ['#{acls.plans.send(plan.to_sym).wildcards.join("', '")}']" if acls.plans.send(plan.to_sym).wildcards %>
<% end %>
<% end %>
<% end %>
<% end %>
supported_versions: <%= "['#{supported_versions.join("' , '")}']" %>
<% if version_aliases && !version_aliases.fields.empty? %>
version_aliases:
<% for version_alias in version_aliases.fields.each %>
<%= "'#{version_alias}': '#{version_aliases.send(version_alias.to_sym)}'" %>
<% end %>
<% end %>

<% if gateway.ip_route %>
ip_route: <%= gateway.ip_route %>
<% end %>

cc_api_version: <%= cc_api_version %>

<% if cc_api_version == "v2" %>
gateway_name: "MongoDB (Core) Gateway"
uaa_client_id: <%= properties.uaa_client_id || "vmc" %>
uaa_endpoint: <%= properties.uaa_endpoint %>
uaa_client_auth_credentials:
username: <%= properties.uaa_client_auth_credentials.username %>
password: "<%= properties.uaa_client_auth_credentials.password %>"
service_auth_tokens:
mongodb_core: "<%= gateway.token %>"
<% end %>

token: "<%= gateway.token %>"
logging:
file: /var/vcap/sys/log/mongodb_gateway/mongodb_gateway.log
level: debug
<% if properties.syslog_aggregator %>
syslog: vcap.mongodb_gateway
<% end %>

pid: /var/vcap/sys/run/mongodb_gateway/mongodb_gateway.pid
node_timeout: <%= gateway.node_timeout || 8 %>
z_interval: <%= gateway.z_interval || 30 %>
check_orphan_interval: <%= gateway.check_orphan_interval || -1 %>
double_check_orphan_interval: <%= gateway.double_check_orphan_interval || 300 %>
max_nats_payload: <%= nats_props.max_payload || 1048576 %>

<% if lifecycle and lifecycle.resque %>
resque:
host: <%= lifecycle.resque.host %>
port: <%= lifecycle.resque.port %>
password: "<%= lifecycle.resque.password %>"
expire: <%= lifecycle.resque.expire %>
download_url_template: "http://<%= lifecycle.download_url %>/serialized/%{service}/%{name}/snapshots/%{snapshot_id}?token=%{token}"
<% end %>

<% if plan_enabled %>
plan_management:
plans:
<% plan_mgmt.fields.each do |pf| %>
'<%= pf %>':
high_water: <%= plan_mgmt.send(pf).job_management.high_water %>
low_water: <%= plan_mgmt.send(pf).job_management.low_water %>
allow_over_provisioning: <%= plan_mgmt.send(pf).configuration.allow_over_provisioning || "false" %>
<% opts = plan_mgmt.send(pf).configuration.lifecycle %>
<% if opts && opts.enable == true %>
lifecycle:
serialization: <%= opts.serialization || "disable" %>
<% if opts.snapshot %>
snapshot:
quota: <%= opts.snapshot.quota || 0 %>
<% end %>
<% if opts.serialization || opts.snapshot %>
job: enable
<% end %>
<% end %>
<% end %>
<% end %>


cf create-service-auth-token for mongo db returns create-service-auth-token only works up to CF API version 2.46.0. Your target is 2.79.0.

Alex Irazabal
 

How do I create the auth-token for my target? I installed cf-services-contrib V6 release. Trying to binf the mongodb to my app.


Re: proposal: unik & cloud foundry

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


Re: [cf-bosh] [ann] docker-boshrelease v30 - bosh loves docker - everything is easier with bosh links, cloud-config, bosh2

Amit Kumar Gupta
 

Great stuff Dr Nic, lovely blog post!

On Thu, Apr 13, 2017 at 7:26 AM, Dr Nic Williams <drnicwilliams(a)gmail.com>
wrote:

*Release notes*: https://github.com/cloudfoundry-community/docker-
boshrelease/releases/tag/v30.0.0

The docker-boshrelease was first introduced Apr 14, 2014 - three years ago
- by the legendary Ferdy. It has been used in production systems for years
- both running static clusters of containers, and as an API allowing
dynamic provisioning/deprovisioning of containers (historically this was
via Cloud Foundry) via the https://github.com/cloudfoundry-community/cf-
containers-broker companion project.

*To celebrate the dual birthdays* - this repository turning three and
BOSH itself turning five https://www.cloudfoundry.org/bosh-turns-five/ -
we've done a major upgrade to this project to bring it into line with the
exciting features in BOSH 2.0.

This release also includes the introduction of a companion project
https://github.com/cloudfoundry-community/docker-broker-deployment - the
one-stop shop for deploying the Open Service Broker API that can deploy
anything as a service, via Docker!

I've also published a "getting started" guide at
https://www.starkandwayne.com/blog/adding-docker-based-
services-to-your-cloud-foundry-with-bosh2/ which includes links to
getting started with bosh 2.0, and deploying CF using the fabulous new
bosh2 cli and *-deployment repos.

Happy birthday BOSH!
Dr Nic

--
Dr Nic Williams
Stark & Wayne LLC
http://starkandwayne.com
+61 437 276 076 <+61%20437%20276%20076>
twitter @drnic


[ann] docker-boshrelease v30 - bosh loves docker - everything is easier with bosh links, cloud-config, bosh2

Dr Nic Williams <drnicwilliams@...>
 

*Release notes*:
https://github.com/cloudfoundry-community/docker-boshrelease/releases/tag/v30.0.0

The docker-boshrelease was first introduced Apr 14, 2014 - three years ago
- by the legendary Ferdy. It has been used in production systems for years
- both running static clusters of containers, and as an API allowing
dynamic provisioning/deprovisioning of containers (historically this was
via Cloud Foundry) via the
https://github.com/cloudfoundry-community/cf-containers-broker companion
project.

*To celebrate the dual birthdays* - this repository turning three and BOSH
itself turning five https://www.cloudfoundry.org/bosh-turns-five/ - we've
done a major upgrade to this project to bring it into line with the
exciting features in BOSH 2.0.

This release also includes the introduction of a companion project
https://github.com/cloudfoundry-community/docker-broker-deployment - the
one-stop shop for deploying the Open Service Broker API that can deploy
anything as a service, via Docker!

I've also published a "getting started" guide at
https://www.starkandwayne.com/blog/adding-docker-based-services-to-your-cloud-foundry-with-bosh2/
which includes links to getting started with bosh 2.0, and deploying CF
using the fabulous new bosh2 cli and *-deployment repos.

Happy birthday BOSH!
Dr Nic

--
Dr Nic Williams
Stark & Wayne LLC
http://starkandwayne.com
+61 437 276 076
twitter @drnic


Re: CLA

Chip Childers <cchilders@...>
 

PR away!

Generally, what would happen is the the bots would remind you to file a CLA
before they are updated with your GH ID. But closing then reopening the PR
would kick the bot to mark it as OK to merge after we get the CLA filed and
bots configured. ;-)

On Thu, Apr 13, 2017 at 6:48 AM Leandro David Cacciagioni <
leandro.21.2008(a)gmail.com> wrote:

Hi guys,

Today I have submitted the CLA to the corresponding email address, did I
need to wait for any confirmation from the foundation to submit a pull
request or that's all that is required.

Thanks,
Leandro.-
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


CLA

Leandro David Cacciagioni
 

Hi guys,

Today I have submitted the CLA to the corresponding email address, did I
need to wait for any confirmation from the foundation to submit a pull
request or that's all that is required.

Thanks,
Leandro.-


Re: proposal: unik & cloud foundry

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


Re: proposal: unik & cloud foundry

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


Re: Java: How to find out user, org, application

Stanislav German-Evtushenko
 

Hi,


On Linux or MacOS the following shell scripts may help. They show details across organizations and spaces you have access to.
https://github.com/rakutentech/cf-tools/blob/master/cf-applist.sh
https://github.com/rakutentech/cf-tools/blob/master/cf-routelist.sh

Best regards,
Stanislav German-Evtushenko

On 11 April 2017 at 11:46, CF_genn <CF_subscription(a)streber24.de<mailto:CF_subscription(a)streber24.de>> wrote:
Hi CF-DEV,
I have a Java app deployed and running. Is it possible to find out from the
application
- in what org / space it is running?
- can it find out its own name? (as shown in "cf apps")

Thank you!





--
View this message in context: http://cf-dev.70369.x6.nabble.com/Java-How-to-find-out-user-org-application-tp6729.html
Sent from the CF Dev mailing list archive at Nabble.com.



--
Kind Regards,

David Farrell

Pivotal Global Support Services (GSS)

Email: dafarrell(a)pivotal.io<mailto:dafarrell(a)pivotal.io>
Office #: +353 21 4238482
Office Hours: Mon-Fri 8:30 AM to 5PM <GMT+1>
Out of Office Hours Contact +1 877-477-2269

Pivotal GSS Contact & Escalations:
https://discuss.zendesk.com/hc/en-us/articles/203809556


[https://docs.google.com/a/pivotal.io/uc?id=0BzyCyw2nYNQ_dnNvM0l6YzV1bzg&export=download]
pivotal.io<http://pivotal.io/>

2721 - 2740 of 9422