Date   
REMINDER CAB call for April live today @ CF Summit Room 116 @ 11a Philly time

Michael Maximilien
 

FYI... 

Same time 8a Pacific or 11a EST and also streamed on zoom.  Room 116 at the Philadelphia convention center.


So join remotely if you can or if you are at CF Summit but can’t make it to the room.

Also, no set agenda. Just open discussions.

See / zoom you soon. Best,


dr.max
ibm ☁ 
silicon valley, ca


Re: Buildpack deep dive questions...

José Riguera López
 

I have a kind of same issue as you trying to understand how a buildpack works and creating a new one. The golang library used in the official buildpacks has no documentation, so it makes really difficult starting from zero, specially if we are talking of something which should be a "helper".
I made a grafana buildpack with bash scripts (https://github.com/SpringerPE/cf-grafana-buildpack) which think it makes easy to understand what each step (the scripts in `bin` folder) are responsible for, and the argument parameters (folders) they get. Is specially important the correct usage of the caching folder to avoid downloading again and again the binaries (resources), because there are other examples on github I think they do not properly manage that part (ofc, the buildpack works but it downloads again and again the resources).

Jose,

El lun., 25 mar. 2019 a las 15:45, Cade Thacker (<cade@...>) escribió:
Long time reader... first time poster :D 

I'm really digging and deconstruction a few different buildpacks trying to understand how they really work.  supply, compile, detect, etc.  Especially the multi buildpack POV. 

So I think i'm starting to get the details straight but I have some basic architecture questions. 

1) For example, if the core functionality of the buildpack is a compiled app (like go or java) and not a scripted language but the github repo only contains the source code then somewhere in this process it must be compiled.  If I want to use the buildpack as an online buildpack that means that the buildpack has to be "built" after it is cloned down during staging.  Is this the correct path?  Or should it be built and the binary pushed back with the code into github? This seems wrong. Somebody hit me with the clue stick. 

2) Second, somewhat tangent question. I know that CloudFoundry is doing tons of work around envoy/istio, but we have a more pressing need right now.  My company has a need to connect many apps and CloudFoundry is just one small part of our runtime. Would it be possible to write a final build pack for envoy and have it basically bind to PORT and then pass the calls to whatever was the 2nd to last buildpack? java, ruby, go, etc.  Forgive me if this is a silly question, but trying to find the edge of this new multi build pack world. Need to inject some custom ingress/egress rules. 

-- 
--cade



--
José Riguera López <jriguera@...>

Re: Buildpack deep dive questions...

Tim Downey
 

Feel free to reach out in the #capi channel on the Cloud Foundry Slack and folks from our team would be happy to chat!

As I mentioned earlier, we're actively working on the MVP so it's very experimental and there's not much yet in the way of docs for it, but we're working on it! Don't mean to derail your immediate plans though, so I would recommend looking into Dan's suggestions for the near-term.

- Tim

On Tue, Apr 2, 2019 at 1:22 PM Cade Thacker <cade.thacker@...> wrote:
This is outstanding.  How can I get involved? I’d love to jump into that conversation with both feet and help!! 

We are looking to better control egress and offload app security on ingress.  

Specifically envoy.  

Cade


On Apr 2, 2019, at 12:38, Tim Downey <tdowney@...> wrote:

Hi Cade,

This won't necessarily help for your immediate needs, but wanted to share that the Cloud Controller (CAPI) team is actively working on experimental support for including user-specified sidecar processes within the app container.

For the MVP form of this you'll still need to find a way to include the sidecar executable with your app (either via a buildpack or including it with the app source), but it should provide an easier way to specify/view information about the sidecar processes via `/v3/sidecars`.


As I said, this is still under active development and very experimental, but we'd be interested in learning more about your use cases.

Stay tuned!

Tim Downey, CAPI Team

On Tue, Apr 2, 2019, 6:53 AM Daniel Mikusa <dmikusa@...> wrote:
On Mon, Mar 25, 2019 at 10:45 AM Cade Thacker <cade@...> wrote:
Long time reader... first time poster :D 

I'm really digging and deconstruction a few different buildpacks trying to understand how they really work.  supply, compile, detect, etc.  Especially the multi buildpack POV. 

