Date   

Re: Concourse OAuth on runtime.ci.cf-app.com

Christopher Piraino <cpiraino@...>
 

Woops, thought I was responding to Gabe. Disregard. :)

On Mon, Nov 9, 2015 at 5:29 PM, Christopher Piraino <cpiraino(a)pivotal.io>
wrote:

The routing team would like access! I see the OAuth is through Github, do
you need github handles or can you add teams?

- Chris

On Mon, Nov 9, 2015 at 5:05 PM, Gabriel Rosenhouse <grosenhouse(a)pivotal.io
wrote:
Hi all,

We've enabled OAuth login to https://runtime.ci.cf-app.com

Currently this is in addition to basic auth. We plan to eventually
retire basic auth.

The MEGA and CAPI teams have access via OAuth. Let us know if your team
also needs access.

Regards,

Gabe & Zak A.
MEGA team


Re: Concourse OAuth on runtime.ci.cf-app.com

Christopher Piraino <cpiraino@...>
 

The routing team would like access! I see the OAuth is through Github, do
you need github handles or can you add teams?

- Chris

On Mon, Nov 9, 2015 at 5:05 PM, Gabriel Rosenhouse <grosenhouse(a)pivotal.io>
wrote:

Hi all,

We've enabled OAuth login to https://runtime.ci.cf-app.com

Currently this is in addition to basic auth. We plan to eventually retire
basic auth.

The MEGA and CAPI teams have access via OAuth. Let us know if your team
also needs access.

Regards,

Gabe & Zak A.
MEGA team


Concourse OAuth on runtime.ci.cf-app.com

Gabriel Rosenhouse <grosenhouse@...>
 

Hi all,

We've enabled OAuth login to https://runtime.ci.cf-app.com

Currently this is in addition to basic auth. We plan to eventually retire
basic auth.

The MEGA and CAPI teams have access via OAuth. Let us know if your team
also needs access.

Regards,

Gabe & Zak A.
MEGA team


Re: [buildpacks] CF-built binaries: release timeline and beta testing

Shawn Nielsen
 

Mike,

Thanks for the quick reply.

My question is more around using an 'online' buildpack vs. 'offline'.
When I say 'online', I'm referring to the binaries being pulled from the s3
repo at staging time.

If we use the offline buildpack binaries, we are restricted to node
versions explicitly defined in the manifest files. This creates some
issues when projects want to do validation testing between one version and
the next or need to roll back for whatever reason. It also requires us to
manually update the buildpack every time there is a new release. We've
historically used the online buildpacks to prevent these types of issues,
but we'd like to better understand Pivotal's long term strategy here.

Going forward, what is Pivotal's strategy for online binaries that would be
used at staging time?

-Shawn

On Mon, Nov 9, 2015 at 4:03 PM, Mike Dalessio <mdalessio(a)pivotal.io> wrote:

Hi Shawn,

Thanks for asking.

The actual URL used is going to depend on what version of the buildpack
you're using. Currently master (v1.5.1) is only referncing CF-generated
binaries:

https://github.com/cloudfoundry/nodejs-buildpack/blob/master/manifest.yml

We removed references to s3pository.heroku.com in February, for v1.2.0 of
the buildpack.

Let me know if you need more context around this. Thanks!

-mike


On Mon, Nov 9, 2015 at 4:40 PM, Shawn Nielsen <sknielse(a)gmail.com> wrote:

James,

It looks like the online NodeJS buildpack is currently pointing to
Heroku's repo:
http://s3pository.heroku.com/node/...

Whereas the offline NodeJS buildpack manifest files seems to be pointing
to pivotal's repo:
https://pivotal-buildpacks.s3.amazonaws.com/concourse-binaries/node/...

Is there a reason for this discrepency?

I would think the online NodeJS buildpack should be pointing to the same
pivotal repo as the offline:
https://pivotal-buildpacks.s3.amazonaws.com/concourse-binaries/node/...


Let me know if you have any input here. Thanks,

-Shawn


On Fri, Jul 17, 2015 at 11:46 PM, James Bayer <jbayer(a)pivotal.io> wrote:

mike d is the best to answer, but i'll take a crack at it

On Fri, Jul 17, 2015 at 3:24 PM, Shawn Nielsen <sknielse(a)gmail.com>
wrote:

Two questions on these cf-built binaries:

1. From my understanding, the purpose of this is to compile the
binaries so they are optimized for the cf specific stacks (e.g.
cflinuxfs2 ) as opposed to something that was generically compiled
(e.g. to 64 bit trusty). Can you confirm this or expound upon this if
there are other reasons?
for some buildpacks, we have been relying on heroku binaries which is an
external dependency. we want the cf team to be in complete control of how
and when the binaries are built. this ensures cf can be in control of our
own destiny when for patching security issues or bugs. additionally it
means cf can take responsibility for how the binaries are compiled to
increase trust of the binary contents.



2. Are these binaries available in offline mode only or is there also
intent that they will be hosted, allowing us to consume them in an online
mode?
most/all cf buildpacks are available in online and offline mode as i
understand it. see:
https://github.com/cloudfoundry-incubator/buildpack-packager/blob/master/doc/disconnected_environments.md



Thanks,

-Shawn

On Mon, Jul 13, 2015 at 2:08 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:



On Mon, Jul 13, 2015 at 1:08 PM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

On Wed, Jul 8, 2015 at 1:55 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:

Hi all,

In the June CAB call, it was mentioned that the Buildpacks team was
working on generating CF-specific binaries to be packaged in the
buildpacks. I'm pleased to announce that the team is ready to start
shipping these binaries in the golang, nodejs, php, python, and ruby
buildpacks for the cflinuxfs2 stack.

