Date   

Re: Composite Application Deployer

David Vydra <david@...>
 

James,

Thanks for the detailed answer. We started treating Jenkins views as the
representation of a particular space and each view contains many of jobs
for that push one app to that space.

autopilot plugin is definitely a move in the right direction, but we have a
richer deployment story --- we run smoke tests before we switch the routes.
We are implementing lower-level primitives that support this level of
granularity.

We are currently using Java, but will probably switch to Go if our approach
works (and we find time to learn Go)

Thanks,
David


--
http://www.linkedin.com/in/dvydra
http://www.testdriven.com
http://twitter.com/vydra


Removal of login job from cf-release

Amit Kumar Gupta
 

Hi folks,

We're announcing the forthcoming removal of the Login component in
cf-release.

This component was made redundant in commit 6522b1 to
github.com/cloudfoundry/cf-release, which is contained in final release
v208. This was Part 1 of a 2-Part PR, and was just an additive change.
See here:

https://github.com/cloudfoundry/cf-release/pull/620

Operators currently managing a post-6522b1 release should be able to scale
up their UAA jobs and remove their Login jobs accordingly.

We'd like to move forward with Part 2, which will actually remove the Login
job and references to it in manifest templates:

https://github.com/cloudfoundry/cf-release/pull/621

Operators managing a pre-6522b1 release are advised to upgrade to one
post-6522b1 before removing their Login servers to avoid downtime, as BOSH
will remove jobs (namely Login) before updating jobs (namely updating UAA
to a version that obviates the Login server).

Thanks,
Amit Gupta
Product Manager - Cloud Foundry OSS Release Integration Team


opensaf comparison

Sashan Govender <sashang@...>
 

Hi

I had a look at the 2014 presentation here:
http://cloudfoundry.org/learn/index.html

In it they compared 6 platforms however OpenSAF was not one of them. I am
wondering where people creating these PaaS systems see OpenSAF fitting in
and what the regions of overlap. There seems to be a significant amount of
overlap in terms of functionality, for example, the ability to install,
upgrade and remove an application on set of nodes, a distributed
configuration database and monitoring of applications. Is there any reason
why OpenSAF is not considered for comparison when it provides some of the
features required for a PaaS system? Is it missing something fundametal to
PaaS? Is it too awkward to admin or use? Is it not very well known?

http://www.opensaf.org/
http://sourceforge.net/projects/opensaf/


Refactoring Runtime

Onsi Fakhouri <ofakhouri@...>
 

Hi CF-Dev,

As discussed at the June 2nd Runtime PMC
<https://github.com/cloudfoundry/pmc-notes/blob/master/Runtime/2015-06-02-runtime.md>
some of the OSS CF development teams are being reorganized. The primary
focus has been on breaking the runtime team apart along cleaner lines of
responsibility. This refactoring especially makes sense in light of
Diego's approach to GA status.

We've split runtime into 3 teams:

Routing Team

Responsibilities include the Gorouter and the new TCP Router. Shannon Coen
is PM.

CAPI: the API Team

Responsibilities include the Cloud Controller and cover both the
application API and the services API. Dieu Cao is PM.

MEGA: the Release Integration Team

Responsibilities include the integration pipeline (named A1) and
CF-Release. In short, if the MEGA team does its job well, it will be able
to reliably tell us: “this is the set of cf components and versions that
work reliably together” and “this version of the components can be safely
upgraded to this other version of the components”. Amit Gupta is PM.

More details around the three teams, including links to repos and tracker
projects are available at
https://github.com/cloudfoundry-community/cf-docs-contrib/wiki (please bear
with us as we bring the wiki up-to-date!)

Whereas Routing and CAPI are relatively self-explanatory, MEGA merits a
little more discussion:


The MEGA team is an important refactor that is taking on the burden of
monitoring builds and integrating the various components of Cloud Foundry
into a cohesive whole. This important job was previously under Runtime's
umbrella but constitutes a substantial amount of work that will benefit
from the focus and attention of a dedicated team.

While spinning out MEGA is best understood as an organizational refactor
the scope and responsibility of an "integration" team runs the risk of
being vague. To help clarify the team's responsibilities and the ways in
which they will be making substantive contributions to CF we've put
together a preliminary mandate for the team here
<https://docs.google.com/document/d/1WmA174FR6p2G0WJqUQ336wzWaYWgBEwBtFJz7uKFSdo/edit#heading=h.w9zfhm7rwpdq>.