So I think i'm starting to get the details straight but I have some basic architecture questions. 

1) For example, if the core functionality of the buildpack is a compiled app (like go or java) and not a scripted language but the github repo only contains the source code then somewhere in this process it must be compiled.  If I want to use the buildpack as an online buildpack that means that the buildpack has to be "built" after it is cloned down during staging.  Is this the correct path?  Or should it be built and the binary pushed back with the code into github? This seems wrong. Somebody hit me with the clue stick. 

If your buildpack itself needs to be compiled, you have two choices:

1.) Compile locally, package a buildpack and install with `cf create-buildpack`.
2.) Use a shim script to build then run your buildpack. If you want to support `cf push -b https://git-url/my-buildpack` then you have to do this.


and the script it runs to install Golang.

 

2) Second, somewhat tangent question. I know that CloudFoundry is doing tons of work around envoy/istio, but we have a more pressing need right now.  My company has a need to connect many apps and CloudFoundry is just one small part of our runtime. Would it be possible to write a final build pack for envoy and have it basically bind to PORT and then pass the calls to whatever was the 2nd to last buildpack? java, ruby, go, etc.  Forgive me if this is a silly question, but trying to find the edge of this new multi build pack world. Need to inject some custom ingress/egress rules. 

The final buildpack can basically do what ever it wants, since it gets to dictate the start command. If you want it to start Envoy + some other stuff you can do that. A couple things to keep in mind. First, if you're starting multiple processes in the app container you need to manage them. If one fails, you need to make it so that they all fail, or you'll have unexpected behavior. For example, if Envoy is running but your second process, presumably your actual app, crashes then you need to make sure they all crash so that the platform can detect the crash and restart your app. Second, multiple processes in the container makes it harder to reason about available memory, be especially careful if you're running a Java app. Lastly, only the supply script will run for non-final buildpacks. If you need finalize to run for a non-final buildpack, like to get the proper Java start command, then that's not going to be easy.

Hope that helps!

Dan


Re: Buildpack deep dive questions...

Cade Thacker <cade.thacker@...>
 

This is outstanding.  How can I get involved? I’d love to jump into that conversation with both feet and help!! 

We are looking to better control egress and offload app security on ingress.  

Specifically envoy.  

Cade


On Apr 2, 2019, at 12:38, Tim Downey <tdowney@...> wrote:

Hi Cade,

This won't necessarily help for your immediate needs, but wanted to share that the Cloud Controller (CAPI) team is actively working on experimental support for including user-specified sidecar processes within the app container.

For the MVP form of this you'll still need to find a way to include the sidecar executable with your app (either via a buildpack or including it with the app source), but it should provide an easier way to specify/view information about the sidecar processes via `/v3/sidecars`.


As I said, this is still under active development and very experimental, but we'd be interested in learning more about your use cases.

Stay tuned!

Tim Downey, CAPI Team

On Tue, Apr 2, 2019, 6:53 AM Daniel Mikusa <dmikusa@...> wrote:
On Mon, Mar 25, 2019 at 10:45 AM Cade Thacker <cade@...> wrote:
Long time reader... first time poster :D 

I'm really digging and deconstruction a few different buildpacks trying to understand how they really work.  supply, compile, detect, etc.  Especially the multi buildpack POV. 

So I think i'm starting to get the details straight but I have some basic architecture questions. 

1) For example, if the core functionality of the buildpack is a compiled app (like go or java) and not a scripted language but the github repo only contains the source code then somewhere in this process it must be compiled.  If I want to use the buildpack as an online buildpack that means that the buildpack has to be "built" after it is cloned down during staging.  Is this the correct path?  Or should it be built and the binary pushed back with the code into github? This seems wrong. Somebody hit me with the clue stick. 

If your buildpack itself needs to be compiled, you have two choices:

1.) Compile locally, package a buildpack and install with `cf create-buildpack`.
2.) Use a shim script to build then run your buildpack. If you want to support `cf push -b https://git-url/my-buildpack` then you have to do this.


and the script it runs to install Golang.

 