*__We're planning to cut releases of these buildpacks with the CF*
*binaries on Monday, 20 July.__*

In the meantime, I'd like to ask the community to beta these
buildpacks and give us feedback.

We're successfully running [BRATs][1] (the buildpack runtime
acceptance tests) on these binaries, so we don't expect any issues; but
we'd love to hear if anyone experiences any issues deploying their apps.

Obviously, until we cut official releases, you should use judgement
when deciding where to use these beta buildpacks.

[1]: https://github.com/cloudfoundry/brats


*## Timeline, Versioning and Proposed Changes*

Unless we hear of any blocking issues, we'll cut official releases
of the go, node, php, python and ruby buildpacks on July 20th.

When we cut these releases, we'll be bumping the major version
number, and removing the `manifest-including-unsupported.yml` file from the
repository HEAD. I'd love to hear anyone's opinion on these changes as well.


*## How to deploy with the "beta" binary buildpacks*

Until we cut official releases, we are maintaining a git branch in
each buildpack repository, named `cf-binary-beta`, in which the manifest
points at our CF-specific binaries.

If your CF deployment has access to the public internet, you can
push your app and specify the github repo and branch with the `-b` option.

*__Go:__*

`cf push <appname> -b
https://github.com/cloudfoundry/go-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/go-buildpack#cf-binary-beta>

*__Node:__*

`cf push <appname> -b
https://github.com/cloudfoundry/nodejs-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/nodejs-buildpack#cf-binary-beta>

*__PHP:__*

`cf push <appname> -b
https://github.com/cloudfoundry/php-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/php-buildpack#cf-binary-beta>
Looks good mostly. One minor issue. It seems like the snmp
extension is not loading correctly. Looks to be missing a required shared
library.

2015-07-13T12:29:53.09-0400 [App/0] OUT 16:29:53 php-fpm |
[13-Jul-2015 16:29:53] NOTICE: PHP message: PHP Warning: PHP Startup:
Unable to load dynamic library
'/home/vcap/app/php/lib/php/extensions/no-debug-non-zts-20100525/snmp.so' -
libnetsnmp.so.30: cannot open shared object file: No such file or directory
in Unknown on line 0

That's with PHP 5.4.42, 5.5.26 and 5.6.10.
Good catch, I've created a story for this:
https://www.pivotaltracker.com/story/show/98980384





One other thing, which is not really an issue, but perhaps an
optimization. I noticed for the PHP extensions the bundle has both ".a"
and ".so" files for many of the extensions. The ".a" static libraries
should not be necessary, just the ".so" shared libraries. Seems like
removing them could save 8 to 9M. You could save another 25M by deleting
the bin/php-cgi file. You really only need bin/php for cmd line stuff and
sbin/php-fpm for web apps. Can't think of any reason you'd need / want to
do cgi. It's not a ton of space, 35M X 3 (each current version) + 35M X 3
(each of previous versions) - whatever compression will save. Just thought
I'd throw it out there though.

Another good catch, I've created a story to look into it:
https://www.pivotaltracker.com/story/show/98980692




Dan




*__Python:__*

`cf push <appname> -b
https://github.com/cloudfoundry/python-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/python-buildpack#cf-binary-beta>

*__Ruby:__*

