Date   

Re: Issues on upgrading UAA 3.6.0 to 3.12.0?

Filip Hanik
 

We recommend that you upgrade to 3.16.0 to make sure you get all security
fixes included.

The UAA you are upgrading to supports multiple keys.
Here is an example

https://github.com/cloudfoundry/uaa/blob/develop/uaa/src/test/resources/test/bootstrap/all-properties-set.yml#L72-L82

add both your new and old keys into the configuration. Then set the
activeKeyId to be the new key.

The old key will be used to verify existing tokens only. The new key will
be used to sign new tokens.
When you believe the time is right, you can remove the old key from the
configuration. any tokens still signed with the old key will then be
considered invalid.

Filip

On Mon, May 8, 2017 at 4:23 PM, Sam Leong <sam.leong(a)quicken.com> wrote:

Hi,

We've been running UAA 3.6 on production and need to upgrade to 3.12. One
requirement is that we will need to retain the validity of the token that
was issued by UAA 3.6 after the upgrade.

We used the default key for token signing in 3.6, in the upgrade we will
use a new key, so I like to know the way how the client be able to verify
the signature of the old valid tokens while the new tokens will be signed
by a new key after upgrade to 3.12?

Thanks, Sam


Issues on upgrading UAA 3.6.0 to 3.12.0?

Sam Leong
 

Hi,

We've been running UAA 3.6 on production and need to upgrade to 3.12. One requirement is that we will need to retain the validity of the token that was issued by UAA 3.6 after the upgrade.

We used the default key for token signing in 3.6, in the upgrade we will use a new key, so I like to know the way how the client be able to verify the signature of the old valid tokens while the new tokens will be signed by a new key after upgrade to 3.12?

Thanks, Sam


Re: Proposal for named service bindings

Mike Youngstrom
 

This looks great! Thanks Zach.

Mike

On Mon, May 8, 2017 at 12:05 PM, Zach Robinson <zrobinson(a)pivotal.io> wrote:

Hey all,

Here's the implementation proposal: https://docs.google.com/
document/d/1PjcEx5_w383AKI9WyJHI4gGDkhIS9mhqwUK5nvmOWUc/edit?usp=sharing

And here's the tracker epic: https://www.pivotaltracker.
com/epic/show/3472063

-Zach


Re: Proposal for named service bindings

Zach Robinson
 


Get RTT with MessageInterceptor

Felipe Roca Blaya <felipe.rocablaya13@...>
 

Hi,
I'm working with eclipse-leshan and I found troubles trying to retrieve the rtt between a Coap request and response.
I've created a new MessageInterceptor but I've saw that CoapEndpoint calculates and sets the RTT value after notify the different MessageInterceptor.
This seems strange for me because the RTT by definition excludes the overhead in the requester. My first reaction has been if you change the order it should works. But I'm sure this has been made for a good reason. So if someone could explain it to me or tell me some other way to retrieve the rtt I'll be grateful.
Thanks in advance


Re: CF Diego Apps logging on stdout

Prashant Ghorpade
 

Hi,

Any updates? I am not getting application staging logs for CF v259 as well. Same observations for CF v255/256 and 257.

Thanks,
Prashant

From: Prashant Ghorpade
Sent: Wednesday, April 26, 2017 3:14 PM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org>
Subject: RE: [cf-dev] Re: CF Diego Apps logging on stdout

Hi,

Yes you right! I really mean to say application staging logs and following are sample output which I am not able to see for CF v255/256/257 for Diego as a default backend. It’s working for me for CF v254.