2) Second, somewhat tangent question. I know that CloudFoundry is doing tons of work around envoy/istio, but we have a more pressing need right now.  My company has a need to connect many apps and CloudFoundry is just one small part of our runtime. Would it be possible to write a final build pack for envoy and have it basically bind to PORT and then pass the calls to whatever was the 2nd to last buildpack? java, ruby, go, etc.  Forgive me if this is a silly question, but trying to find the edge of this new multi build pack world. Need to inject some custom ingress/egress rules. 

The final buildpack can basically do what ever it wants, since it gets to dictate the start command. If you want it to start Envoy + some other stuff you can do that. A couple things to keep in mind. First, if you're starting multiple processes in the app container you need to manage them. If one fails, you need to make it so that they all fail, or you'll have unexpected behavior. For example, if Envoy is running but your second process, presumably your actual app, crashes then you need to make sure they all crash so that the platform can detect the crash and restart your app. Second, multiple processes in the container makes it harder to reason about available memory, be especially careful if you're running a Java app. Lastly, only the supply script will run for non-final buildpacks. If you need finalize to run for a non-final buildpack, like to get the proper Java start command, then that's not going to be easy.

Hope that helps!

Dan


Re: Buildpack deep dive questions...

Tim Downey
 

Hi Cade,

This won't necessarily help for your immediate needs, but wanted to share that the Cloud Controller (CAPI) team is actively working on experimental support for including user-specified sidecar processes within the app container.

For the MVP form of this you'll still need to find a way to include the sidecar executable with your app (either via a buildpack or including it with the app source), but it should provide an easier way to specify/view information about the sidecar processes via `/v3/sidecars`.


As I said, this is still under active development and very experimental, but we'd be interested in learning more about your use cases.

Stay tuned!

Tim Downey, CAPI Team

On Tue, Apr 2, 2019, 6:53 AM Daniel Mikusa <dmikusa@...> wrote:
On Mon, Mar 25, 2019 at 10:45 AM Cade Thacker <cade@...> wrote:
Long time reader... first time poster :D 

I'm really digging and deconstruction a few different buildpacks trying to understand how they really work.  supply, compile, detect, etc.  Especially the multi buildpack POV. 

So I think i'm starting to get the details straight but I have some basic architecture questions. 

1) For example, if the core functionality of the buildpack is a compiled app (like go or java) and not a scripted language but the github repo only contains the source code then somewhere in this process it must be compiled.  If I want to use the buildpack as an online buildpack that means that the buildpack has to be "built" after it is cloned down during staging.  Is this the correct path?  Or should it be built and the binary pushed back with the code into github? This seems wrong. Somebody hit me with the clue stick. 

If your buildpack itself needs to be compiled, you have two choices:

1.) Compile locally, package a buildpack and install with `cf create-buildpack`.
2.) Use a shim script to build then run your buildpack. If you want to support `cf push -b https://git-url/my-buildpack` then you have to do this.


and the script it runs to install Golang.

 

2) Second, somewhat tangent question. I know that CloudFoundry is doing tons of work around envoy/istio, but we have a more pressing need right now.  My company has a need to connect many apps and CloudFoundry is just one small part of our runtime. Would it be possible to write a final build pack for envoy and have it basically bind to PORT and then pass the calls to whatever was the 2nd to last buildpack? java, ruby, go, etc.  Forgive me if this is a silly question, but trying to find the edge of this new multi build pack world. Need to inject some custom ingress/egress rules. 

The final buildpack can basically do what ever it wants, since it gets to dictate the start command. If you want it to start Envoy + some other stuff you can do that. A couple things to keep in mind. First, if you're starting multiple processes in the app container you need to manage them. If one fails, you need to make it so that they all fail, or you'll have unexpected behavior. For example, if Envoy is running but your second process, presumably your actual app, crashes then you need to make sure they all crash so that the platform can detect the crash and restart your app. Second, multiple processes in the container makes it harder to reason about available memory, be especially careful if you're running a Java app. Lastly, only the supply script will run for non-final buildpacks. If you need finalize to run for a non-final buildpack, like to get the proper Java start command, then that's not going to be easy.

Hope that helps!

Dan


Re: Buildpack deep dive questions...

Daniel Mikusa
 

On Mon, Mar 25, 2019 at 10:45 AM Cade Thacker <cade@...> wrote:
Long time reader... first time poster :D 