Comments and feedback on the Mega mandate are, of course, welcome. The
team will be holding an inception on Wednesday to further refine the doc
and we fully expect the team's role and responsibilities to evolve with
time.

Onsi


HTTPS for Java App

Maaz
 

Hello,

We have CF 197 deployed in our environment (without HA Proxy). I am trying to push a standalone Spring boot JAR (with embedded tomcat). The app starts properly but I can't access it via https.

I have these settings for my spring boot app
server:
tomcat:
remote_ip_header: x-forwarded-for
protocol_header: x-forwarded-proto

Also
Within the app I have configured the tomcat to accept SSL connection using this sample
https://github.com/spring-projects/spring-boot/blob/master/spring-boot-samples/spring-boot-sample-tomcat-multi-connectors/src/main/java/sample/tomcat/multiconnector/SampleTomcatTwoConnectorsApplication.java

Can someone please point out what I am missing in order to get Https working for my app.
Do I need to enable something within the CF deployment ?

Thanks
Maaz


Re: using declared-services in manifest.yml

Amit Kumar Gupta
 

Hi Suchitra,

This mailing list is for discussion of the open source Cloud Foundry
projects, IBM BlueMix is IBM's proprietary hosted Cloud Foundry solution.
Your question sounds like it pertains specifically to the BlueMix
marketplace. I would recommend reaching out to BlueMix support.

Best,
Amit

On Mon, Jul 13, 2015 at 1:14 PM, Suchitra Manickam <smanick(a)us.ibm.com>
wrote:

I'm trying to to use the "Deploy to Bluemix" button feature with an
application using dashDB.
I followed the instructions from this link and created a new application
with cloudant which worked fine.


https://developer.ibm.com/devops-services/2015/02/18/share-code-new-deploy-bluemix-button/

But the same doesnt work with dashDB. Here's the log generated.



Here are the settings that I used for Cloudant vs dashDB.
Can you please let me know how to make it work with dashDB?

*No SQL Cloudant DB*
*dashDB*







cf marketplace output:



cf marketplace output:





Thanks and Regards,
Suchitra Manickam

Internet Address: smanick(a)us.ibm.com
Notes Address: Suchitra Manickam/Silicon Valley/IBM(a)IBMUS
Phone: (408) 463-3520

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


using declared-services in manifest.yml

Suchitra Manickam <smanick@...>
 

I'm trying to to use the "Deploy to Bluemix" button feature with an
application using dashDB.
I followed the instructions from this link and created a new application
with cloudant which worked fine.

https://developer.ibm.com/devops-services/2015/02/18/share-code-new-deploy-bluemix-button/

But the same doesnt work with dashDB. Here's the log generated.



Here are the settings that I used for Cloudant vs dashDB.
Can you please let me know how to make it work with dashDB?

No SQL Cloudant DB
dashDB








cf marketplace output:




cf marketplace output:









Thanks and Regards,
Suchitra Manickam

Internet Address: smanick(a)us.ibm.com
Notes Address: Suchitra Manickam/Silicon Valley/IBM(a)IBMUS
Phone: (408) 463-3520


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

Mike Dalessio
 

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


Re: Any information Docker image on CF / Pivotal CF

Eric Malm <emalm@...>
 

Hi, Balaramaraju,

Thanks for asking about Docker-image support in CF! One of the goals of the
current work on Diego and Garden is to support running Docker-image-based
containers on CF. We've documented our level of support for such containers
in the Docker Support file in the Diego Design Notes:
https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/docker-support.md
.

The Diego and Garden teams are currently working on upgrading the
garden-linux dependency in diego-release to a version that better supports
Docker-image-based containers, and especially running processes as users
included in given rootfs, docker-image-based or otherwise. After that
upgrade is complete, we shortly thereafter plan to honor the user specified
in the Docker image metadata, instead of using the special 'vcap' user that
garden-linux creates in its containers. (In fact, pretty soon garden-linux
will no longer even create that 'vcap' user, and it will instead come from
the cflinuxfs2 rootfs itself.)

Thanks,
Eric, CF Runtime Diego PM



On Mon, Jul 13, 2015 at 2:34 AM, Balaramaraju JLSP <balaramaraju(a)gmail.com>
wrote:

Hi Gwenn ,

Do you know when this can be official ?
any documentation or tutorial kind of on this.