----------------------------------------------------------------------------------------------------------------------------
2017-04-24T13:00:31.67-0400 [STG/0] OUT Successfully created container
2017-04-24T13:00:31.67-0400 [STG/0] OUT Downloading app package...
2017-04-24T13:00:33.68-0400 [STG/0] OUT Staging...
2017-04-24T13:00:33.68-0400 [STG/0] OUT Downloaded app package (43.8M)
2017-04-24T13:00:35.32-0400 [STG/0] OUT -----> Java Buildpack Version: v3.14 (offline) | https://github.com/cloudfoundry/java-buildpack.git#d5d58c6
2017-04-24T13:00:35.51-0400 [STG/0] OUT -----> Downloading Open Jdk JRE 1.8.0_121 from https://java-buildpack.cloudfoundry.org/openjdk/trusty/x86_64/openjdk-1.8.0_121.tar.gz (found in cache)
2017-04-24T13:00:36.84-0400 [STG/0] OUT Expanding Open Jdk JRE to .java-buildpack/open_jdk_jre (1.3s)
2017-04-24T13:00:36.84-0400 [STG/0] OUT -----> Downloading Open JDK Like Memory Calculator 2.0.2_RELEASE from https://java-buildpack.cloudfoundry.org/memory-calculator/trusty/x86_64/memory-calculator-2.0.2_RELEASE.tar.gz (found in cache)
2017-04-24T13:00:36.87-0400 [STG/0] OUT Memory Settings: -Xms1363148K -XX:MetaspaceSize=209715K -Xmx1363148K -XX:MaxMetaspaceSize=209715K -Xss699K
2017-04-24T13:00:36.87-0400 [STG/0] OUT -----> Downloading Container Certificate Trust Store 2.0.0_RELEASE from https://java-buildpack.cloudfoundry.org/container-certificate-trust-store/container-certificate-trust-store-2.0.0_RELEASE.jar (found in cache)
2017-04-24T13:00:37.24-0400 [STG/0] OUT Adding certificates to .java-buildpack/container_certificate_trust_store/truststore.jks (0.3s)
2017-04-24T13:00:37.24-0400 [STG/0] OUT -----> Downloading Spring Auto Reconfiguration 1.10.0_RELEASE from https://java-buildpack.cloudfoundry.org/auto-reconfiguration/auto-reconfiguration-1.10.0_RELEASE.jar (found in cache)
2017-04-24T13:00:48.25-0400 [STG/0] OUT Uploading droplet...
2017-04-24T13:00:48.25-0400 [STG/0] OUT Exit status 0
2017-04-24T13:00:48.25-0400 [STG/0] OUT Staging complete
2017-04-24T13:00:48.25-0400 [STG/0] OUT Uploading droplet, build artifacts cache...
2017-04-24T13:00:48.25-0400 [STG/0] OUT Uploading build artifacts cache...
2017-04-24T13:00:48.32-0400 [STG/0] OUT Uploaded build artifacts cache (109B)
2017-04-24T13:00:53.13-0400 [STG/0] OUT Uploaded droplet (89.1M)
2017-04-24T13:00:53.16-0400 [STG/0] OUT Uploading complete
2017-04-24T13:00:53.19-0400 [STG/0] OUT Destroying container
2017-04-24T13:00:53.49-0400 [CELL/0] OUT Creating container
2017-04-24T13:00:54.04-0400 [CELL/0] OUT Successfully created container
2017-04-24T13:00:54.09-0400 [STG/0] OUT Successfully destroyed container
2017-04-24T13:00:57.49-0400 [CELL/0] OUT Starting health monitoring of container
----------------------------------------------------------------------------------------------------------------------------
Thanks,
Prashant

From: ronak banka [mailto:ronakbanka.cse(a)gmail.com]
Sent: Wednesday, April 26, 2017 2:54 PM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Subject: [cf-dev] Re: CF Diego Apps logging on stdout

Hello,

By "application startup logs", do you mean application staging logs??

Can you paste log lines which are missing?

Thanks
Ronak

On Wed, Apr 26, 2017 at 14:25 Prashant Ghorpade <prashant.ghorpade(a)sas.com<mailto:prashant.ghorpade(a)sas.com>> wrote:
Hello,

I have seen some changes related to “cf logs app_name” command from CF v255 onwards on Openstack using Diego as a default container. CF v254 is working for me.