I'm really digging and deconstruction a few different buildpacks trying to understand how they really work.  supply, compile, detect, etc.  Especially the multi buildpack POV. 

So I think i'm starting to get the details straight but I have some basic architecture questions. 

1) For example, if the core functionality of the buildpack is a compiled app (like go or java) and not a scripted language but the github repo only contains the source code then somewhere in this process it must be compiled.  If I want to use the buildpack as an online buildpack that means that the buildpack has to be "built" after it is cloned down during staging.  Is this the correct path?  Or should it be built and the binary pushed back with the code into github? This seems wrong. Somebody hit me with the clue stick. 

If your buildpack itself needs to be compiled, you have two choices:

1.) Compile locally, package a buildpack and install with `cf create-buildpack`.
2.) Use a shim script to build then run your buildpack. If you want to support `cf push -b https://git-url/my-buildpack` then you have to do this.


and the script it runs to install Golang.

 

2) Second, somewhat tangent question. I know that CloudFoundry is doing tons of work around envoy/istio, but we have a more pressing need right now.  My company has a need to connect many apps and CloudFoundry is just one small part of our runtime. Would it be possible to write a final build pack for envoy and have it basically bind to PORT and then pass the calls to whatever was the 2nd to last buildpack? java, ruby, go, etc.  Forgive me if this is a silly question, but trying to find the edge of this new multi build pack world. Need to inject some custom ingress/egress rules. 

The final buildpack can basically do what ever it wants, since it gets to dictate the start command. If you want it to start Envoy + some other stuff you can do that. A couple things to keep in mind. First, if you're starting multiple processes in the app container you need to manage them. If one fails, you need to make it so that they all fail, or you'll have unexpected behavior. For example, if Envoy is running but your second process, presumably your actual app, crashes then you need to make sure they all crash so that the platform can detect the crash and restart your app. Second, multiple processes in the container makes it harder to reason about available memory, be especially careful if you're running a Java app. Lastly, only the supply script will run for non-final buildpacks. If you need finalize to run for a non-final buildpack, like to get the proper Java start command, then that's not going to be easy.

Hope that helps!

Dan


Re: Mapping ORGs and Space permissions via LDAP

Mark Coumounduros
 

Hello Cloud Foundry:

Just checking back on whether there are ways to control access to org or spaces using UAA scopes (i.e., mapping LDAP Groups to Cloud Foundry Orgs and/or Spaces).

I last posted to the community back in Feb 2017 and am hoping this feature is now enabled for end users (or forthcoming).  Cheers!

NOTICE: [dotnet-core-buildpack] End of support for Node.js 6.x after 2019-04-28

Elliott Shanks
 

The default version of Node.js in the dotnet-core buildpack will change from the latest 6.x version to the latest 10.x version in the first release of the dotnet-core buildpack after April 28, 2019. Due to the end of upstream support for Node.js 6.x in April, all buildpack users should ensure that their dotnet-core apps run on a minimum buildpack supported version of Node.js 10.x or later.

For more information about Node.js 10.x or LTS timelines for 10.x, refer to: https://github.com/nodejs/Release

For more information about supported Node.js versions in the .NET-core buildpack, refer to: https://buildpacks.cloudfoundry.org/#/buildpacks


--
Respectfully, 

Elliott Shanks
CF Buildpacks PM

NOTICE: [Ruby-buildpack] End of support for Node.js 6.x after 2019-04-28

Elliott Shanks
 

The default version of Node.js in the Ruby buildpack will change from the latest 6.x version to the latest 10.x version in the first release of the Ruby buildpack after April 28, 2019. Due to the end of upstream support for Node.js 6.x in April, all buildpack users should ensure that their Ruby apps run on a minimum buildpack supported version of Node.js 10.x or later.

For more information about Node.js 10.x or LTS timelines for 10.x, refer to: https://github.com/nodejs/Release

For more information about supported Node.js versions in the Ruby buildpack, refer to: https://buildpacks.cloudfoundry.org/#/buildpacks


--
Respectfully, 

Elliott Shanks
CF Buildpacks PM

Re: What do admins expect to see in "cf marketplace?"

Oleksii Fedorov
 

Thank you all for your replies and input!

We’ve decided to go forward with treating this as a bug (and not an expected behaviour) and hence not a breaking change. 