`cf push <appname> -b
https://github.com/cloudfoundry/ruby-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/ruby-buildpack#cf-binary-beta>


If your CF deployment doesn't have access to the public internet and
you'd like to try these buildpacks, please reach out directly and we'll
figure out the best way to accommodate.


*## Tooling Details*

If you'd like to take a look at how we're currently building these
binaries, our tooling is open-sourced at:

https://github.com/cloudfoundry/binary-builder
Note that `binary-builder` uses the rootfs docker image to compile
each binary, which means that this tool can easily be extended to
essentially cross-compile **any** binary for a CF rootfs. We'd love
to hear your feedback on this, as well.


Thanks,
-mike



_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Cloud Controller - s3 encryption for droplets

William C Penrod
 

The blobstore properties in bosh allows you to enter an encryption key to encrypt the data before it is pushed up to an s3 bucket. In the cloud foundry deploy, can this encryption property be added for the s3 connection in the cloud controller for droplets?


Re: [buildpacks] CF-built binaries: release timeline and beta testing

Mike Dalessio
 

Hi Shawn,

Thanks for asking.

The actual URL used is going to depend on what version of the buildpack
you're using. Currently master (v1.5.1) is only referncing CF-generated
binaries:

https://github.com/cloudfoundry/nodejs-buildpack/blob/master/manifest.yml
We removed references to s3pository.heroku.com in February, for v1.2.0 of
the buildpack.

Let me know if you need more context around this. Thanks!

-mike


On Mon, Nov 9, 2015 at 4:40 PM, Shawn Nielsen <sknielse(a)gmail.com> wrote:

James,

It looks like the online NodeJS buildpack is currently pointing to
Heroku's repo:
http://s3pository.heroku.com/node/...

Whereas the offline NodeJS buildpack manifest files seems to be pointing
to pivotal's repo:
https://pivotal-buildpacks.s3.amazonaws.com/concourse-binaries/node/...

Is there a reason for this discrepency?

I would think the online NodeJS buildpack should be pointing to the same
pivotal repo as the offline:
https://pivotal-buildpacks.s3.amazonaws.com/concourse-binaries/node/...


Let me know if you have any input here. Thanks,

-Shawn


On Fri, Jul 17, 2015 at 11:46 PM, James Bayer <jbayer(a)pivotal.io> wrote:

mike d is the best to answer, but i'll take a crack at it

On Fri, Jul 17, 2015 at 3:24 PM, Shawn Nielsen <sknielse(a)gmail.com>
wrote:

Two questions on these cf-built binaries:

1. From my understanding, the purpose of this is to compile the
binaries so they are optimized for the cf specific stacks (e.g.
cflinuxfs2 ) as opposed to something that was generically compiled
(e.g. to 64 bit trusty). Can you confirm this or expound upon this if
there are other reasons?
for some buildpacks, we have been relying on heroku binaries which is an
external dependency. we want the cf team to be in complete control of how
and when the binaries are built. this ensures cf can be in control of our
own destiny when for patching security issues or bugs. additionally it
means cf can take responsibility for how the binaries are compiled to
increase trust of the binary contents.



2. Are these binaries available in offline mode only or is there also
intent that they will be hosted, allowing us to consume them in an online
mode?
most/all cf buildpacks are available in online and offline mode as i
understand it. see:
https://github.com/cloudfoundry-incubator/buildpack-packager/blob/master/doc/disconnected_environments.md



Thanks,

-Shawn

On Mon, Jul 13, 2015 at 2:08 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:



On Mon, Jul 13, 2015 at 1:08 PM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

On Wed, Jul 8, 2015 at 1:55 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:

Hi all,

In the June CAB call, it was mentioned that the Buildpacks team was
working on generating CF-specific binaries to be packaged in the
buildpacks. I'm pleased to announce that the team is ready to start
shipping these binaries in the golang, nodejs, php, python, and ruby
buildpacks for the cflinuxfs2 stack.

*__We're planning to cut releases of these buildpacks with the CF*
*binaries on Monday, 20 July.__*

In the meantime, I'd like to ask the community to beta these
buildpacks and give us feedback.

We're successfully running [BRATs][1] (the buildpack runtime
acceptance tests) on these binaries, so we don't expect any issues; but
we'd love to hear if anyone experiences any issues deploying their apps.

Obviously, until we cut official releases, you should use judgement
when deciding where to use these beta buildpacks.

[1]: https://github.com/cloudfoundry/brats


*## Timeline, Versioning and Proposed Changes*

Unless we hear of any blocking issues, we'll cut official releases of
the go, node, php, python and ruby buildpacks on July 20th.

When we cut these releases, we'll be bumping the major version
number, and removing the `manifest-including-unsupported.yml` file from the
repository HEAD. I'd love to hear anyone's opinion on these changes as well.


*## How to deploy with the "beta" binary buildpacks*

Until we cut official releases, we are maintaining a git branch in
each buildpack repository, named `cf-binary-beta`, in which the manifest
points at our CF-specific binaries.

If your CF deployment has access to the public internet, you can push
your app and specify the github repo and branch with the `-b` option.

*__Go:__*

`cf push <appname> -b
https://github.com/cloudfoundry/go-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/go-buildpack#cf-binary-beta>

*__Node:__*

`cf push <appname> -b
https://github.com/cloudfoundry/nodejs-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/nodejs-buildpack#cf-binary-beta>

*__PHP:__*

`cf push <appname> -b
https://github.com/cloudfoundry/php-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/php-buildpack#cf-binary-beta>
Looks good mostly. One minor issue. It seems like the snmp extension
is not loading correctly. Looks to be missing a required shared library.

2015-07-13T12:29:53.09-0400 [App/0] OUT 16:29:53 php-fpm |
[13-Jul-2015 16:29:53] NOTICE: PHP message: PHP Warning: PHP Startup:
Unable to load dynamic library
'/home/vcap/app/php/lib/php/extensions/no-debug-non-zts-20100525/snmp.so' -
libnetsnmp.so.30: cannot open shared object file: No such file or directory
in Unknown on line 0

That's with PHP 5.4.42, 5.5.26 and 5.6.10.
Good catch, I've created a story for this:
https://www.pivotaltracker.com/story/show/98980384





One other thing, which is not really an issue, but perhaps an
optimization. I noticed for the PHP extensions the bundle has both ".a"
and ".so" files for many of the extensions. The ".a" static libraries
should not be necessary, just the ".so" shared libraries. Seems like
removing them could save 8 to 9M. You could save another 25M by deleting
the bin/php-cgi file. You really only need bin/php for cmd line stuff and
sbin/php-fpm for web apps. Can't think of any reason you'd need / want to
do cgi. It's not a ton of space, 35M X 3 (each current version) + 35M X 3
(each of previous versions) - whatever compression will save. Just thought
I'd throw it out there though.

Another good catch, I've created a story to look into it:
https://www.pivotaltracker.com/story/show/98980692




Dan




*__Python:__*

`cf push <appname> -b
https://github.com/cloudfoundry/python-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/python-buildpack#cf-binary-beta>

*__Ruby:__*

`cf push <appname> -b
https://github.com/cloudfoundry/ruby-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/ruby-buildpack#cf-binary-beta>


If your CF deployment doesn't have access to the public internet and
you'd like to try these buildpacks, please reach out directly and we'll
figure out the best way to accommodate.


*## Tooling Details*

If you'd like to take a look at how we're currently building these
binaries, our tooling is open-sourced at:

https://github.com/cloudfoundry/binary-builder
Note that `binary-builder` uses the rootfs docker image to compile
each binary, which means that this tool can easily be extended to
essentially cross-compile **any** binary for a CF rootfs. We'd love
to hear your feedback on this, as well.


Thanks,
-mike