On Mon, Jul 13, 2015 at 12:54 PM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

Cloudfoundry support docker image, I mean the open source version does no
with diego, for me diego is a part of CF ..
But yet is not official right now.



On Mon, Jul 13, 2015 at 3:16 PM, Prysmakou Aliaksandr <
aliaksandr.prysmakou(a)altoros.com> wrote:

Hi,

Currently CF doesn't run docker images. But there is project to add
support of Docker to CF called Diego.
More details are here -
https://github.com/cloudfoundry-incubator/diego-release

Alex Prysmakou / Altoros
Tel: (617) 841-2121 ext. 5161 | Toll free: 855-ALTOROS
Skype: aliaksandr.prysmakou
www.altoros.com | blog.altoros.com | twitter.com/altoros

On Jul 13, 2015, at 8:52 AM, Balaramaraju JLSP <balaramaraju(a)gmail.com>
wrote:

HI All,

can i use my docker image on cloud foundry ?
if any one succeed please share the information

--
J L S P Balaramaraju
_______________________________________________
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


--
J L S P Balaramaraju

_______________________________________________
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

Daniel Mikusa
 

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.

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.

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


Re: java-buildpack aspectj weaver support

Stevo Slavić <sslavic at gmail.com...>
 

Hello Chris,

Thanks for fast feedback!

I've created feature request
https://github.com/cloudfoundry/java-buildpack/issues/205

Kind regards,
Stevo Slavic.

On Mon, Jul 13, 2015 at 12:23 PM, Christopher Frost <cfrost(a)pivotal.io>
wrote:

Hi,

This is currently not supported and we have nothing in the pipeline for
it. Please raise a feature request though and we will discuss it.

Thanks, Chris.


Christopher Frost - Pivotal UK
Java Buildpack Team

On Mon, Jul 13, 2015 at 9:01 AM, Stevo Slavić <sslavic(a)gmail.com> wrote:

Hello CloudFoundry community,

Does java-buildpack support turning on aspectj loadtime weaving for app?

If not, are there any plans to do it? App itself could provision
aspectj-weaver.jar file.

Kind regards,
Stevo Slavic.

_______________________________________________
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


Re: Removing FUSE support from CF

Daniel Mikusa
 

On Mon, Jul 13, 2015 at 2:48 AM, Lerenc, Vedran <vedran.lerenc(a)sap.com>
wrote:

Hi Onsi,



Ø Thoughts? Concerns?



Well, that’s bad news.



We, and I assume many others as well (like the folks from Stackato who do
it in the public), have used SSHFS + FUSE to implement a persistent file
system for old-fashioned apps/apps that are not Cloud-native. I don’t want
to fight an ideological battle here, it’s just that these apps do still
exist (in majority) and a file system service is an important
service/feature for them.



So if you remove FUSE (which we thought is not going away/was added to
stay), it’s pretty bad for us/many apps.



Best regards, Vedran
+1 - It would be sad to see FUSE support go away. It's been very helpful
for running apps that depend on a persistent FS, like Wordpress. Perhaps
this use case of mounting a remote SSHFS could be supported in some other
way?

Dan








*From: *Onsi Fakhouri
*Reply-To: *"Discussions about Cloud Foundry projects and the system
overall."
*Date: *Saturday 11 July 2015 01:10
*To: *cf-dev
*Subject: *[cf-dev] Removing FUSE support from CF



Hey CF-Dev,



The Garden team has been hard at work substantially improving
Garden-Linux's security features. Garden-Linux now employs user namespaces
and drops capabilities when creating unprivileged containers - we're
excited to bring both of these features to the platform!



Diego currently runs applications in *privileged* containers. These lack
the security features outlined above and we are planning on switching to
launch all CF applications in *unprivileged* containers.



Unfortunately, it has proved difficult to support
mounting FUSE filesystems from within unprivileged containers. We believe
the security benefits outweigh the features that FUSE give us and* are
planning on removing support for FUSE in favor of better securing our
containers.* If/when FUSE support in unprivileged containers becomes
possible we may add it back to the platform.



Thoughts? Concerns?



Thanks!



Onsi

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


Re: java-buildpack aspectj weaver support

Christopher Frost
 

Hi,

This is currently not supported and we have nothing in the pipeline for it.
Please raise a feature request though and we will discuss it.

Thanks, Chris.


Christopher Frost - Pivotal UK
Java Buildpack Team