I am not getting application startup logs after running “cf logs app_name” command on stdout.

I am able to see logs when I try to access the sample application from browser but I am more interested in application startup logs.

Kindly let me know in case any additional details are required for the same.

Thanks,
Prashant


Re: Update: Locks & Service Discovery in CF Runtime

Benjamin Gandon
 

The road off Consul looks like it is long but necessary. Consul looks like a spof in CF, when you know how much the platform needs it, and when you read that sometimes plain upgrades break it badly.

Plus, the myriad of logic in the confab wrapper around Consul is an example of how much Consul is hard to manage and keep up properly.

Don't forget that recently PCF benefitted a CRE (SRE-tye) shared review from Google.
Don't forget that we have converging evidences that let us think Google stays away from etcd for their hosted K8s on GCP.

My guess is that internally, Google SREs might have evidences at scale that systems like etcd or consul should be avoided, and this understanding is being ported to CF through the CRE program.


Also, moving away from Consul is like choosing to build Diego instead of building on top of K8s. Controlling the agenda is important. I mean not being forced to run after a project that has its own. Ensuring which value is put into the product, and that this value is consistent with the rest of the platform, is also important.


These are just thoughts. I would love to read more precise info about the Why, for this "away-from-Consul" move. Guys?

Le 26 avr. 2017 à 18:48, Voelz, Marco <marco.voelz(a)sap.com> a écrit :

Dear Luan,

Maybe that's a stupid question which has already been answered, but doesn't consul release 0.8 address most of the criticism from the CF community?

I see now big efforts on all sides (CF and BOSH teams) invested in building our own solution to a problem which seems to be pretty generic.

Do we think that's something we should spend engineering resources on and that others (e.g. HashiCorp in this case) cannot solve the problem to se be our needs? At least to me it seems that they try to move in the right direction.

Maybe my perspective on this is just too generic and I'm not deep enough in the technical details.

What do you think?

Thanks and warm regards
Marco



On 24. Apr 2017, at 20:35, Luan Santos <lsantos(a)pivotal.io> wrote:

Hi all,

We have been working on the milestones proposed before in order to lessen and remove our dependencies on Consul.

Please see the updated Locks & Service Discovery in CF Runtime document for more details and discussion.

Thanks,

Luan
Software Engineer, Cloud Foundry @ Pivotal


Re: Inconsistency in retrieval of service plans

Benjamin Gandon
 

Did you look at the doc on api.cloudfoundry.org about any ordering contract for those API calls?

Le 5 mai 2017 à 12:16, Roopali Sharma <roopali1193(a)gmail.com> a écrit :

Hello All,



While listing service plans for any given service , if we use /v2/service_plans?q=<service_guid> , the plans appear in the same order as defined in the service catalog. However, call to /v2/services/<service_guid>?inline-relations-depth=1 returns the service plans in some random ordering which does not respect the order of catalog. The ordering however does not change with every call and also does not seem to take into account unique plan_id or the plan_name itself. Hence , it is unclear as to what sorting paradigm is in use.



Can someone comment if this is a bug with controller API or if not, some clarity regarding the ranking order.



With regards,

Roopali Sharma


Re: Questions on credential rotation

Krannich, Bernd <bernd.krannich@...>
 

Hey Dan,

Thank you very much for your reply!

I think there is overwhelming agreement that all components should allow credential rotation without downtime, where possible, so I would expect it is on many teams' radar. If not, I am happy to start conversations once we get to that phase of our project.
Sound great. We are actively following the developments in bosh-deployment and cf-deployment also with respect to credhub integration. It would be great if you could send an update via this list once you have reached the next phase here.

Thanks,
Bernd

P.S.: > We view our project as being part of the 'rotate' component of Justin's vision. Repave is focused on recreating instances to a known-good state, which is something outside of our area of concern.
Yes, I meant to write:
CredHub [4] seems to be geared in the direction of “rotate”.
Repave is of course largely based on regular stemcell updates using BOSH.

