Hi All,

Quick follow-up to this.

To ease the transition, we're going to continue updating the current
cflinuxfs2 BOSH release[1] until May 19, 2017.

After May 19, 2017, only the new BOSH release[2] will be updated.

Please make sure to update the release name in your deployment manifest
("cflinuxfs2-rootfs" -> "cflinuxfs2") when you switch to the new release.

[1] https://github.com/cloudfoundry/cflinuxfs2-rootfs-release
[2] https://github.com/cloudfoundry/cflinuxfs2-release

Thanks,
Stephen
(CF Buildpacks PM)

CF devs,

Please see the following public link for information about a high CVE in
UAA.
https://www.cloudfoundry.org/cve-2017-4972/

Friendly reminder that you can subscribe to new Cloud Foundry security
issues at: https://www.cloudfoundry.org/category/security/feed/

Please let me know if you have any questions or concerns.

Thanks,
Molly Crowther
Cloud Foundry Foundation Security Team

Hello All,

I'm excited to send this email as a reminder that EOL for the Legacy DEA
Backend is May 22, 2017, just over a month away, finally closing out a
great chapter for Cloud Foundry.

You can find the previous notice of this here [1] and here [2].

Documentation on how to migrate to Diego can be found here [3].

The EOL phase for the DEAs out will entail:
(1) moving the DEAs to the Cloud Foundry Attic (meaning the DEAs will no
longer be supported, no longer be patched for any reason, and no longer
accept any contributions),

(2) removing distribution of the DEAs from cf-release,

(3) shutting down all CI pipelines related to the DEAs,

(4) removing all code paths and technical debt in the Cloud Controller
associated with running Cloud Foundry on multiple backends.

Additionally, the Runtime OG team's support efforts have not required much
in the last several months, and the team is standing down for now.

Thanks!
Dieu Cao
CF Runtime PMC Lead


[1]
https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/PFXSJMKSQ6UNR2I5U5Q2H2QTXTCAEIJR/#PFXSJMKSQ6UNR2I5U5Q2H2QTXTCAEIJR

[2]
https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/GMXXJTTM2Q6SIRGVXSQH4TPLHTVHKNNG/

[3] https://docs.cloudfoundry.org/running/apps-enable-diego.html

Alex ,
Could you please provide the details about this failure under github issue https://github.com/cloudfoundry-community/mongodb-bosh-release/issues ? We can help take a look


Thanks
Lynn

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

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

Micro cloud foundry is for older version of Cloud Foundry
Please try the following

https://pivotal.io/pcf-dev
or
https://github.com/cloudfoundry/bosh-lite/blob/master/README.md#install-bosh-lite


2017-04-18 16:06 GMT+09:00 MuthuIQSSNet <muthukrishnan.m(a)iqss.net>:

FYI...

Final reminder of the CAB call this Wednesday @ 8a PDT (UTC -7).

Zoom in for CFF updates, project highlights, and talks by: David Dabeti (CF-deployment), Dmitriy Kalinin (Turbulence BOSH release), and Dr. Nic Williams on migrating releases to BOSH v2.

Talk soon. Cheers,

dr.max

ibm cloud labs
sillicon valley, ca
usa
maximilien.org

Sent from my iPhone

Begin forwarded message:

Hi,



I am also impressed on Cloud Foundry and to move next level, most of the
tutorial pointing to download Micro Cloud Foundry but the page seems not
available.

Cloud you please send me the link to download micro cloud foundry site and
in addition, if anything wanted to learn along with this, please send me
those also.



Thanks

Muthu

Are you familiar with bbl (bosh-bootloader)?
https://github.com/cloudfoundry/bosh-bootloader

This is a command line utility for standing up a CloudFoundry or Concourse

installation on an IAAS. This CLI is currently under heavy development, and
the initial goal is to support bootstrapping a CloudFoundry installation on
AWS.

The team developing it has an epic called "bbl aws terraform":
https://www.pivotaltracker.com/epic/show/3132527

See also, the #bbl-users channel in Slack
http://slack.cloudfoundry.org/

On Sun, Apr 16, 2017 at 7:50 AM, Leandro David Cacciagioni <
leandro.21.2008(a)gmail.com> wrote:

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

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

Hi Zach,

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

Happy Easter!
Peter

Excellent. Thanks Zack!

Mike

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

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.

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

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

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

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

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