_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: [buildpacks] CF-built binaries: release timeline and beta testing

Shawn Nielsen
 

James,

It looks like the online NodeJS buildpack is currently pointing to Heroku's
repo:
http://s3pository.heroku.com/node/...

Whereas the offline NodeJS buildpack manifest files seems to be pointing to
pivotal's repo:
https://pivotal-buildpacks.s3.amazonaws.com/concourse-binaries/node/...

Is there a reason for this discrepency?

I would think the online NodeJS buildpack should be pointing to the same
pivotal repo as the offline:
https://pivotal-buildpacks.s3.amazonaws.com/concourse-binaries/node/...


Let me know if you have any input here. Thanks,

-Shawn

On Fri, Jul 17, 2015 at 11:46 PM, James Bayer <jbayer(a)pivotal.io> wrote:

mike d is the best to answer, but i'll take a crack at it

On Fri, Jul 17, 2015 at 3:24 PM, Shawn Nielsen <sknielse(a)gmail.com> wrote:

Two questions on these cf-built binaries:

1. From my understanding, the purpose of this is to compile the binaries
so they are optimized for the cf specific stacks (e.g. cflinuxfs2 ) as
opposed to something that was generically compiled (e.g. to 64 bit
trusty). Can you confirm this or expound upon this if there are other
reasons?
for some buildpacks, we have been relying on heroku binaries which is an
external dependency. we want the cf team to be in complete control of how
and when the binaries are built. this ensures cf can be in control of our
own destiny when for patching security issues or bugs. additionally it
means cf can take responsibility for how the binaries are compiled to
increase trust of the binary contents.



2. Are these binaries available in offline mode only or is there also
intent that they will be hosted, allowing us to consume them in an online
mode?
most/all cf buildpacks are available in online and offline mode as i
understand it. see:
https://github.com/cloudfoundry-incubator/buildpack-packager/blob/master/doc/disconnected_environments.md



Thanks,

-Shawn

On Mon, Jul 13, 2015 at 2:08 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:



On Mon, Jul 13, 2015 at 1:08 PM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

On Wed, Jul 8, 2015 at 1:55 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:

Hi all,

In the June CAB call, it was mentioned that the Buildpacks team was
working on generating CF-specific binaries to be packaged in the
buildpacks. I'm pleased to announce that the team is ready to start
shipping these binaries in the golang, nodejs, php, python, and ruby
buildpacks for the cflinuxfs2 stack.

*__We're planning to cut releases of these buildpacks with the CF*
*binaries on Monday, 20 July.__*

In the meantime, I'd like to ask the community to beta these
buildpacks and give us feedback.

We're successfully running [BRATs][1] (the buildpack runtime
acceptance tests) on these binaries, so we don't expect any issues; but
we'd love to hear if anyone experiences any issues deploying their apps.

Obviously, until we cut official releases, you should use judgement
when deciding where to use these beta buildpacks.

[1]: https://github.com/cloudfoundry/brats


*## Timeline, Versioning and Proposed Changes*

Unless we hear of any blocking issues, we'll cut official releases of
the go, node, php, python and ruby buildpacks on July 20th.

When we cut these releases, we'll be bumping the major version number,
and removing the `manifest-including-unsupported.yml` file from the
repository HEAD. I'd love to hear anyone's opinion on these changes as well.


*## How to deploy with the "beta" binary buildpacks*

Until we cut official releases, we are maintaining a git branch in
each buildpack repository, named `cf-binary-beta`, in which the manifest
points at our CF-specific binaries.

If your CF deployment has access to the public internet, you can push
your app and specify the github repo and branch with the `-b` option.

*__Go:__*

`cf push <appname> -b
https://github.com/cloudfoundry/go-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/go-buildpack#cf-binary-beta>

*__Node:__*

`cf push <appname> -b
https://github.com/cloudfoundry/nodejs-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/nodejs-buildpack#cf-binary-beta>

*__PHP:__*

`cf push <appname> -b
https://github.com/cloudfoundry/php-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/php-buildpack#cf-binary-beta>
Looks good mostly. One minor issue. It seems like the snmp extension
is not loading correctly. Looks to be missing a required shared library.

2015-07-13T12:29:53.09-0400 [App/0] OUT 16:29:53 php-fpm |
[13-Jul-2015 16:29:53] NOTICE: PHP message: PHP Warning: PHP Startup:
Unable to load dynamic library
'/home/vcap/app/php/lib/php/extensions/no-debug-non-zts-20100525/snmp.so' -
libnetsnmp.so.30: cannot open shared object file: No such file or directory
in Unknown on line 0

That's with PHP 5.4.42, 5.5.26 and 5.6.10.
Good catch, I've created a story for this:
https://www.pivotaltracker.com/story/show/98980384





One other thing, which is not really an issue, but perhaps an
optimization. I noticed for the PHP extensions the bundle has both ".a"
and ".so" files for many of the extensions. The ".a" static libraries
should not be necessary, just the ".so" shared libraries. Seems like
removing them could save 8 to 9M. You could save another 25M by deleting
the bin/php-cgi file. You really only need bin/php for cmd line stuff and
sbin/php-fpm for web apps. Can't think of any reason you'd need / want to
do cgi. It's not a ton of space, 35M X 3 (each current version) + 35M X 3
(each of previous versions) - whatever compression will save. Just thought
I'd throw it out there though.

Another good catch, I've created a story to look into it:
https://www.pivotaltracker.com/story/show/98980692




Dan




*__Python:__*

`cf push <appname> -b
https://github.com/cloudfoundry/python-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/python-buildpack#cf-binary-beta>