Best regards,
Oleksii,
on behalf of SAPI team

PS: If somebody’s scripts/automations are still using `cf marketplace` to list non-available plans, use `cf service-access` instead.

On Tue, Mar 26, 2019 at 8:04 PM Sascha Matzke <sascha.matzke@...> wrote:
Hi,

I'm totally in favour of fixing this. The current behaviour always felt wrong and I'm looking forward to the change. 

Best,

Sascha

On Mon, Mar 25, 2019 at 11:25 AM Oleksii Fedorov <ofedorov@...> wrote:
Hey, friends!

Following up on this one more time before we make a decision (currently favouring that this is not a breaking change). We’ll make a decision how to move forward with this issue this Thursday 25 Mar at 5pm ET.

If you have any concerns, please tell us!

Best regards,
Oleksii
on behalf of SAPI team


On Fri, Mar 15, 2019 at 12:04 PM Oleksii Fedorov <ofedorov@...> wrote:
Hello, folks!

We’re considering fixing the bug reported here https://github.com/cloudfoundry/cli/issues/967

We understand that this is just one side of the coin: some admins confused about output of cf marketplace including all the plans (even disabled ones).

The question is if we fix it and admins will see only plans that are “usable” in the current space, will you be confused by that new behaviour? Will it break any of your scripts?

We’re thinking it’s just a bug fix, but maybe it’s a breaking change. And we’re it actually makes sense to do it at all. What do you think?

Best regards, 
Oleksii, Niki, and Alex
on behalf of SAPI team



--
Oleksii Fedorov
Senior Software Engineer
Pivotal Labs, Berlin
DE: +49 15757 486 476




--
Oleksii Fedorov
Senior Software Engineer
Pivotal Labs, Berlin
DE: +49 15757 486 476

Re: What do admins expect to see in "cf marketplace?"

Sascha Matzke
 

Hi,

I'm totally in favour of fixing this. The current behaviour always felt wrong and I'm looking forward to the change. 

Best,

Sascha

On Mon, Mar 25, 2019 at 11:25 AM Oleksii Fedorov <ofedorov@...> wrote:
Hey, friends!

Following up on this one more time before we make a decision (currently favouring that this is not a breaking change). We’ll make a decision how to move forward with this issue this Thursday 25 Mar at 5pm ET.

If you have any concerns, please tell us!

Best regards,
Oleksii
on behalf of SAPI team


On Fri, Mar 15, 2019 at 12:04 PM Oleksii Fedorov <ofedorov@...> wrote:
Hello, folks!

We’re considering fixing the bug reported here https://github.com/cloudfoundry/cli/issues/967

We understand that this is just one side of the coin: some admins confused about output of cf marketplace including all the plans (even disabled ones).

The question is if we fix it and admins will see only plans that are “usable” in the current space, will you be confused by that new behaviour? Will it break any of your scripts?

We’re thinking it’s just a bug fix, but maybe it’s a breaking change. And we’re it actually makes sense to do it at all. What do you think?

Best regards, 
Oleksii, Niki, and Alex
on behalf of SAPI team



--
Oleksii Fedorov
Senior Software Engineer
Pivotal Labs, Berlin
DE: +49 15757 486 476


Re: What do admins expect to see in "cf marketplace?"

Dave Ashby
 

Can't talk now.

On Mar 26, 2019 6:02 AM, Oleksii Fedorov <ofedorov@...> wrote:
Sorry, the calendar was all mixed up, it’s Thursday 28.03

On Mon, Mar 25, 2019 at 6:17 PM Oleksii Fedorov <ofedorov@...> wrote:
Of course, we’re just trying “to play the card” that the original behaviour was a bug in the first place.

As an admin, If you want to see enabled and disabled plans as a result of the same command, you should use `cf service-access` and **not** `cf marketplace`.

Best regards,
Oleksii

On Mon, Mar 25, 2019 at 3:05 PM Norm Abramovitz <norm@...> wrote:
If you take the conservative approach it would be a breaking change. 

We have a tool that validates the CF environment after deployment. In our use case, the service exists with plans x, y, z but plan z is disabled.   As long as we can get enabled and disabled plans in some way. that would be good enough.