P.P.S.: For the people reading through this thread, I corrected my footnotes which unfortunately pointed to the head of the master branch earlier:
[2] https://github.com/cloudfoundry/cf-release/blob/01ccfbbb01bb8824594f67529a4c325214507f08/templates/cf.yml#L640
[3] https://github.com/cloudfoundry/cf-release/blob/01ccfbbb01bb8824594f67529a4c325214507f08/templates/cf.yml#L872

From: Dan Jahner <djahner(a)pivotal.io>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Date: Thursday, 4. May 2017 at 22:22
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Re: Questions on credential rotation

Hey Bernd,

I am the product manager of CredHub. We view our project as being part of the 'rotate' component of Justin's vision. Repave is focused on recreating instances to a known-good state, which is something outside of our area of concern.

The current roadmap for CredHub is focused on pulling credentials into our system; specifically BOSH deployment and service credentials, later application credentials. Once we have a solid footing for storing and managing access to these credentials, we plan to explore what possibilities exist for reducing the friction of credential rotation.

Although I haven't spent a long time investigating, I would agree with your characterization of the 3 classes of credentials. I think there is overwhelming agreement that all components should allow credential rotation without downtime, where possible, so I would expect it is on many teams' radar. If not, I am happy to start conversations once we get to that phase of our project.

Thanks,
Dan
On Thu, May 4, 2017 at 6:32 AM Krannich, Bernd <bernd.krannich(a)sap.com<mailto:bernd.krannich(a)sap.com>> wrote:
Hello all,

We love Justin Smith’s approach of “Rotate, Repair, Repave” [1] when it comes to security. Looking at how the “Rotate” aspect is handled in Cloud Foundry and other BOSH deployments today, we think there’s currently three classes of credentials:


1. Credentials that can be rotated by updating them and doing a `bosh deploy` with zero downtime

2. Credentials that can be rotated by updating them and doing a `bosh deploy` involving a downtime [2]

3. Credentials that cannot be rotated easily at all [3]

A couple of questions here:


• Is the above summary accurate?

• For updates involving a downtime, the only naïve solution I could come up with is to support two sets of credentials during the transition. Are there any more strategies?

• Are there any efforts to turn credentials falling under #2 and #3 into ones that can be updated without downtime?

• CredHub [4] seems to be geared in the direction of “repave”. Is this the case and does this maybe even support work on the previous bullet?

Thanks in advance,
Bernd

[1] https://www.youtube.com/watch?v=NUXpz0Dni50
[2] https://github.com/cloudfoundry/cf-release/blob/master/templates/cf.yml#L634 might be a good example
[3] https://github.com/cloudfoundry/cf-release/blob/master/templates/cf.yml#L865 might be a good example
[4] https://github.com/cloudfoundry-incubator/credhub


Bernd Krannich
SAP Cloud Platform
SAP SE
Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

E bernd.krannich(a)sap.com<mailto:bernd.krannich(a)sap.com>

Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum<http://www.sap.com/company/legal/impressum.epx/>

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.


Spring Cloud data flow

Mohan Radhakrishnan
 

Where can look at some instructions to deploy Spring data flow and Apache Spark on one pipeline and a ML tool like H2O or MapR on the other ? I am trying to simulate stream data processing by analyzing data that originates from Spark,flows through Spring Cloud data flow and reaches the ML tool. At this time I would to try this setup. I don't own any licenses.

Thanks,
Mohan


Upcoming changes to cf-release manifests

David Sabeti
 

Hi cf-dev!

As you may have heard, May 22 marks the last day of DEA support. In advance
of that, the manifest templates in CF 260 will start to choose Diego as the
default backend for running apps. You can still set
`default_to_diego_backend` to false if you would really like to run the
DEAs, but making Diego the default in the manifest templates is a long
overdue change.

Feel free to reach out if you have any questions!

David Sabeti
CF Release Integration PM