*__Ruby:__*

`cf push <appname> -b
https://github.com/cloudfoundry/ruby-buildpack#cf-binary-beta`
<https://github.com/cloudfoundry/ruby-buildpack#cf-binary-beta>


If your CF deployment doesn't have access to the public internet and
you'd like to try these buildpacks, please reach out directly and we'll
figure out the best way to accommodate.


*## Tooling Details*

If you'd like to take a look at how we're currently building these
binaries, our tooling is open-sourced at:

https://github.com/cloudfoundry/binary-builder
Note that `binary-builder` uses the rootfs docker image to compile
each binary, which means that this tool can easily be extended to
essentially cross-compile **any** binary for a CF rootfs. We'd love
to hear your feedback on this, as well.


Thanks,
-mike



_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: multiple nozzles on firehose

Rohit Kumar
 

Hi Lon,

The traffic controller takes a subscription ID as a parameter whenever a
firehose connection is made. If you use the same subscription ID on each
nozzle instance, the firehose will evenly distribute events across all
instances of the nozzle. For example, if you have two nozzles with the same
subscription ID, then half the events will go to one nozzle and half to the
other. Similarly if there were three instances of the nozzle, then each
instance would get one-third the traffic.

Does that help?

Thanks,
Rohit

On Mon, Nov 9, 2015 at 9:39 AM, Nix, Lon <Lon.Nix(a)schwab.com> wrote:

I'm trying to get an idea of how multiple instances of the
firehose-to-syslog app nozzle will interact



Does the firehose act like a queue in the sense that once a nozzle reads a
message its gone from the hose and if there are multiple nozzles will only
one nozzle will read each message at a time? For example, if the messages
in the firehose are A, B, C, and D and two nozzles alternate then the first
nozzle will read A and C and the 2nd nozzle will read B and D. If either
nozzle goes down while reading a message then that message will be lost,
but then that nozzle won’t take any more messages.



Thanks,



--Lon Nix



multiple nozzles on firehose

Nix, Lon <Lon.Nix@...>
 

I'm trying to get an idea of how multiple instances of the firehose-to-syslog app nozzle will interact

Does the firehose act like a queue in the sense that once a nozzle reads a message its gone from the hose and if there are multiple nozzles will only one nozzle will read each message at a time? For example, if the messages in the firehose are A, B, C, and D and two nozzles alternate then the first nozzle will read A and C and the 2nd nozzle will read B and D. If either nozzle goes down while reading a message then that message will be lost, but then that nozzle won't take any more messages.

Thanks,

--Lon Nix


Re: Cloud Foundry NodeJS 4 support and release schedule

Mike Dalessio
 

Hi all,

We recently released nodejs-buildpack v1.5.1
<https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.5.1>
which introduces support for Node.js 4.2.2. The full history of this
support, as well as its limitations, are discussed in depth at this RFC
Github Issue <https://github.com/cloudfoundry/nodejs-buildpack/issues/32>.

Node.js 4.2.2 is the latest (as of 2015-11-06) version on Node's LTS
branch, which we intend to support for the lifetime of the 4.x branch.

We welcome feedback on this version of Node, which you can provide by:

* opening a new Github Issue letting us know about any issues you
experience using it
* commenting on this Github Issue
<https://github.com/cloudfoundry/nodejs-buildpack/issues/32> if you've
tried it and it's working as expected for you
* emailing cf-dev with any comments at all

Thank you!

-mike

On Thu, Sep 10, 2015 at 1:05 PM, Mike Dalessio <mdalessio(a)pivotal.io> wrote:

Quick update on Node 4, which is that we're blocked on openssl
compatibility.

One of the requirements we place on binaries we ship with CF buildpacks is
that libraries should be dynamically linked from the rootfs whenever
possible, particularly for libraries that are likely to be affected by
CVEs, so that we can patch everything with a rootfs update.

Node has defaulted, for quite a while, to statically linking OpenSSL,
despite a history of not-infrequent CVEs affecting that library. The Node
build scripts do allow overriding this, and choosing to dynamically link
instead. We've used this option successfully for building all of the
CF-supported 0.x node versions against the openssl 1.0.1 versions that are
shipped with Ubuntu 14.04 LTS (and therefore the cflinuxfs2 rootfs).

However, in Node 4, the code only supports openssl 1.0.2. That is, it
fails to compile against openssl 1.0.1 headers.

(Possibly worth mentioning for additional context, even RHEL7 appears to
still ship openssl 1.0.1.)

We opened a Github issue on the node project, which has been closed
without a suggested fix for our situation:

https://github.com/nodejs/node/issues/2783

We've also reached out to friends of the CFF at Joyent, and IBM has
notably reached out to their own Node committers on staff. I'll keep this
thread updated as the conversation progresses.

I'm not comfortable introducing a new binary to the CF ecosystem that's
not "patch-able" via a rootfs update. I'm open to suggestions around what
else we could be doing to move towards shipping Node 4, but for right now
we're blocked.

-m



On Wed, Sep 9, 2015 at 3:52 PM, Shawn Nielsen <sknielse(a)gmail.com> wrote:

Thanks for the quick feedback on this, we appreciate your responsiveness.
We'll continue to follow the issue in the pivotal tracker.

On Wed, Sep 9, 2015 at 12:36 PM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:

Hi Shawn,

Great question, thanks for asking it.

The Buildpacks team has a Tracker story in its backlog to work on Node 4:

https://www.pivotaltracker.com/story/show/102941608