On Mon, Mar 25, 2019 at 3:25 AM Oleksii Fedorov <ofedorov@...> wrote:
Hey, friends!

Following up on this one more time before we make a decision (currently favouring that this is not a breaking change). We’ll make a decision how to move forward with this issue this Thursday 25 Mar at 5pm ET.

If you have any concerns, please tell us!

Best regards,
Oleksii
on behalf of SAPI team


On Fri, Mar 15, 2019 at 12:04 PM Oleksii Fedorov <ofedorov@...> wrote:
Hello, folks!

We’re considering fixing the bug reported here https://github.com/cloudfoundry/cli/issues/967

We understand that this is just one side of the coin: some admins confused about output of cf marketplace including all the plans (even disabled ones).

The question is if we fix it and admins will see only plans that are “usable” in the current space, will you be confused by that new behaviour? Will it break any of your scripts?

We’re thinking it’s just a bug fix, but maybe it’s a breaking change. And we’re it actually makes sense to do it at all. What do you think?

Best regards, 
Oleksii, Niki, and Alex
on behalf of SAPI team



--
Oleksii Fedorov
Senior Software Engineer
Pivotal Labs, Berlin
DE: +49 15757 486 476



--
Norman Abramovitz
Technical Director
Stark & Wayne, LLC





--
Oleksii Fedorov
Senior Software Engineer
Pivotal Labs, Berlin
DE: +49 15757 486 476



--
Oleksii Fedorov
Senior Software Engineer
Pivotal Labs, Berlin
DE: +49 15757 486 476

Re: What do admins expect to see in "cf marketplace?"

Oleksii Fedorov
 

Sorry, the calendar was all mixed up, it’s Thursday 28.03


On Mon, Mar 25, 2019 at 6:17 PM Oleksii Fedorov <ofedorov@...> wrote:
Of course, we’re just trying “to play the card” that the original behaviour was a bug in the first place.

As an admin, If you want to see enabled and disabled plans as a result of the same command, you should use `cf service-access` and **not** `cf marketplace`.

Best regards,
Oleksii

On Mon, Mar 25, 2019 at 3:05 PM Norm Abramovitz <norm@...> wrote:
If you take the conservative approach it would be a breaking change. 

We have a tool that validates the CF environment after deployment. In our use case, the service exists with plans x, y, z but plan z is disabled.   As long as we can get enabled and disabled plans in some way. that would be good enough.




On Mon, Mar 25, 2019 at 3:25 AM Oleksii Fedorov <ofedorov@...> wrote:
Hey, friends!

Following up on this one more time before we make a decision (currently favouring that this is not a breaking change). We’ll make a decision how to move forward with this issue this Thursday 25 Mar at 5pm ET.

If you have any concerns, please tell us!

Best regards,
Oleksii
on behalf of SAPI team


On Fri, Mar 15, 2019 at 12:04 PM Oleksii Fedorov <ofedorov@...> wrote:
Hello, folks!

We’re considering fixing the bug reported here https://github.com/cloudfoundry/cli/issues/967

We understand that this is just one side of the coin: some admins confused about output of cf marketplace including all the plans (even disabled ones).

The question is if we fix it and admins will see only plans that are “usable” in the current space, will you be confused by that new behaviour? Will it break any of your scripts?

We’re thinking it’s just a bug fix, but maybe it’s a breaking change. And we’re it actually makes sense to do it at all. What do you think?

Best regards, 
Oleksii, Niki, and Alex
on behalf of SAPI team



--
Oleksii Fedorov
Senior Software Engineer
Pivotal Labs, Berlin
DE: +49 15757 486 476



--
Norman Abramovitz
Technical Director
Stark & Wayne, LLC





--
Oleksii Fedorov
Senior Software Engineer
Pivotal Labs, Berlin
DE: +49 15757 486 476



--
Oleksii Fedorov
Senior Software Engineer
Pivotal Labs, Berlin
DE: +49 15757 486 476

Re: What do admins expect to see in "cf marketplace?"

Oleksii Fedorov
 

Of course, we’re just trying “to play the card” that the original behaviour was a bug in the first place.

As an admin, If you want to see enabled and disabled plans as a result of the same command, you should use `cf service-access` and **not** `cf marketplace`.

Best regards,
Oleksii