Reliability issue with Diego v1.15.1; please use v1.15.0 instead

Eric Malm <emalm@...>
 

Hi, all,

Please do not use v1.15.1 of the Diego BOSH release. The Diego team instead
recommends using v1.15.0, or the forthcoming next final release (most
likely named v1.15.2).

The only change between v1.15.0 and v1.15.1 is an upgrade of the Golang
version from v1.7.4 to v1.8.1. After deploying this release in a large
environment, we observed that the Diego auctioneers on v1.15.1 failed to
make successful requests to retrieve the Diego cells' latest state at the
start of an auction, and typically failed seemingly at random on a
substantial proportion of them. While we did not observe any obvious
significant impact to application developers or application traffic because
of these failures, we are still concerned about them, and do not feel
comfortable recommending operation of a system that exhibits them.

Rolling back to Diego v1.15.0 in the same environment caused the
auctioneers to resume functioning normally, so we're fairly confident that
this issue is caused by the change to the version of Golang in the release.
We'll be reverting that version to v1.7.4 for the next Diego final release,
which we hope to have available as soon as possible, and will then
investigate these failures and ensure we have a resolution for them in
place before re-advancing to the v1.8 Golang line in the release.

Apologies for any inconvenience this issue may have caused, and please let
me or the rest of the Diego team know if you have further questions.

Best,
Eric, CF Diego PM


Inconsistency in retrieval of service plans

Roopali Sharma <roopali1193@...>
 

Hello All,



While listing service plans for any given service , if we use
/v2/service_plans?q=<service_guid> , the plans appear in the same order as
defined in the service catalog. However, call to
/v2/services/<service_guid>?inline-relations-depth=1 returns the service
plans in some random ordering which does not respect the order of catalog.
The ordering however does not change with every call and also does not seem
to take into account unique plan_id or the plan_name itself. Hence , it is
unclear as to what sorting paradigm is in use.



Can someone comment if this is a bug with controller API or if not, some
clarity regarding the ranking order.



With regards,

Roopali Sharma


Re: Concourse-Up: Deploy Concourse CI in a Single Command

Tim Lawrence <tim.lawrence1984@...>
 

on the beach or on the bench?

I find the glare on my screen difficult on the beach :-)

Good work!

On Thu, May 4, 2017 at 2:19 PM, Dan Young <dan.young(a)engineerbetter.com>
wrote:

Hi all,

I guess there are a lot of Concourse CI users on this list, so I thought
I'd mention a new tool that some of the EngineerBetter team built while on
the beach. Concourse-Up will let you deploy a production-ready Concourse on
AWS for your team, *using just a single command *and without needing to
know anything about BOSH. It supports custom domains, SSL termination,
scaling workers, and idempotent upgrades.

Here is a blog post: http://www.engineerbetter.com/2017/05/03/introducing-
concourse-up.html

And the GitHub repo: https://github.com/engineerbetter/concourse-up
Hopefully this will be useful for teams setting up Concourse for new
projects, or new Concourse users who less than enthusiastic about needing
to learn BOSH.

Feedback, feature requests and bug reports are most welcome.

Regards,
Dan Young - CEO
EngineerBetter Ltd <http://www.engineerbetter.com> - The UK Cloud Foundry
Specialists
@dan0young <http://www.twitter.com/dan0young>
+44 (0)7783 397092 <+447783397092>


Re: Questions on credential rotation

Dan Jahner
 

Hey Bernd,

I am the product manager of CredHub. We view our project as being part of
the 'rotate' component of Justin's vision. Repave is focused on recreating
instances to a known-good state, which is something outside of our area of
concern.

The current roadmap for CredHub is focused on pulling credentials into our
system; specifically BOSH deployment and service credentials, later
application credentials. Once we have a solid footing for storing and
managing access to these credentials, we plan to explore what possibilities
exist for reducing the friction of credential rotation.