On Mon, Jul 13, 2015 at 9:01 AM, Stevo Slavić <sslavic(a)gmail.com> wrote:

Hello CloudFoundry community,

Does java-buildpack support turning on aspectj loadtime weaving for app?

If not, are there any plans to do it? App itself could provision
aspectj-weaver.jar file.

Kind regards,
Stevo Slavic.

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


Re: Any information Docker image on CF / Pivotal CF

Balaramaraju JLSP <balaramaraju@...>
 

Hi Gwenn ,

Do you know when this can be official ?
any documentation or tutorial kind of on this.

On Mon, Jul 13, 2015 at 12:54 PM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

Cloudfoundry support docker image, I mean the open source version does no
with diego, for me diego is a part of CF ..
But yet is not official right now.



On Mon, Jul 13, 2015 at 3:16 PM, Prysmakou Aliaksandr <
aliaksandr.prysmakou(a)altoros.com> wrote:

Hi,

Currently CF doesn't run docker images. But there is project to add
support of Docker to CF called Diego.
More details are here -
https://github.com/cloudfoundry-incubator/diego-release

Alex Prysmakou / Altoros
Tel: (617) 841-2121 ext. 5161 | Toll free: 855-ALTOROS
Skype: aliaksandr.prysmakou
www.altoros.com | blog.altoros.com | twitter.com/altoros

On Jul 13, 2015, at 8:52 AM, Balaramaraju JLSP <balaramaraju(a)gmail.com>
wrote:

HI All,

can i use my docker image on cloud foundry ?
if any one succeed please share the information

--
J L S P Balaramaraju
_______________________________________________
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


--
J L S P Balaramaraju


java-buildpack aspectj weaver support

Stevo Slavić <sslavic at gmail.com...>
 

Hello CloudFoundry community,

Does java-buildpack support turning on aspectj loadtime weaving for app?

If not, are there any plans to do it? App itself could provision
aspectj-weaver.jar file.

Kind regards,
Stevo Slavic.


Re: CF Lattice support for private registries (Artifactory Docker registry).

Gwenn Etourneau
 

Maybe dns issue inside the vagrant box .. you should use your dns inside
the box I guess.

On Mon, Jul 13, 2015 at 4:28 PM, Dharmi <dharmi(a)gmail.com> wrote:

Hi,

This is a question related to CF Lattice issue to pull Docker image from
private Artifactory Docker registry. 'posting on CF-Dev assuming that this
could be a generic CF issue to connect to private repos. pls suggest if
otherwise.

Please find the configuration:

Mac OSX 10.10.4
cf version 6.11.3
vbox 4.3.28r100309
Vagrant 1.7.2
Lattice from github master branch
ltc version v0.2.5
Artifactory Pro Power Pack 3.5.2

While pulling images from Docker Hub is working fine, images from my local
Artifactory Docker registry throws the below error.

* v1 ping attempt failed with error: Get
https://docker-local.corp.myorg.com/v1/_ping
<https://docker-local.corp.myorg.com/v1/_ping>: dial tcp:
lookup docker-local.corp.myorg.com <http://docker-local.corp.myorg.com>: no
such host. HTTP attempt: unable to ping registry endpoint
http://docker-local.corp.myorg.com/v0/
<http://docker-local.corp.myorg.com/v0/>*
I tried setting up .dockercfg file with valid entries, but still in vain.
The same works fine if I perform a 'Docker pull' from Artifactory.
Any pointers would be helpful.

Thanks,
Dharmi

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


CF Lattice support for private registries (Artifactory Docker registry).

dharmi
 

Hi,

This is a question related to CF Lattice issue to pull Docker image from
private Artifactory Docker registry. 'posting on CF-Dev assuming that this
could be a generic CF issue to connect to private repos. pls suggest if
otherwise.

Please find the configuration:

Mac OSX 10.10.4
cf version 6.11.3
vbox 4.3.28r100309
Vagrant 1.7.2
Lattice from github master branch
ltc version v0.2.5
Artifactory Pro Power Pack 3.5.2

While pulling images from Docker Hub is working fine, images from my local
Artifactory Docker registry throws the below error.