Generally our turnaround time on vanilla version updates is less than a
day; however, Node 4 isn't just a regular version update, as it comes from
io.js lineage which we haven't ever officially supported; and so we're
going to proceed carefully.

The story I linked to has some specific acceptance criteria:

* Does the binary build with our current tooling? If not, we'll have to
update our tooling.
* Does the binary dynamically link openssl? (This was a specific use
case we've had to work around in the past.) If not, we'll have to make sure
it does, so that rootfs updates will be sufficient to address openssl CVEs.
* Does the binary avoid statically linking any other rootfs libraries?
If not, see above.
* Does the binary pass BRATs? If not, we'll have to fix BRATs.

Only when all of the above look good will we ship; and since we haven't
worked with io.js and family before, I don't want to make any promises
about delivery. If things go well, it could ship as early as tomorrow,
though that's probably overly optimistic.

Additionally I'll likely delay committing it into cf-release until we
have positive feedback from the community.

I'm happy to keep this thread updated with our progress; or you can
follow along at the Tracker story.

Cheers,
-mike


On Wed, Sep 9, 2015 at 11:33 AM, Shawn Nielsen <sknielse(a)gmail.com>
wrote:

NodeJS version 4 was released yesterday to the community.

Generally speaking, what is the typical release schedule for buildpack
binaries after new runtime releases are announced?

More specifically, I'd be curious if you have information on release
schedule of the NodeJS 4 buildpack binaries.






Re: applications on CF cannot download files from internet

Yitao Jiang
 

Ok, i got it.

I start with 197, but i think you can just verify the iptables of the
warden container

On Mon, Nov 9, 2015 at 10:49 AM, Youzhi Zhu <zhuyouzhi03(a)gmail.com> wrote:

HI Yitao

Thank you for your reply.
since my cf-release version is 170, I checked and found it has not
introduced the security groups concept for this CF version.

2015-11-07 17:04 GMT+08:00 Yitao Jiang <jiangyt.cn(a)gmail.com>:

Maybe the security group block egress requests.
Refer to https://docs.cloudfoundry.org/adminguide/app-sec-groups.html

On Sat, Nov 7, 2015 at 2:24 PM, Youzhi Zhu <zhuyouzhi03(a)gmail.com> wrote:

I deploy My application to my own cloud foundry platform, and the app
needs download some files from internet,but it always failed download, so I
get into the container to do some test with wget, it shows that the
container can connect to internet server but cannot download files.

*vcap(a)193r3tpboqm:~/tmp$ ping www.baidu.com <http://www.baidu.com/>*
*PING www.a.shifen.com <http://www.a.shifen.com/> (180.97.33.107) 56(84)
bytes of data.*
*64 bytes from 180.97.33.107 <http://180.97.33.107/>: icmp_seq=1 ttl=50
time=27.8 ms*
*64 bytes from 180.97.33.107 <http://180.97.33.107/>: icmp_seq=2 ttl=50
time=27.7 ms*
*^C*
*--- www.a.shifen.com <http://www.a.shifen.com/> ping statistics ---*
*2 packets transmitted, 2 received, 0% packet loss, time 1001ms*
*rtt min/avg/max/mdev = 27.740/27.814/27.888/0.074 ms*
*vcap(a)193r3tpboqm:~/tmp$ wget www.baidu.com <http://www.baidu.com/>*
*--2015-11-06 15:25:49-- http://www.baidu.com/ <http://www.baidu.com/>*
*Resolving www.baidu.com... 180.97.33.108, 180.97.33.107*
*Connecting to www.baidu.com
<http://www.baidu.com/>|180.97.33.108|:80... connected.*
*HTTP request sent, awaiting response... 200 OK*
*Length: unspecified [text/html]*
*Saving to: `index.html'*

* [ <=>
]0
--.-K/s *
*vcap(a)193r3tpboqm:~/tmp$ ll | grep index.html *
*-rw-r--r-- 1 vcap vcap 0 2015-11-06 15:25 index.html*
*vcap(a)193r3tpboqm:~/tmp$ *

but the host where dea running can wget files successfully

*root(a)dea03:~# wget www.baidu.com <http://www.baidu.com/>*
*--2015-11-06 23:30:28-- http://www.baidu.com/ <http://www.baidu.com/>*
*Resolving www.baidu.com <http://www.baidu.com/> (www.baidu.com
<http://www.baidu.com/>)... 180.97.33.107, 180.97.33.108*
*Connecting to www.baidu.com <http://www.baidu.com/> (www.baidu.com
<http://www.baidu.com/>)|180.97.33.107|:80... connected.*
*HTTP request sent, awaiting response... 200 OK*
*Length: unspecified [text/html]*
*Saving to: `index.html.1'*

* [ <=>
]
97,308 --.-K/s in 0.09s *

*2015-11-06 23:30:29 (1.03 MB/s) - `index.html.1' saved [97308]*

Does anyone met this situation before? thanks!

my cf version is cf-release170 and the os is Ubuntu 12.04.1 LTS


--

Regards,

Yitao
jiangyt.github.io
--

Regards,

Yitao
jiangyt.github.io


Re: applications on CF cannot download files from internet

Youzhi Zhu
 

HI Yitao

Thank you for your reply.
since my cf-release version is 170, I checked and found it has not
introduced the security groups concept for this CF version.

2015-11-07 17:04 GMT+08:00 Yitao Jiang <jiangyt.cn(a)gmail.com>:

Maybe the security group block egress requests.
Refer to https://docs.cloudfoundry.org/adminguide/app-sec-groups.html

On Sat, Nov 7, 2015 at 2:24 PM, Youzhi Zhu <zhuyouzhi03(a)gmail.com> wrote:

I deploy My application to my own cloud foundry platform, and the app
needs download some files from internet,but it always failed download, so I
get into the container to do some test with wget, it shows that the
container can connect to internet server but cannot download files.

*vcap(a)193r3tpboqm:~/tmp$ ping www.baidu.com <http://www.baidu.com/>*
*PING www.a.shifen.com <http://www.a.shifen.com/> (180.97.33.107) 56(84)
bytes of data.*
*64 bytes from 180.97.33.107 <http://180.97.33.107/>: icmp_seq=1 ttl=50
time=27.8 ms*
*64 bytes from 180.97.33.107 <http://180.97.33.107/>: icmp_seq=2 ttl=50
time=27.7 ms*
*^C*
*--- www.a.shifen.com <http://www.a.shifen.com/> ping statistics ---*
*2 packets transmitted, 2 received, 0% packet loss, time 1001ms*
*rtt min/avg/max/mdev = 27.740/27.814/27.888/0.074 ms*
*vcap(a)193r3tpboqm:~/tmp$ wget www.baidu.com <http://www.baidu.com/>*
*--2015-11-06 15:25:49-- http://www.baidu.com/ <http://www.baidu.com/>*
*Resolving www.baidu.com... 180.97.33.108, 180.97.33.107*
*Connecting to www.baidu.com <http://www.baidu.com/>|180.97.33.108|:80...
connected.*
*HTTP request sent, awaiting response... 200 OK*
*Length: unspecified [text/html]*
*Saving to: `index.html'*

* [ <=>
]0
--.-K/s *
*vcap(a)193r3tpboqm:~/tmp$ ll | grep index.html *
*-rw-r--r-- 1 vcap vcap 0 2015-11-06 15:25 index.html*
*vcap(a)193r3tpboqm:~/tmp$ *

but the host where dea running can wget files successfully

*root(a)dea03:~# wget www.baidu.com <http://www.baidu.com/>*
*--2015-11-06 23:30:28-- http://www.baidu.com/ <http://www.baidu.com/>*
*Resolving www.baidu.com <http://www.baidu.com/> (www.baidu.com
<http://www.baidu.com/>)... 180.97.33.107, 180.97.33.108*
*Connecting to www.baidu.com <http://www.baidu.com/> (www.baidu.com
<http://www.baidu.com/>)|180.97.33.107|:80... connected.*
*HTTP request sent, awaiting response... 200 OK*
*Length: unspecified [text/html]*
*Saving to: `index.html.1'*

* [ <=>
]
97,308 --.-K/s in 0.09s *

*2015-11-06 23:30:29 (1.03 MB/s) - `index.html.1' saved [97308]*

Does anyone met this situation before? thanks!

my cf version is cf-release170 and the os is Ubuntu 12.04.1 LTS


--

Regards,

Yitao
jiangyt.github.io


Re: Running non http UDP application on Cloud Foundry

Atul Kshirsagar
 

Generic UDP routing is kind of hard for multi packet protocols (like SIP or CoAP), you want to make sure packets belonging to same message are routed to same instance of your app. There are two ways to achieve this:
1) Protocol specific UDP routers (stateful) that understand the protocol and can route packets belonging to same message to same instance of your app.
2) Based on source IP route the packets to same instance of app (might not result in most optimal load balancing).