Although I haven't spent a long time investigating, I would agree with your
characterization of the 3 classes of credentials. I think there is
overwhelming agreement that all components should allow credential rotation
without downtime, where possible, so I would expect it is on many teams'
radar. If not, I am happy to start conversations once we get to that phase
of our project.

Thanks,
Dan

On Thu, May 4, 2017 at 6:32 AM Krannich, Bernd <bernd.krannich(a)sap.com>
wrote:

Hello all,



We love Justin Smith’s approach of “Rotate, Repair, Repave” [1] when it
comes to security. Looking at how the “Rotate” aspect is handled in Cloud
Foundry and other BOSH deployments today, we think there’s currently three
classes of credentials:



1. Credentials that can be rotated by updating them and doing a
`bosh deploy` with zero downtime

2. Credentials that can be rotated by updating them and doing a
`bosh deploy` involving a downtime [2]

3. Credentials that cannot be rotated easily at all [3]



A couple of questions here:



· Is the above summary accurate?

· For updates involving a downtime, the only naïve solution I
could come up with is to support two sets of credentials during the
transition. Are there any more strategies?

· Are there any efforts to turn credentials falling under #2 and
#3 into ones that can be updated without downtime?

· CredHub [4] seems to be geared in the direction of “repave”. Is
this the case and does this maybe even support work on the previous bullet?



Thanks in advance,

Bernd



[1] https://www.youtube.com/watch?v=NUXpz0Dni50

[2]
https://github.com/cloudfoundry/cf-release/blob/master/templates/cf.yml#L634 might
be a good example

[3]
https://github.com/cloudfoundry/cf-release/blob/master/templates/cf.yml#L865 might
be a good example

[4] https://github.com/cloudfoundry-incubator/credhub





*Bernd Krannich*

SAP Cloud Platform

*SAP SE*

Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany



E bernd.krannich(a)sap.com



Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum
<http://www.sap.com/company/legal/impressum.epx/>



Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige
vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich
erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine
Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte
benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen
Dank.



This e-mail may contain trade secrets or privileged, undisclosed, or
otherwise confidential information. If you have received this e-mail in
error, you are hereby notified that any review, copying, or distribution of
it is strictly prohibited. Please inform us immediately and destroy the
original transmittal. Thank you for your cooperation.


disabling ipv6 at the kernel level in stemcells

Dmitriy Kalinin <dkalinin@...>
 

hey all,

we've disabled ipv6 via ipv6.disable=1 in grub in 3363.19+ linux stemcells
some time ago. in previous stemcells it was disabled via sysctl at bootup.

we are now aware that small number of releases may be affected (one release
for example was disabling portion of ipv6 functionality themselves but no
longer can succeed since /proc/... entry is gone and that code was not
checking for its existence). we also had a report that some java processes
may be affected if they were using particular libraries that for some
reason try to obtain local ipv6 address (even though ipv6 was disabled
before their startup).

we try very hard to avoid making any breaking changes in minor stemcell
versions; however, this changed turned out to be more disruptive than we
expected. given that it affects only small number of releases we have
decided to keep it in (hoping that it should be easy for release authors to
issue a patch if necessary).

(for folks thinking about the future ipv6 support, bosh-agent will
automatically turn it on at runtime if necessary.)

as usual feel free to reach out to us on #bosh slack if you need any help.

dmitriy


Questions on credential rotation

Krannich, Bernd <bernd.krannich@...>
 

Hello all,

We love Justin Smith’s approach of “Rotate, Repair, Repave” [1] when it comes to security. Looking at how the “Rotate” aspect is handled in Cloud Foundry and other BOSH deployments today, we think there’s currently three classes of credentials:


1. Credentials that can be rotated by updating them and doing a `bosh deploy` with zero downtime

2. Credentials that can be rotated by updating them and doing a `bosh deploy` involving a downtime [2]

3. Credentials that cannot be rotated easily at all [3]

A couple of questions here:


· Is the above summary accurate?

· For updates involving a downtime, the only naïve solution I could come up with is to support two sets of credentials during the transition. Are there any more strategies?