On Mon, Mar 25, 2019 at 3:05 PM Norm Abramovitz <norm@...> wrote:
If you take the conservative approach it would be a breaking change. 

We have a tool that validates the CF environment after deployment. In our use case, the service exists with plans x, y, z but plan z is disabled.   As long as we can get enabled and disabled plans in some way. that would be good enough.




On Mon, Mar 25, 2019 at 3:25 AM Oleksii Fedorov <ofedorov@...> wrote:
Hey, friends!

Following up on this one more time before we make a decision (currently favouring that this is not a breaking change). We’ll make a decision how to move forward with this issue this Thursday 25 Mar at 5pm ET.

If you have any concerns, please tell us!

Best regards,
Oleksii
on behalf of SAPI team


On Fri, Mar 15, 2019 at 12:04 PM Oleksii Fedorov <ofedorov@...> wrote:
Hello, folks!

We’re considering fixing the bug reported here https://github.com/cloudfoundry/cli/issues/967

We understand that this is just one side of the coin: some admins confused about output of cf marketplace including all the plans (even disabled ones).

The question is if we fix it and admins will see only plans that are “usable” in the current space, will you be confused by that new behaviour? Will it break any of your scripts?

We’re thinking it’s just a bug fix, but maybe it’s a breaking change. And we’re it actually makes sense to do it at all. What do you think?

Best regards, 
Oleksii, Niki, and Alex
on behalf of SAPI team



--
Oleksii Fedorov
Senior Software Engineer
Pivotal Labs, Berlin
DE: +49 15757 486 476



--
Norman Abramovitz
Technical Director
Stark & Wayne, LLC





--
Oleksii Fedorov
Senior Software Engineer
Pivotal Labs, Berlin
DE: +49 15757 486 476

Buildpack deep dive questions...

Cade Thacker
 

Long time reader... first time poster :D 

I'm really digging and deconstruction a few different buildpacks trying to understand how they really work.  supply, compile, detect, etc.  Especially the multi buildpack POV. 

So I think i'm starting to get the details straight but I have some basic architecture questions. 

1) For example, if the core functionality of the buildpack is a compiled app (like go or java) and not a scripted language but the github repo only contains the source code then somewhere in this process it must be compiled.  If I want to use the buildpack as an online buildpack that means that the buildpack has to be "built" after it is cloned down during staging.  Is this the correct path?  Or should it be built and the binary pushed back with the code into github? This seems wrong. Somebody hit me with the clue stick. 

2) Second, somewhat tangent question. I know that CloudFoundry is doing tons of work around envoy/istio, but we have a more pressing need right now.  My company has a need to connect many apps and CloudFoundry is just one small part of our runtime. Would it be possible to write a final build pack for envoy and have it basically bind to PORT and then pass the calls to whatever was the 2nd to last buildpack? java, ruby, go, etc.  Forgive me if this is a silly question, but trying to find the edge of this new multi build pack world. Need to inject some custom ingress/egress rules. 

-- 
--cade

Re: What do admins expect to see in "cf marketplace?"

Norm Abramovitz
 

If you take the conservative approach it would be a breaking change. 

We have a tool that validates the CF environment after deployment. In our use case, the service exists with plans x, y, z but plan z is disabled.   As long as we can get enabled and disabled plans in some way. that would be good enough.




On Mon, Mar 25, 2019 at 3:25 AM Oleksii Fedorov <ofedorov@...> wrote:
Hey, friends!

Following up on this one more time before we make a decision (currently favouring that this is not a breaking change). We’ll make a decision how to move forward with this issue this Thursday 25 Mar at 5pm ET.

If you have any concerns, please tell us!

Best regards,
Oleksii
on behalf of SAPI team


On Fri, Mar 15, 2019 at 12:04 PM Oleksii Fedorov <ofedorov@...> wrote:
Hello, folks!

We’re considering fixing the bug reported here https://github.com/cloudfoundry/cli/issues/967

We understand that this is just one side of the coin: some admins confused about output of cf marketplace including all the plans (even disabled ones).

The question is if we fix it and admins will see only plans that are “usable” in the current space, will you be confused by that new behaviour? Will it break any of your scripts?

We’re thinking it’s just a bug fix, but maybe it’s a breaking change. And we’re it actually makes sense to do it at all. What do you think?