Anyways as James pointed out there is no support for UDP routing in CF. For your use case if it is an option for you to use SIP over tcp then tcp router, which is being developed for CF right now , can be an option for you.

Regards,
Atul


Re: Source IP ACLs

Noburou TANIGUCHI
 

Thank you for the response, Shannon,

Our work on support for Route Services has nearly reached MVP.
Great!

- UX proposal:
https://drive.google.com/open?id=1SfwaQ1hnngfopXC_Q24cT6lbo0yFwvbAbPcCPEHeNPY
- Original proposal:
https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing
- Tracker epics: https://www.pivotaltracker.com/epic/show/1884060 and
https://www.pivotaltracker.com/epic/show/2031344
I will read them. Thanks.


--
Noburou TANIGUCHI



shannon wrote
You could certainly build a route service to support this use case. Users
would create a service instance of the service, configure it to block
specified IPs (on create, bind, or out-of-band), then bind it to the
route,
causing requests to the route to be forwarded to the service instance,
which would block the requests or pass them through. All applications
mapped to the route would be protected.

Route Services opens a whole new class of services which could be offered
in the marketplace by exposing an point of extension. Now all these
features don't have be to implemented directly in the router itself.

Our work on support for Route Services has nearly reached MVP. The backend
work is nearly complete, and we've started work on the CLI commands. Soon
we'll publish documentation for service broker authors as well as end
users.

I'll also be sending a request for feedback shortly on a header we're
using
in the integration that must be handled by the services. With a few
changes
we could support standard forwarding proxies as Route Services per the
http
rfc, but it comes with tradeoffs. Stay tuned.

For now, you can refer to these docs for info about the Route Services
feature:
- UX proposal:
https://drive.google.com/open?id=1SfwaQ1hnngfopXC_Q24cT6lbo0yFwvbAbPcCPEHeNPY
- Original proposal:
https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing
- Tracker epics: https://www.pivotaltracker.com/epic/show/1884060 and
https://www.pivotaltracker.com/epic/show/2031344

Please let me know if you have any questions.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Sat, Oct 31, 2015 at 1:33 AM, Noburou TANIGUCHI &lt;
dev(a).m001
&gt; wrote:

We have proprietarily implemented the feature into Gorouter, but now
similar
functionality will probably achieved by Route Service [1]. There seems
little information [2] about it and I also want to know the progress.