· Are there any efforts to turn credentials falling under #2 and #3 into ones that can be updated without downtime?

· CredHub [4] seems to be geared in the direction of “repave”. Is this the case and does this maybe even support work on the previous bullet?

Thanks in advance,
Bernd

[1] https://www.youtube.com/watch?v=NUXpz0Dni50
[2] https://github.com/cloudfoundry/cf-release/blob/master/templates/cf.yml#L634 might be a good example
[3] https://github.com/cloudfoundry/cf-release/blob/master/templates/cf.yml#L865 might be a good example
[4] https://github.com/cloudfoundry-incubator/credhub


Bernd Krannich
SAP Cloud Platform
SAP SE
Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany

E bernd.krannich(a)sap.com<mailto:bernd.krannich(a)sap.com>

Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum<http://www.sap.com/company/legal/impressum.epx/>

Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen Dank.

This e-mail may contain trade secrets or privileged, undisclosed, or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying, or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation.


Concourse-Up: Deploy Concourse CI in a Single Command

Dan Young <dan.young@...>
 

Hi all,

I guess there are a lot of Concourse CI users on this list, so I thought
I'd mention a new tool that some of the EngineerBetter team built while on
the beach. Concourse-Up will let you deploy a production-ready Concourse on
AWS for your team, *using just a single command *and without needing to
know anything about BOSH. It supports custom domains, SSL termination,
scaling workers, and idempotent upgrades.

Here is a blog post: http://www.engineerbetter.com/2017/05/03/
introducing-concourse-up.html

And the GitHub repo: https://github.com/engineerbetter/concourse-up
Hopefully this will be useful for teams setting up Concourse for new
projects, or new Concourse users who less than enthusiastic about needing
to learn BOSH.

Feedback, feature requests and bug reports are most welcome.

Regards,
Dan Young - CEO
EngineerBetter Ltd <http://www.engineerbetter.com> - The UK Cloud Foundry
Specialists
@dan0young <http://www.twitter.com/dan0young>
+44 (0)7783 397092 <+447783397092>


Re: proposal: unik & cloud foundry

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


Re: [cf-bosh] Re: BOSH CLI v2

Julz Friedman
 

I can't wait to try out the new log-in com-mand

[image: Gemoji image for :trollface:]

(Srsly great work bosh folks! :))

On Tue, 2 May 2017 at 06:39 Sean Keery <skeery(a)pivotal.io> wrote:

Excellent. Thanks to the team for all the hard work.

On Mon, May 1, 2017 at 7:39 PM Dmitriy Kalinin <dkalinin(a)pivotal.io>
wrote:

Hey all,

I am happy to announce BOSH CLI v2 is now generally available. CLI v2
incorporates tons of feedback received over the past few years. Some
features have been redesigned, some removed, and some hopefully much
improved.

You will find docs available on https://bosh.io/docs. Let us know if you
find any missing material (I'm sure there is some). Here are some
documentation pages worth mentioning:

- https://bosh.io/docs#basic-deploy - cli v2 section on the index page
- https://bosh.io/docs/cli-v2 - all commands
- https://bosh.io/docs/cli-v2-diff - some notable cli v1 vs v2
differences

CLI binary also links directly to the command specific documentation
section from its command help output (-h), so more information is just a
command+click away.

CLI v1 will continue to work and be supported for some time; however, new
Director features will not be exposed in v1.

Feel free to drop by #bosh slack channel if you have any questions,

BOSH team

--
*Sean Keery | Minister of Chaos | Pivotal Cloud Foundry Solutions*
Mobile: 970.274.1285 | skeery(a)pivotal.io
LinkedIn: @zgrinch <http://www.linkedin.com/in/zgrinch> | Twitter:
@zgrinch <https://twitter.com/zgrinch> | Github: @skibum55
<https://github.com/skibum55>


Adopt the Silicon Valley state of mind

2641 - 2660 of 9422