Best regards, 
Oleksii, Niki, and Alex
on behalf of SAPI team



--
Oleksii Fedorov
Senior Software Engineer
Pivotal Labs, Berlin
DE: +49 15757 486 476



--
Norman Abramovitz
Technical Director
Stark & Wayne, LLC



Re: What do admins expect to see in "cf marketplace?"

Oleksii Fedorov
 

Hey, friends!

Following up on this one more time before we make a decision (currently favouring that this is not a breaking change). We’ll make a decision how to move forward with this issue this Thursday 25 Mar at 5pm ET.

If you have any concerns, please tell us!

Best regards,
Oleksii
on behalf of SAPI team


On Fri, Mar 15, 2019 at 12:04 PM Oleksii Fedorov <ofedorov@...> wrote:
Hello, folks!

We’re considering fixing the bug reported here https://github.com/cloudfoundry/cli/issues/967

We understand that this is just one side of the coin: some admins confused about output of cf marketplace including all the plans (even disabled ones).

The question is if we fix it and admins will see only plans that are “usable” in the current space, will you be confused by that new behaviour? Will it break any of your scripts?

We’re thinking it’s just a bug fix, but maybe it’s a breaking change. And we’re it actually makes sense to do it at all. What do you think?

Best regards, 
Oleksii, Niki, and Alex
on behalf of SAPI team



--
Oleksii Fedorov
Senior Software Engineer
Pivotal Labs, Berlin
DE: +49 15757 486 476

Re: Request for Feedback: "Scaling Cloud Controller" guidance document

Dieu Cao <dcao@...>
 

Woohoo! I can't begin to convey how excited I am about this as a former CAPI PM.

-Dieu

On Fri, Mar 22, 2019 at 10:44 AM Tim Downey <tdowney@...> wrote:
Hello,

The CAPI team has been working on a document to give operators some guidance with regards to knowing when and how to scale their Cloud Controllers (and related jobs in capi-release) based on our team's experience. 

A draft version of the "Scaling Cloud Controller" document can be viewed here:

Our intent is to work with the Docs team and get this added as part of the Running Cloud Foundry operator docs, but first we'd welcome and appreciate any feedback from the CF operator community. Feel free to respond to this post or submit an issue/PR with suggestions for the draft document.

Thanks!
CF CAPI Team

Request for Feedback: "Scaling Cloud Controller" guidance document

Tim Downey
 

Hello,

The CAPI team has been working on a document to give operators some guidance with regards to knowing when and how to scale their Cloud Controllers (and related jobs in capi-release) based on our team's experience. 

A draft version of the "Scaling Cloud Controller" document can be viewed here:

Our intent is to work with the Docs team and get this added as part of the Running Cloud Foundry operator docs, but first we'd welcome and appreciate any feedback from the CF operator community. Feel free to respond to this post or submit an issue/PR with suggestions for the draft document.

Thanks!
CF CAPI Team

istio-release 1.2.0

Wa Gao
 

Hello, 

We have cut istio-release 1.2.0. With this release in addition to weighted routing, we now support envoys sidecars configured by Istio Pilot for app to app communication. We also have support for client-side load balancing, retries and timeouts for app to app communication. We are working on the docs to run the book-info app on CF and will keep you posted. 

The release highlights include the following features. 

  • app developers can rely on the platform to provide timeouts for app to app communication, timeout default is currently set to 15s and not modifiable details
  • istio-release versioning now uses semver versions and not the whole number versions details
  • performance improvement to allow operators to run many apps by temporarily disabling stats logging (reduces envoy RAM consumption) details
  • we have now added a Contributing section to istio-release details
  • fix issue with retries such that application developers can rely on the platform to provide retries for app to app communication details
  • performance and security: only internal routes are published to sidecar envoys and external routes to the envoy gateway details
  • Copilot uses new MCP details
  • Changed pilot to use role~ip~id~dns.domain for the Envoy service node field details
  • operator can set spec property for pilot_log_level details
  • Bump istio to 1.1 in istio-release details
  • developer can see traffic equally distributed when they map an internal route to three apps on the same port details
  • operators can specify the DNS address of the MCP Client Pilot connects to details

 CF-Networking