[1]

https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit#heading=h.8djffzes9pnb

[2] https://www.pivotaltracker.com/n/projects/966314


Carlo Alberto Ferraris-2 wrote
Is there any provision for restricting the source IPs that are allowed
to
access a certain application (or route)? Or the only way to do this is
to
place a reverse proxy in front of the gorouter?
In case the reverse proxy is the only way to go, would there be
interest
to have something like this implemented inside the gorouter itself?
(we're
willing to contribute)




-----
I'm not a ...
noburou taniguchi
--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-Source-IP-ACLs-tp2518p2544.html
Sent from the CF Dev mailing list archive at Nabble.com.




-----
I'm not a ...
noburou taniguchi
--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-Source-IP-ACLs-tp2518p2628.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: cf client: Get a connection from spaces to services

Lyn Autumn
 

Just figured out that I could do it by reading out the application environments, but this will be quite messy and I'm not sure if this will work properly. So if there is an easier way, I'd appreciate if somebody lets me know ;-)


Re: cf client: Get a connection from spaces to services

Lyn Autumn
 

Sorry for not being clear enough.
Well I am trying to get the relations from the CloudFoundryClient in Java to see which services belong to a space and which spaces are in an organization. I can access orgs, spaces and apps all with a for-loop and iterate over the values. They also have an GUID, which means I can make a relation between all of them ("give me the space with the id xy"), so I know which apps are in one space and which spaces are in one org.
Services though are just stored as a List of Strings in the application object and not with an ID. So by searching for the service with client.getService(Name) it can happen that I get the wrong service (because there can be more services with the same name in different spaces, so I always get the first one back which might not be the right one). I am just missing a function like client.getService(GUID).
I'm using the cloudfoundry-client-lib version 1.1.3, maybe there is another version or something?
Well I hope this was clearer.


Re: app restage

James Bayer
 

you need some way to get the service binding details from you app into the
config service (Zookeeper, or SCC). i suppose you could have something do
it on a cron schedule or something. your app also needs to be able to
handle the updates to reset any connections it may have.

On Thu, Nov 5, 2015 at 10:16 AM, Swatz bosh <swatzron(a)gmail.com> wrote:

Hi,

If we use Zookeeper/Spring-Cloud-Config-server for application
configuration management, then is there are way - to avoid 'cf restage app'
after binding my app to config server. So is there a way that - without
restaging my app configurations get reflected in my app ?

Hope am able to clearly raise my query.

Thanks.
--
Thank you,

James Bayer


Re: cf client: Get a connection from spaces to services

James Bayer
 

i'm not following what you are trying to do.

perhaps you can explain what you are trying to accomplish in terms of a
real-world scenario and we can advise an approach.

On Fri, Nov 6, 2015 at 8:12 AM, Lyn Autumn <sh228(a)hdm-stuttgart.de> wrote:

Hi there!
I'm not sure if I'm actually right here to ask my question: So I'm trying
to get the relation between spaces and services from the CloudFoundryClient
(Java).
Unfortunately the Services are saved as a List of String ins Applications,
so I can't access the actual Service(Instance) ID to get the correct
Service. This means if I have the same name for a Service in multiple
spaces I always get the first one because it will be overwritten the whole
time. Is there another function, am I missing something?
I'd appreciate any help, thanks in advance!
--
Thank you,

James Bayer


Re: Running non http UDP application on Cloud Foundry

James Bayer
 

none of the CF routers, either the HTTP gorouter or the upcoming TCP router
[1] support routing UDP.

there is way to turn on "container to container networking" but it's not
advised in a multi-tenant environment because any container can connect to
any other container directly. you would also have to expose each
application host (DEA or Diego Cell) to the outside world if you want
clients to hit it from outside CF.

[1] https://github.com/cloudfoundry-incubator/cf-routing-release

On Fri, Nov 6, 2015 at 1:51 PM, Suryaveer Chauhan <
chauhan.suryaveer(a)gmail.com> wrote:

I have just installed a local CF using CF_NISE_INSTALLER.

I wish to run a SIP application, which runs on PORT 5060 and UDP.
Whatever I have read about CF, I understand that there's a HTTP proxy to
route the incoming requests.

Is there a way I can run this application on CF.

I greatly appreciate some help.

Thanks


--
Thank you,

James Bayer


Failed compiling packages during cf-215 upgrade in bosh director

Lingesh Mouleeshwaran
 

Hi Team , we are getting below error for few packages during cf 2215
version deployment via bosh. Please any idea to add / restore the missing
blobstores in bosh director.

Failed compiling packages >
golang1.3/e4b65bcb478d9bea1f9c92042346539713551a4a: Action Failed get_task:
Task 4f0a837d-f87d-429d-58d2-3bdc297e0251 result: Compiling package
golang1.3: Fetching package golang1.3: Fetching package blob
797ed1ec-dd77-47b0-ad70-0cb26c3f31d1: Getting blob from inner blobstore:
Getting blob from inner blobstore: Shelling out to bosh-blobstore-dav cli:
Running command: 'bosh-blobstore-dav -c
/var/vcap/bosh/etc/blobstore-dav.json get
797ed1ec-dd77-47b0-ad70-0cb26c3f31d1
/var/vcap/data/tmp/bosh-blobstore-externalBlobstore-Get048275605', stdout:
'Error running app - Getting dav blob 797ed1ec-dd77-47b0-ad70-0cb26c3f31d1:
Wrong response code: 404; body:

Regards
Lingesh M

6781 - 6800 of 9429