Re: Purge files on NFS or S3?
CF Runtime
Hi John,
James is correct, the resources do not get cleaned up. The system does not have any runtime dependencies on any of them however. They are used when pushing an app to prevent the user from having to push a large file that the system has already seen. You should be able to delete the contents of the resources blobstore. This is the path defined by properties.cc.resource_pool.resource_directory_key in your deployment manifest. Removing anything in the buildpacks, droplets, or packages folders can cause problems in the running system. - CF Runtime Team john, i think the resource files may grow forever right now withoutfind out more.wrote: so needfar, and I wonder if there's a systematic way to purge files we don't (or how do I know I don't need them)?
|
|
Re: cloud foundry
James Bayer
i strongly recommend that you move on to cf v2 for new deployments. cf v1
toggle quoted messageShow quoted text
has not been actively maintained for quite some time.
On Tue, May 19, 2015 at 1:05 AM, 张祥 <zx1084583686(a)gmail.com> wrote:
when i install the cloudfoundry v1,i met a problem,could you help me ? --
Thank you, James Bayer
|
|
Re: Reg Mysql in pivotal cloud with plan 1GB with 400 connections
James Bayer
this email list is about cloud foundry oss, not pivotal commercial
toggle quoted messageShow quoted text
software. you can always open a support case at pivotal.io/support for commercial product inquiries. the pcf mysql product is based on the oss cf mysql [1]. for each bosh deployment of mysql you get a mysql compatible cluster. the cluster uses mariadb and galera for the database nodes. the default configurations for tunable parameters are listed in the spec file: https://github.com/cloudfoundry/cf-mysql-release/blob/master/jobs/mysql/spec what those values should be for your deployment and application workloads are going to be highly dependent on what tradeoffs you want to make. the service plan you use should indicate the number of connections available with your plan, and how you configure max connections in your application typically depends on the database access framework you use. [1] github.com/cloudfoundry/cf-mysql-release
On Tue, May 19, 2015 at 12:27 AM, Dew Agarwal <dew.agarwal(a)gmail.com> wrote:
Hi Team, --
Thank you, James Bayer
|
|
Re: Limit application instances number
Pablo Alonso Rodriguez <palonsoro@...>
Thank you for your answers.
|
|
Re: cloud foundry
Takeshi Morikawa
Cloud Foundry v1 (dev_setup) is no longer supported
toggle quoted messageShow quoted text
http://grokbase.com/t/cloudfoundry.org/vcap-dev/13bd5tmwh2/got-error-error-installing-chef-during-vcap-installation 2015-05-19 17:05 GMT+09:00 张祥 <zx1084583686(a)gmail.com>:
when i install the cloudfoundry v1,i met a problem,could you help me ?
|
|
cloud foundry
张祥 <zx1084583686 at gmail.com...>
when i install the cloudfoundry v1,i met a problem,could you help me ?
[image: 内嵌图片 1]
|
|
Reg Mysql in pivotal cloud with plan 1GB with 400 connections
Dew Agarwal <dew.agarwal@...>
Hi Team,
I was looking into the performance of my application in cloud in multi-threaded environment. Can I get any document on the behaviour of mysql in cloud in multi threaded environment. Specially on number of connections(foreground/backgroud) per instance/ multiple instances using scaling feature etc. Question: Suppose I have five databases used in my app, and am using 1GB with 400 connection plan of mysql, what should be my max connection pool size supported? Thanks in advance. Regards, D Agarwal
|
|
Re: Limit application instances number
James Bayer
there is plans to add a max app instance count to the quota, which would be
enforceable either at the org or at the space level. https://www.pivotaltracker.com/story/show/83375624 https://www.pivotaltracker.com/story/show/83375642 On Mon, May 18, 2015 at 7:45 PM, Matthew Sykes <matthew.sykes(a)gmail.com> wrote: Not that I'm aware of -- Thank you, James Bayer
|
|
Re: Limit application instances number
Matthew Sykes <matthew.sykes@...>
Not that I'm aware of
toggle quoted messageShow quoted text
That said, you can control the maximum memory an instance can allocate and you can control the maximum memory in the quota. It's not the same but it may be something you can leverage.
On Mon, May 18, 2015 at 7:11 AM, Pablo Alonso Rodriguez <palonsoro(a)gmail.com
wrote: Good morning. --
Matthew Sykes matthew.sykes(a)gmail.com
|
|
Re: Problem for Chaos Lemur
stephen
Hi Paul, thank you for your quick response. I added the VSPHERE_HOST settings but it failed to restart. Refer to attached screenshot ' configuration.png '. Also I attached the log file 'restart.log'.
toggle quoted messageShow quoted text
It seems to be a connect issue but I tried to connect the VSPHERE host via vSphere client with the below information: VSPHERE_HOST: 10.32.70.119 VSPHERE_PASSWORD: Password VSPHERE_USERNAME: root And it can connect to the host successfully. Any help will be appreciated.
-----Original Message-----
From: cf-dev-bounces(a)lists.cloudfoundry.org [mailto:cf-dev-bounces(a)lists.cloudfoundry.org] On Behalf Of Paul Harris Sent: Saturday, May 16, 2015 12:57 AM To: cf-dev(a)lists.cloudfoundry.org Subject: Re: [cf-dev] Problem for Chaos Lemur Hi Stephen, DRYRUN mode does everything the same as normal operation *except* for the actual deletion, so if Chaos Lemur is reporting unexpected names it's a problem with some other part of your config, not DRYRUN. From your environment variables it seems you haven't configured it to access your underlying infrastructure, either AWS or VSphere. You need to provide credentials[1] for one of those: AWS_ACCESSKEYID & AWS_SECRETACCESSKEY, or VSPHERE_HOST & VSPHERE_PASSWORD & VSPHERE_USERNAME Give that a go and it should work, but be aware that if DRYRUN is not true then you will lose VMs! Cheers, Paul [1]: https://github.com/pivotal-cf/chaos-lemur#environment-variables -- View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-Problem-for-Chaos-Lemur-tp90p96.html Sent from the CF Dev mailing list archive at Nabble.com. _______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
Re: Deploying CF in AWS
CF Runtime
Hi Alberto,
toggle quoted messageShow quoted text
When BOSH creates a final release, it uploads the packages to the blob store configured for that BOSH release. You can see this for cf-release here: https://github.com/cloudfoundry/cf-release/blob/master/config/final.yml There is more information on release blobstores in the bosh documentation: http://bosh.io/docs/s3-release-blobstore.html - CF Runtime Team Hi Team,
I’ve been following the instructions to deploy CF found here:
|
|
Re: visual studio extension - login error
Vlad Iovanov
Glad to hear it!
Cheers, Vlad From: Price, Jon [mailto:jon.price(a)intel.com] Sent: Monday, May 18, 2015 2:43 PM To: Iovanov, Vlad Mircea; cf-dev(a)lists.cloudfoundry.org Subject: RE: [cf-dev] visual studio extension - login error Hi Vlad, The new version works great! Thank you very much. :) -- Jon From: Iovanov, Vlad Mircea [mailto:Vlad.Iovanov(a)hp.com] Sent: Monday, May 18, 2015 1:51 PM To: Price, Jon; cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org> Subject: RE: [cf-dev] visual studio extension - login error Hello Jon, Can you please try to upgrade the Visual Studio Extensions to latest (1.2.0.4)? We've published a new version that should address the login problems you've been experiencing. New versions of the .NET SDK and MSBuild tasks have also been published. Cheers, Vlad From: Price, Jon [mailto:jon.price(a)intel.com] Sent: Friday, May 15, 2015 11:49 AM To: Iovanov, Vlad Mircea; cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org> Subject: RE: [cf-dev] visual studio extension - login error Hi Vlad, We are running CF release 207. Here is the /v2/info output with some of the data sanitized: {"name":"vcap","build":"2222","support":"http://url.removed", "authorization_endpoint":"https://login.paaslab3.xxx.com", "token_endpoint":"https://uaa.paaslab3.xxx.com","min_cli_version":null, "min_recommended_cli_version":null,"api_version":"2.25.0", "logging_endpoint":"wss://loggregator.paaslab3.xxx.com:443"} We normally have ldap authentication enabled and require ssl between the login server and uaa but even after disabling all of that and running with what I think is a pretty simple and standard configuration we get the error. Thank you for taking the time to look into this. -- Jon From: cf-dev-bounces(a)lists.cloudfoundry.org<mailto:cf-dev-bounces(a)lists.cloudfoundry.org> [mailto:cf-dev-bounces(a)lists.cloudfoundry.org] On Behalf Of Iovanov, Vlad Mircea Sent: Friday, May 15, 2015 10:52 AM To: cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org> Subject: Re: [cf-dev] visual studio extension - login error Hello Jon, Can you please let me know what version of Cloud Foundry you are running? If you could include the output of your "info" endpoint it would be great (http://apidocs.cloudfoundry.org/208/info/get_info.html) Cheers, Vlad
|
|
Re: visual studio extension - login error
Jon Price
Hi Vlad,
The new version works great! Thank you very much. :) -- Jon From: Iovanov, Vlad Mircea [mailto:Vlad.Iovanov(a)hp.com] Sent: Monday, May 18, 2015 1:51 PM To: Price, Jon; cf-dev(a)lists.cloudfoundry.org Subject: RE: [cf-dev] visual studio extension - login error Hello Jon, Can you please try to upgrade the Visual Studio Extensions to latest (1.2.0.4)? We've published a new version that should address the login problems you've been experiencing. New versions of the .NET SDK and MSBuild tasks have also been published. Cheers, Vlad From: Price, Jon [mailto:jon.price(a)intel.com] Sent: Friday, May 15, 2015 11:49 AM To: Iovanov, Vlad Mircea; cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org> Subject: RE: [cf-dev] visual studio extension - login error Hi Vlad, We are running CF release 207. Here is the /v2/info output with some of the data sanitized: {"name":"vcap","build":"2222","support":"http://url.removed", "authorization_endpoint":"https://login.paaslab3.xxx.com", "token_endpoint":"https://uaa.paaslab3.xxx.com","min_cli_version":null, "min_recommended_cli_version":null,"api_version":"2.25.0", "logging_endpoint":"wss://loggregator.paaslab3.xxx.com:443"} We normally have ldap authentication enabled and require ssl between the login server and uaa but even after disabling all of that and running with what I think is a pretty simple and standard configuration we get the error. Thank you for taking the time to look into this. -- Jon From: cf-dev-bounces(a)lists.cloudfoundry.org<mailto:cf-dev-bounces(a)lists.cloudfoundry.org> [mailto:cf-dev-bounces(a)lists.cloudfoundry.org] On Behalf Of Iovanov, Vlad Mircea Sent: Friday, May 15, 2015 10:52 AM To: cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org> Subject: Re: [cf-dev] visual studio extension - login error Hello Jon, Can you please let me know what version of Cloud Foundry you are running? If you could include the output of your "info" endpoint it would be great (http://apidocs.cloudfoundry.org/208/info/get_info.html) Cheers, Vlad
|
|
Re: visual studio extension - login error
Vlad Iovanov
Hello Jon,
Can you please try to upgrade the Visual Studio Extensions to latest (1.2.0.4)? We've published a new version that should address the login problems you've been experiencing. New versions of the .NET SDK and MSBuild tasks have also been published. Cheers, Vlad From: Price, Jon [mailto:jon.price(a)intel.com] Sent: Friday, May 15, 2015 11:49 AM To: Iovanov, Vlad Mircea; cf-dev(a)lists.cloudfoundry.org Subject: RE: [cf-dev] visual studio extension - login error Hi Vlad, We are running CF release 207. Here is the /v2/info output with some of the data sanitized: {"name":"vcap","build":"2222","support":"http://url.removed", "authorization_endpoint":"https://login.paaslab3.xxx.com", "token_endpoint":"https://uaa.paaslab3.xxx.com","min_cli_version":null, "min_recommended_cli_version":null,"api_version":"2.25.0", "logging_endpoint":"wss://loggregator.paaslab3.xxx.com:443"} We normally have ldap authentication enabled and require ssl between the login server and uaa but even after disabling all of that and running with what I think is a pretty simple and standard configuration we get the error. Thank you for taking the time to look into this. -- Jon From: cf-dev-bounces(a)lists.cloudfoundry.org<mailto:cf-dev-bounces(a)lists.cloudfoundry.org> [mailto:cf-dev-bounces(a)lists.cloudfoundry.org] On Behalf Of Iovanov, Vlad Mircea Sent: Friday, May 15, 2015 10:52 AM To: cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org> Subject: Re: [cf-dev] visual studio extension - login error Hello Jon, Can you please let me know what version of Cloud Foundry you are running? If you could include the output of your "info" endpoint it would be great (http://apidocs.cloudfoundry.org/208/info/get_info.html) Cheers, Vlad
|
|
Re: TCP Router VS NoRouter
Mike Youngstrom
Hi Owais,
What are you referring to when you say you're concerned about the LTM becoming a Monolith? Too much functionality in one component? Too much of the system depending on one component? Chip, Hopefully it's ok to discuss NoRouter here even though it isn't an official CF project. Let us know if it is not. Mike On Fri, May 15, 2015 at 10:55 AM, Chip Childers <cchilders(a)cloudfoundry.org> wrote: The "norouter", while interesting, isn't the official CF project approach
|
|
Re: Follow up on multiple line log outputs in CF
George Li
Any build-in support for multiline logging would be nice. Seeing content in
toggle quoted messageShow quoted text
one call to log4j's log.error() spreading over numerous logging records really sucks, especially for exception stacktrace.
On Mon, May 18, 2015 at 11:59 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:
I don't believe there is a solution in raw Loggregator to fix this.
|
|
Re: Follow up on multiple line log outputs in CF
Mike Youngstrom
I don't believe there is a solution in raw Loggregator to fix this.
Multi line log messages is a major issue we deal with regularly today in our deployment. Although there are workarounds to the issue like the logstash config you posted, it is somewhat dependent upon how the application logs are formatted which is sub optimal. I'd personally like to see a syslog port available to the app container that applications can send logs to in addition to channeling STDERR and STDOUT. That would make issues like much easier to handle downstream and would help eliminate deployed app specific hacks like we have to do today in logstash. I talked with a LAMB engineer at Summit and they didn't believe syslog for deployed apps was anywhere on the LAMB roadmap. Can anyone confirm that? I could have sworn I'd heard mention of syslog for app mentioned in the past. Mike On Mon, May 18, 2015 at 9:32 AM, Li, George <guangxing.li(a)pearson.com> wrote: James,
|
|
Re: Issues running UAA 2.1.0+ locally and on CF
Josh Ghiloni
Interesting, will do.
toggle quoted messageShow quoted text
Josh Ghiloni Senior Consultant 303.932.2202 o | 303.590.5427 m | 303.565.2794 f jghiloni(a)ecsteam.com<mailto:jghiloni(a)ecsteam.com> ECS Team Technology Solutions Delivered ECSTeam.com<http://ECSTeam.com>
On May 18, 2015, at 10:55 AM, Filip Hanik <fhanik(a)pivotal.io<mailto:fhanik(a)pivotal.io>> wrote:
Good news and bad news, bad news that you have a problem good news is that it is happening during "./gradlew run" which means it is easily reproducible and thus, easily fixable. Since our Travis CI runs the embedded gradle cargo container, we can know for certain that ./gradlew run does indeed work and the login page will be available at http://localhost:8080/uaa/login My first guess is that your gradle cache may contain some library that has mutated. So, prepare yourself to download the internet and my recommendation would be to blow away your ~/.gradle directory and try './gradlew run' again with the master branch Let us know the results Filip On Mon, May 18, 2015 at 10:10 AM, Josh Ghiloni <jghiloni(a)ecsteam.com<mailto:jghiloni(a)ecsteam.com>> wrote: Hi all, We recently put up CF v207 and are trying to deploy UAA into the apps area that we use for SSO between our micro services. Before this, we’d been running 2.0.3 with no issues. However, when I tried to upgrade to 2.2.6, any pages we tried to hit resulted in an HTTP 404 and redirected to the error page, which renders, though all linked stylesheets and images also returned 404s. We reverted to 2.0.3 because we didn’t need anything in the newer version at this time, but it’s an odd issue, and i’m wondering if anyone else has hit it. FWIW, this also happens with ver 2.1.0, and it happens locally (when I run `gradlew run`) as well for those versions. Does this have anything to do with the introduction of multi-tenancy? Any insights would be appreciated, because the logs aren’t really showing anything. Thanks! Josh Ghiloni Senior Consultant 303.932.2202<tel:303.932.2202> o | 303.590.5427<tel:303.590.5427> m | 303.565.2794<tel:303.565.2794> f jghiloni(a)ecsteam.com<mailto:jghiloni(a)ecsteam.com> ECS Team Technology Solutions Delivered ECSTeam.com<http://ecsteam.com/> _______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org> https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
Re: Issues running UAA 2.1.0+ locally and on CF
Filip Hanik
Good news and bad news,
toggle quoted messageShow quoted text
bad news that you have a problem good news is that it is happening during "./gradlew run" which means it is easily reproducible and thus, easily fixable. Since our Travis CI runs the embedded gradle cargo container, we can know for certain that ./gradlew run does indeed work and the login page will be available at http://localhost:8080/uaa/login My first guess is that your gradle cache may contain some library that has mutated. So, prepare yourself to download the internet and my recommendation would be to blow away your ~/.gradle directory and try './gradlew run' again with the master branch Let us know the results Filip
On Mon, May 18, 2015 at 10:10 AM, Josh Ghiloni <jghiloni(a)ecsteam.com> wrote:
Hi all,
|
|
Issues running UAA 2.1.0+ locally and on CF
Josh Ghiloni
Hi all,
We recently put up CF v207 and are trying to deploy UAA into the apps area that we use for SSO between our micro services. Before this, we’d been running 2.0.3 with no issues. However, when I tried to upgrade to 2.2.6, any pages we tried to hit resulted in an HTTP 404 and redirected to the error page, which renders, though all linked stylesheets and images also returned 404s. We reverted to 2.0.3 because we didn’t need anything in the newer version at this time, but it’s an odd issue, and i’m wondering if anyone else has hit it. FWIW, this also happens with ver 2.1.0, and it happens locally (when I run `gradlew run`) as well for those versions. Does this have anything to do with the introduction of multi-tenancy? Any insights would be appreciated, because the logs aren’t really showing anything. Thanks! Josh Ghiloni Senior Consultant 303.932.2202 o | 303.590.5427 m | 303.565.2794 f jghiloni(a)ecsteam.com<mailto:jghiloni(a)ecsteam.com> ECS Team Technology Solutions Delivered ECSTeam.com<http://ECSTeam.com>
|
|