* v1 ping attempt failed with error: Get
https://docker-local.corp.myorg.com/v1/_ping
<https://docker-local.corp.myorg.com/v1/_ping>: dial tcp:
lookup docker-local.corp.myorg.com <http://docker-local.corp.myorg.com>: no
such host. HTTP attempt: unable to ping registry endpoint
http://docker-local.corp.myorg.com/v0/
<http://docker-local.corp.myorg.com/v0/>*
I tried setting up .dockercfg file with valid entries, but still in vain.
The same works fine if I perform a 'Docker pull' from Artifactory.
Any pointers would be helpful.

Thanks,
Dharmi


Re: Any information Docker image on CF / Pivotal CF

Gwenn Etourneau
 

Cloudfoundry support docker image, I mean the open source version does no
with diego, for me diego is a part of CF ..
But yet is not official right now.



On Mon, Jul 13, 2015 at 3:16 PM, Prysmakou Aliaksandr <
aliaksandr.prysmakou(a)altoros.com> wrote:

Hi,

Currently CF doesn't run docker images. But there is project to add
support of Docker to CF called Diego.
More details are here -
https://github.com/cloudfoundry-incubator/diego-release

Alex Prysmakou / Altoros
Tel: (617) 841-2121 ext. 5161 | Toll free: 855-ALTOROS
Skype: aliaksandr.prysmakou
www.altoros.com | blog.altoros.com | twitter.com/altoros

On Jul 13, 2015, at 8:52 AM, Balaramaraju JLSP <balaramaraju(a)gmail.com>
wrote:

HI All,

can i use my docker image on cloud foundry ?
if any one succeed please share the information

--
J L S P Balaramaraju
_______________________________________________
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


Re: Python buildpack failed to work on CF 210

Gwenn Etourneau
 

:)

On Mon, Jul 13, 2015 at 2:33 PM, 王小锋 <zzuwxf(a)gmail.com> wrote:

Thanks a lot, Gwenn

I specify python version in runtime.txt, after modifying it to 2.7.9, it
works.

2015-07-10 11:47 GMT+08:00 Gwenn Etourneau <getourneau(a)pivotal.io>:

I am wondering about "Installing runtime (python-2.7.6)" I think only
2.7.9 and 2.7.10 are supported on the cf2linux stack.

Do you specify the python version on your application ? Can you try the
one I give you ?


On Fri, Jul 10, 2015 at 12:30 PM, 王小锋 <zzuwxf(a)gmail.com> wrote:

Hi, there

I upgraded CloudFoundry to verion 210 from 205 last week, today when I
push a "hello world" python project (works before) to CF using command
below:

cf push python11 -p python-sample.zip -b
https://github.com/cloudfoundry/python-buildpack

it failed with followoing error, seems pre-comipled package does not
work on latest stack cflinuxfs2, any ideas?

BTW, when I push python project using cached python buildpack 1.3.1 with
old stack lucid64, it worked.

2015-07-10T03:27:05.72+0000 [DEA] OUT Got staging request for app
with id 04900427-41c0-48c4-9cae-e904b9b6caa4
2015-07-10T03:27:06.69+0000 [STG] OUT -----> Downloaded app package
(4.0K)
2015-07-10T03:27:06.76+0000 [STG] ERR Cloning into
'/tmp/buildpacks/python-buildpack'...
2015-07-10T03:27:13.58+0000 [STG] OUT Submodule 'compile-extensions'
(https://github.com/cloudfoundry-incubator/compile-extensions.git)
registered for path 'compile-extensions'
2015-07-10T03:27:13.62+0000 [STG] ERR Cloning into
'compile-extensions'...
2015-07-10T03:27:16.67+0000 [STG] OUT Submodule path
'compile-extensions': checked out 'f752ecf4b27d2f31bb082dfe7a47c76fefc769d7'
2015-07-10T03:27:16.79+0000 [STG] OUT -------> Buildpack version
1.4.0
2015-07-10T03:27:16.83+0000 [STG] OUT -----> Installing runtime
(python-2.7.6)
2015-07-10T03:27:31.22+0000 [STG] OUT -----> Installing dependencies
with pip
2015-07-10T03:27:31.27+0000 [STG] ERR ERROR:root:code for hash md5
was not found.
2015-07-10T03:27:31.27+0000 [STG] ERR Traceback (most recent call
last):
2015-07-10T03:27:31.27+0000 [STG] ERR File
"/app/.heroku/python/lib/python2.7/hashlib.py", line 139, in <module>
2015-07-10T03:27:31.27+0000 [STG] ERR globals()[__func_name] =
__get_hash(__func_name)
2015-07-10T03:27:31.27+0000 [STG] ERR File
"/app/.heroku/python/lib/python2.7/hashlib.py", line 91, in
__get_builtin_constructor
2015-07-10T03:27:31.27+0000 [STG] ERR raise
ValueError('unsupported hash type ' + name)
2015-07-10T03:27:31.27+0000 [STG] ERR ValueError: unsupported hash
type md5
2015-07-10T03:27:31.27+0000 [STG] ERR ERROR:root:code for hash sha1
was not found.
2015-07-10T03:27:31.27+0000 [STG] ERR Traceback (most recent call
last):
2015-07-10T03:27:31.27+0000 [STG] ERR File
"/app/.heroku/python/lib/python2.7/hashlib.py", line 139, in <module>
2015-07-10T03:27:31.27+0000 [STG] ERR globals()[__func_name] =
__get_hash(__func_name)
2015-07-10T03:27:31.27+0000 [STG] ERR File
"/app/.heroku/python/lib/python2.7/hashlib.py", line 91, in
__get_builtin_constructor
2015-07-10T03:27:31.27+0000 [STG] ERR raise
ValueError('unsupported hash type ' + name)
2015-07-10T03:27:31.27+0000 [STG] ERR ValueError: unsupported hash
type sha1
2015-07-10T03:27:31.27+0000 [STG] ERR ERROR:root:code for hash
sha224 was not found.
2015-07-10T03:27:31.27+0000 [STG] ERR Traceback (most recent call
last):
2015-07-10T03:27:31.27+0000 [STG] ERR File
"/app/.heroku/python/lib/python2.7/hashlib.py", line 139, in <module>
2015-07-10T03:27:31.27+0000 [STG] ERR globals()[__func_name] =
__get_hash(__func_name)
2015-07-10T03:27:31.27+0000 [STG] ERR File
"/app/.heroku/python/lib/python2.7/hashlib.py", line 91, in
__get_builtin_constructor
2015-07-10T03:27:31.27+0000 [STG] ERR raise
ValueError('unsupported hash type ' + name)
2015-07-10T03:27:31.27+0000 [STG] ERR ValueError: unsupported hash
type sha224
2015-07-10T03:27:31.27+0000 [STG] ERR ERROR:root:code for hash
sha256 was not found.
2015-07-10T03:27:31.27+0000 [STG] ERR Traceback (most recent call
last):
2015-07-10T03:27:31.27+0000 [STG] ERR File
"/app/.heroku/python/lib/python2.7/hashlib.py", line 139, in <module>
2015-07-10T03:27:31.27+0000 [STG] ERR globals()[__func_name] =
__get_hash(__func_name)
2015-07-10T03:27:31.27+0000 [STG] ERR File
"/app/.heroku/python/lib/python2.7/hashlib.py", line 91, in
__get_builtin_constructor
2015-07-10T03:27:31.27+0000 [STG] ERR raise
ValueError('unsupported hash type ' + name)
2015-07-10T03:27:31.27+0000 [STG] ERR ValueError: unsupported hash
type sha256
2015-07-10T03:27:31.27+0000 [STG] ERR ERROR:root:code for hash
sha384 was not found.
2015-07-10T03:27:31.27+0000 [STG] ERR Traceback (most recent call
last):
2015-07-10T03:27:31.27+0000 [STG] ERR File
"/app/.heroku/python/lib/python2.7/hashlib.py", line 139, in <module>
2015-07-10T03:27:31.27+0000 [STG] ERR globals()[__func_name] =
__get_hash(__func_name)
2015-07-10T03:27:31.27+0000 [STG] ERR File
"/app/.heroku/python/lib/python2.7/hashlib.py", line 91, in
__get_builtin_constructor
2015-07-10T03:27:31.27+0000 [STG] ERR raise
ValueError('unsupported hash type ' + name)
2015-07-10T03:27:31.27+0000 [STG] ERR ValueError: unsupported hash
type sha384
2015-07-10T03:27:31.27+0000 [STG] ERR ERROR:root:code for hash
sha512 was not found.
2015-07-10T03:27:31.27+0000 [STG] ERR Traceback (most recent call
last):
2015-07-10T03:27:31.27+0000 [STG] ERR File
"/app/.heroku/python/lib/python2.7/hashlib.py", line 139, in <module>
2015-07-10T03:27:31.27+0000 [STG] ERR globals()[__func_name] =
__get_hash(__func_name)
2015-07-10T03:27:31.27+0000 [STG] ERR File
"/app/.heroku/python/lib/python2.7/hashlib.py", line 91, in
__get_builtin_constructor
2015-07-10T03:27:31.27+0000 [STG] ERR raise
ValueError('unsupported hash type ' + name)
2015-07-10T03:27:31.27+0000 [STG] ERR ValueError: unsupported hash
type sha512
2015-07-10T03:27:31.37+0000 [STG] ERR Traceback (most recent call
last):
2015-07-10T03:27:31.37+0000 [STG] ERR File
"/app/.heroku/python/bin/pip", line 9, in <module>
2015-07-10T03:27:31.37+0000 [STG] ERR
load_entry_point('pip==7.0.1', 'console_scripts', 'pip')()
2015-07-10T03:27:31.37+0000 [STG] ERR File
"build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 552, in
load_entry_point
2015-07-10T03:27:31.37+0000 [STG] ERR File
"build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 2672, in
load_entry_point
2015-07-10T03:27:31.37+0000 [STG] ERR File
"build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 2345, in load
2015-07-10T03:27:31.37+0000 [STG] ERR File
"build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 2351, in
resolve
2015-07-10T03:27:31.37+0000 [STG] ERR File
"/app/.heroku/python/lib/python2.7/site-packages/pip-7.0.1-py2.7.egg/pip/__init__.py",
line 15, in <module>
2015-07-10T03:27:31.37+0000 [STG] ERR from pip.vcs import git,
mercurial, subversion, bazaar # noqa
2015-07-10T03:27:31.37+0000 [STG] ERR File
"/app/.heroku/python/lib/python2.7/site-packages/pip-7.0.1-py2.7.egg/pip/vcs/mercurial.py",
line 10, in <module>
2015-07-10T03:27:31.37+0000 [STG] ERR from pip.download import
path_to_url
2015-07-10T03:27:31.37+0000 [STG] ERR File
"/app/.heroku/python/lib/python2.7/site-packages/pip-7.0.1-py2.7.egg/pip/download.py",
line 38, in <module>
2015-07-10T03:27:31.37+0000 [STG] ERR from pip._vendor import
requests, six
2015-07-10T03:27:31.37+0000 [STG] ERR File
"/app/.heroku/python/lib/python2.7/site-packages/pip-7.0.1-py2.7.egg/pip/_vendor/__init__.py",
line 92, in load_module
2015-07-10T03:27:31.37+0000 [STG] ERR raise ImportError("No
module named '%s'" % (name,))
2015-07-10T03:27:31.37+0000 [STG] ERR ImportError: No module named
'pip._vendor.requests'
2015-07-10T03:27:31.38+0000 [STG] OUT Staging failed: Buildpack
compilation step failed


_______________________________________________
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


Re: Removing FUSE support from CF

Lerenc, Vedran <vedran.lerenc@...>
 

Hi Onsi,


Ø Thoughts? Concerns?

Well, that’s bad news.

We, and I assume many others as well (like the folks from Stackato who do it in the public), have used SSHFS + FUSE to implement a persistent file system for old-fashioned apps/apps that are not Cloud-native. I don’t want to fight an ideological battle here, it’s just that these apps do still exist (in majority) and a file system service is an important service/feature for them.

So if you remove FUSE (which we thought is not going away/was added to stay), it’s pretty bad for us/many apps.

Best regards, Vedran



From: Onsi Fakhouri
Reply-To: "Discussions about Cloud Foundry projects and the system overall."
Date: Saturday 11 July 2015 01:10
To: cf-dev
Subject: [cf-dev] Removing FUSE support from CF

Hey CF-Dev,

The Garden team has been hard at work substantially improving Garden-Linux's security features. Garden-Linux now employs user namespaces and drops capabilities when creating unprivileged containers - we're excited to bring both of these features to the platform!

Diego currently runs applications in privileged containers. These lack the security features outlined above and we are planning on switching to launch all CF applications in unprivileged containers.

Unfortunately, it has proved difficult to support mounting FUSE filesystems from within unprivileged containers. We believe the security benefits outweigh the features that FUSE give us and are planning on removing support for FUSE in favor of better securing our containers. If/when FUSE support in unprivileged containers becomes possible we may add it back to the platform.

Thoughts? Concerns?

Thanks!

Onsi

8681 - 8700 of 9422