Date   

Re: Permission denied error when unpacking droplet

Rohit Kelapure <rkelapure@...>
 

On Mon, Sep 28, 2015 at 7:03 PM, Amit Gupta <amitkgupta84(a)gmail.com> wrote:

The DEA is trying to run a script in the warden container to untar the
droplet. For some reason, the user executing the script and the file
system permissions in the container in the /home/vcap directory are not
what they're supposed to be. I believe you are deploying and running all
the Cloud Foundry components in a non-standard way. You may wish to try a
more standard deployment, and look at the differences in users and file
system permissions between the standard deployment and your deployment, and
reverse-engineer what would need to be fixed in your deployment to get
things to work. Here's a blog post, at the end it talks about how you can
get a session into a warden container (
http://andypiper.co.uk/2014/02/17/getting-inside-cloud-foundry-for-debug-and-profit/).
Alternatively you can look at the startup scripts used in the standard
deployments, e.g. (
https://github.com/cloudfoundry/cf-release/blob/master/jobs/dea_next/templates/dea_ctl.erb
).

Since you've configured all your components in a very idiosyncratic
manner, it's hard to say generally what you need to fix to get all the
permissions right.
--
Pivotal CF Architect
rkelapure(a)pivotal.io
cell: 9197242524


Re: PHP extension 'gettext' doesn't work?

Daniel Mikusa
 

It seems to be working for me [1] (at least the extension is loading, which
usually means it'll work). Can you provide some details on what you're
seeing?

- what version of PHP are you using?
- how are you enabling the extension: options.json or composer.json?
- what's the full output of `cf push`?
- what's the output of `cf logs` when you try to access a page that uses
`gettext`?

Thanks,

Dan

[1] - http://php-info.cfapps.io/info.php

On Tue, Sep 29, 2015 at 3:56 AM, Hiroaki Ukaji <dt3snow.w(a)gmail.com> wrote:

Hi.

We deployed a php application using 'gettext' extension to manage i18n
function. (*1)

We tried to activate i18n, however, it didn't work in this php application
after all.
We also tested with a simple application which contains 'gettext', but it
seemed that the extension still doesn't work.(*2)

Is there anyone who uses i18n well by using 'gettext' extension in PHP
applications?


----------
(*1)
http://blog.cloudfoundry.gr.jp/2015/09/cf100apps-067-fc2blog.html
----------
(*2)

This result should be `/home/vcap/app/htdocs/locale: Hello, world` , if
'gettext' extension works well.
----------

Thanks.

Hiroaki UKAJI




--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-PHP-extension-gettext-doesn-t-work-tp1984.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: CF API for "general statistics"?

James Bayer
 

if you're using bosh to manage cloud foundry, then the bosh cli has a
command:
bosh vms --vitals

which you can read about here [1], that does a good job of measuring infra
concerns:

- Vitals: Includes load, CPU, memory, swap, system disk, ephemeral disk,
and persistent disk usage for each VM.


[1] http://bosh.io/docs/sysadmin-commands.html#health

On Tue, Sep 29, 2015 at 2:51 AM, Rafal Radecki <radecki.rafal(a)gmail.com>
wrote:

Hi all :)

I got a task to check the possibility to fetch details such as:
- overall used and available memory/storage usage of cf platform
- list of running warden containers, approximation how many can be spawned
additionally
I looked through https://apidocs.cloudfoundry.org/218/ but did not find
anything similar to whats I am looking for.

Are there any options other than standard os level monitoring?

BR,
Rafal.


--
Thank you,

James Bayer


CF API for "general statistics"?

Rafal Radecki
 

Hi all :)

I got a task to check the possibility to fetch details such as:
- overall used and available memory/storage usage of cf platform
- list of running warden containers, approximation how many can be spawned additionally
I looked through https://apidocs.cloudfoundry.org/218/ but did not find anything similar to whats I am looking for.

Are there any options other than standard os level monitoring?

BR,
Rafal.


PHP extension 'gettext' doesn't work?

Hiroaki Ukaji <dt3snow.w@...>
 

Hi.

We deployed a php application using 'gettext' extension to manage i18n
function. (*1)

We tried to activate i18n, however, it didn't work in this php application
after all.
We also tested with a simple application which contains 'gettext', but it
seemed that the extension still doesn't work.(*2)

Is there anyone who uses i18n well by using 'gettext' extension in PHP
applications?


----------
(*1)
http://blog.cloudfoundry.gr.jp/2015/09/cf100apps-067-fc2blog.html
----------
(*2)

This result should be `/home/vcap/app/htdocs/locale: Hello, world` , if
'gettext' extension works well.
----------

Thanks.

Hiroaki UKAJI




--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-PHP-extension-gettext-doesn-t-work-tp1984.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: Permission denied error when unpacking droplet

Amit Gupta
 

The DEA is trying to run a script in the warden container to untar the droplet. For some reason, the user executing the script and the file system permissions in the container in the /home/vcap directory are not what they're supposed to be. I believe you are deploying and running all the Cloud Foundry components in a non-standard way. You may wish to try a more standard deployment, and look at the differences in users and file system permissions between the standard deployment and your deployment, and reverse-engineer what would need to be fixed in your deployment to get things to work. Here's a blog post, at the end it talks about how you can get a session into a warden container (http://andypiper.co.uk/2014/02/17/getting-inside-cloud-foundry-for-debug-and-profit/). Alternatively you can look at the startup scripts used in the standard deployments, e.g. (https://github.com/cloudfoundry/cf-release/blob/master/jobs/dea_next/templates/dea_ctl.erb).

Since you've configured all your components in a very idiosyncratic manner, it's hard to say generally what you need to fix to get all the permissions right.


Re: my app needs to get the number of instances in which its running, (in runtime my app uses this info in my program logic)

CF Runtime
 

This information is not provided to the app. You can see what data is
provided here:
http://docs.run.pivotal.io/devguide/deploy-apps/environment-variable.html#instance-vars

If you want to get this information for you app, the best way would be to
have the app call the API directly and see what the "instances" attribute
is set to.
http://apidocs.cloudfoundry.org/218/apps/retrieve_a_particular_app.html

Joseph
CF Release Integration Team

On Mon, Sep 28, 2015 at 12:14 PM, zooba Sir <myfakename90(a)gmail.com> wrote:

evaluating the performance of my app.
how my app can get the number of instances in which its running. in
runtime it needs this info in my logic.


my app needs to get the number of instances in which its running, (in runtime my app uses this info in my program logic)

Zuba Al
 

evaluating the performance of my app.
how my app can get the number of instances in which its running. in runtime it needs this info in my logic.


Re: Instance crashing after running once. Error: "reason"=>"CRASHED", "exit_status"=>0, "exit_description"=>"app instance exited"

Zuba Al
 

i thought exit with status 0 is error. my app is running good then.
thanks Dan.


Re: postgres out of disk space

Matthias Ender <Matthias.Ender@...>
 

thank you all!
I’m indeed running v212.
Deleting /var/vcap/store/shared/run.10.10.2.37.xip.io-cc-droplets/buildpack_cache
did the trick.


From: CF Runtime [mailto:cfruntime(a)gmail.com]
Sent: Friday, September 25, 2015 6:47 PM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Re: Re: Re: postgres out of disk space
Importance: High

cf-release v213 fixed a bug where buildpack caches were not getting cleaned up properly. Are you running a version prior to 213?

If so, you might need to go into the `shared/run.10.10.2.37.xip.io-cc-droplets` directory and delete the `buildpack_cache` subdirectory. Deleting the contents of buildpack_cache will not cause failures in the system, the caches will simply get generated from scratch the next time apps stage.

If you upgrade to 213 or later, you can just call the api endpoint to clean out the buildpack cache. You can find the details in the v213 release notes:
https://github.com/cloudfoundry/cf-release/releases/tag/v213

Joseph & Natalie
CF Release Integration Team

On Fri, Sep 25, 2015 at 11:53 AM, Matthias Ender <Matthias.Ender(a)sas.com<mailto:Matthias.Ender(a)sas.com>> wrote:
ah, it’s not postgres:

90M postgres

it’s actually:

94G shared/run.10.10.2.37.xip.io-cc-droplets

Does it keep a copy of each artifact ever pushed?
Or is this part of the event storage, controlled by these properties:

app_events:
cutoff_age_in_days: 31
app_usage_events:
cutoff_age_in_days: 31
audit_events:
cutoff_age_in_days: 31

??


From: Aleksey Zalesov [mailto:aleksey.zalesov(a)altoros.com<mailto:aleksey.zalesov(a)altoros.com>]
Sent: Friday, September 25, 2015 12:23 PM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Subject: [cf-dev] Re: postgres out of disk space

Does your database occupy this 100 GB? Or something else like logs?

Aleksey Zalesov | CloudFoundry Engineer | Altoros
Tel: (617) 841-2121 ext. 5707<tel:%28617%29%20841-2121%20ext.%205707> | Toll free: 855-ALTOROS
Fax: (866) 201-3646<tel:%28866%29%20201-3646> | Skype: aleksey_zalesov
www.altoros.com<http://www.altoros.com/> | blog.altoros.com<http://blog.altoros.com/> | twitter.com/altoros<http://twitter.com/altoros>

On 25 Sep 2015, at 14:22, Matthias Ender <Matthias.Ender(a)sas.com<mailto:Matthias.Ender(a)sas.com>> wrote:

I have a cf-aws-tiny cf-boshrelease deployment, and it’s been running well for over 4 months.
We have about 40 apps, with a couple of dozen of cf pushes each day.
Yesterday pushing apps became spotty and then impossible, with various errors.
Turned out the 100GB disk for the postgres instance on the data note was full.
I increased the disk size and things a running again.
But – what happened there? 100G and growing seems like awfully large database for a rather modest use.
And I’m worried it’ll just happen again in a few months.

thanks,
Matthias


Permission denied error when unpacking droplet

Kyle Havlovitz (kyhavlov)
 

I'm getting the following error when pushing an app (dea logs):
{"timestamp":1443390480.7652702,"message":"\"cd /home/vcap/ && tar zxf /tmp/dea_ng/droplets/6ed0ecb3edbc2822ced1d2fb54b6d62b67a86aa8/droplet.tgz\" exited with status 2 with data {:script=>\"cd /home/vcap/ && tar zxf /tmp/dea_ng/droplets/6ed0ecb3edbc2822ced1d2fb54b6d62b67a86aa8/droplet.tgz\", :exit_status=>2, :stdout=>\"\", :stderr=>\"tar: ./logs: Cannot mkdir: Permission denied\\ntar: ./logs: Cannot mkdir: Permission denied\\ntar: ./logs/staging_task.log: Cannot open: No such file or directory\\ntar: ./tmp: Cannot mkdir: Permission denied\\ntar: ./staging_info.yml: Cannot open: Permission denied\\ntar: .: Cannot utime: Operation not permitted\\ntar: Exiting with failure status due to previous errors\\n\"}","log_level":"warn","source":"Container","data":{},"thread_id":69954816652080,"fiber_id":69954833634360,"process_id":26381,"file":"/opt/cloudfoundry/dea_next/lib/container/container.rb","lineno":80,"method":"run_script"}

I'm not sure what's causing this or the permissions needed and for what component here. Any help would be much appreciated.


Re: diego error: failed to initialize container --where to look?

Tom Sherrod <tom.sherrod@...>
 

Lesson: take error messages literally
Cell had a filled disk partition. Yes, insufficient resources.

Changed machine type, and all good.

Tom


Re: postgres out of disk space

CF Runtime
 

Droplets are important, and should not be removed. If an app is deleted,
the droplet will also be deleted. If a droplet exists, that means it is
still needed.

If the app needs to be scaled up or moved to a different runner, the
droplet is reused. In theory droplets could be recreated from the package
if it were deleted, but there is no automated behavior for this. You would
need to `restage` the app to force the system to generate a new droplet
from the existing package.

Joseph
CF Release Integration Team

On Sat, Sep 26, 2015 at 12:24 AM, Zalesov Aleksey <
aleksey.zalesov(a)altoros.com> wrote:

It will be handy to have a configuration option for CC to prune unused
droplets after 7 days of inactivity, for example.

On 26 Sep 2015, at 01:47, CF Runtime <cfruntime(a)gmail.com> wrote:

cf-release v213 fixed a bug where buildpack caches were not getting
cleaned up properly. Are you running a version prior to 213?

If so, you might need to go into the
`shared/run.10.10.2.37.xip.io-cc-droplets` directory and delete the
`buildpack_cache` subdirectory. Deleting the contents of buildpack_cache
will not cause failures in the system, the caches will simply get generated
from scratch the next time apps stage.

If you upgrade to 213 or later, you can just call the api endpoint to
clean out the buildpack cache. You can find the details in the v213 release
notes:
https://github.com/cloudfoundry/cf-release/releases/tag/v213

Joseph & Natalie
CF Release Integration Team

On Fri, Sep 25, 2015 at 11:53 AM, Matthias Ender <Matthias.Ender(a)sas.com>
wrote:

ah, it’s not postgres:



90M postgres



it’s actually:



94G shared/run.10.10.2.37.xip.io-cc-droplets



Does it keep a copy of each artifact ever pushed?

Or is this part of the event storage, controlled by these properties:



app_events:

cutoff_age_in_days: 31

app_usage_events:

cutoff_age_in_days: 31

audit_events:

cutoff_age_in_days: 31



??





*From:* Aleksey Zalesov [mailto:aleksey.zalesov(a)altoros.com]
*Sent:* Friday, September 25, 2015 12:23 PM
*To:* Discussions about Cloud Foundry projects and the system overall. <
cf-dev(a)lists.cloudfoundry.org>
*Subject:* [cf-dev] Re: postgres out of disk space



Does your database occupy this 100 GB? Or something else like logs?



Aleksey Zalesov | CloudFoundry Engineer | Altoros

Tel: (617) 841-2121 ext. 5707 | Toll free: 855-ALTOROS
Fax: (866) 201-3646 | Skype: aleksey_zalesov

www.altoros.com | blog.altoros.com | twitter.com/altoros



On 25 Sep 2015, at 14:22, Matthias Ender <Matthias.Ender(a)sas.com> wrote:



I have a cf-aws-tiny cf-boshrelease deployment, and it’s been running
well for over 4 months.

We have about 40 apps, with a couple of dozen of cf pushes each day.

Yesterday pushing apps became spotty and then impossible, with various
errors.

Turned out the 100GB disk for the postgres instance on the data note was
full.

I increased the disk size and things a running again.

But – what happened there? 100G and growing seems like awfully large
database for a rather modest use.

And I’m worried it’ll just happen again in a few months.



thanks,

Matthias




diego error: failed to initialize container --where to look?

Tom Sherrod <tom.sherrod@...>
 

After upgrade to/deploy diego in multiple environments with success, I'm a bit stumped on error for a new install.

A cf docker-push results in:
015-09-26T16:02:01.65+0000 [API/0] OUT Updated app with guid 7aa5800b-96d3-48a0-b707-1d85680e10c9 ({"state"=>"STARTED"})
2015-09-26T16:02:01.74+0000 [API/0] ERR Failed to stage application: insufficient resources

I back up a step and diego enable an app. Fails on start of app:
2015-09-26T16:14:26.38+0000 [API/0] OUT App instance exited with guid be3f6daa-96d1-41a3-8a3a-2d0ff697f8c4 payload: {"instance"=>"8d1947c6-84cb-4144-4a97-9038a7978ebf", "index"=>0, "reason"=>"CRASHED", "exit_description"=>"failed to initialize container", "crash_count"=>3, "crash_timestamp"=>1443284066323748334, "version"=>"b5a0a268-82f7-445d-937d-4349415b2a70"}

I'm betting it is one machine not being able to talk to another.
What log may provide any additional details on what's failing?

Thanks,
Tom


Re: postgres out of disk space

Aleksey Zalesov
 

It will be handy to have a configuration option for CC to prune unused droplets after 7 days of inactivity, for example.

On 26 Sep 2015, at 01:47, CF Runtime <cfruntime(a)gmail.com<mailto:cfruntime(a)gmail.com>> wrote:

cf-release v213 fixed a bug where buildpack caches were not getting cleaned up properly. Are you running a version prior to 213?

If so, you might need to go into the `shared/run.10.10.2.37.xip.io-cc-droplets` directory and delete the `buildpack_cache` subdirectory. Deleting the contents of buildpack_cache will not cause failures in the system, the caches will simply get generated from scratch the next time apps stage.

If you upgrade to 213 or later, you can just call the api endpoint to clean out the buildpack cache. You can find the details in the v213 release notes:
https://github.com/cloudfoundry/cf-release/releases/tag/v213

Joseph & Natalie
CF Release Integration Team

On Fri, Sep 25, 2015 at 11:53 AM, Matthias Ender <Matthias.Ender(a)sas.com<mailto:Matthias.Ender(a)sas.com>> wrote:
ah, it’s not postgres:

90M postgres

it’s actually:

94G shared/run.10.10.2.37.xip.io-cc-droplets

Does it keep a copy of each artifact ever pushed?
Or is this part of the event storage, controlled by these properties:

app_events:
cutoff_age_in_days: 31
app_usage_events:
cutoff_age_in_days: 31
audit_events:
cutoff_age_in_days: 31

??


From: Aleksey Zalesov [mailto:aleksey.zalesov(a)altoros.com<mailto:aleksey.zalesov(a)altoros.com>]
Sent: Friday, September 25, 2015 12:23 PM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Subject: [cf-dev] Re: postgres out of disk space

Does your database occupy this 100 GB? Or something else like logs?

Aleksey Zalesov | CloudFoundry Engineer | Altoros
Tel: (617) 841-2121 ext. 5707<tel:%28617%29%20841-2121%20ext.%205707> | Toll free: 855-ALTOROS
Fax: (866) 201-3646<tel:%28866%29%20201-3646> | Skype: aleksey_zalesov
www.altoros.com<http://www.altoros.com/> | blog.altoros.com<http://blog.altoros.com/> | twitter.com/altoros<http://twitter.com/altoros>

On 25 Sep 2015, at 14:22, Matthias Ender <Matthias.Ender(a)sas.com<mailto:Matthias.Ender(a)sas.com>> wrote:

I have a cf-aws-tiny cf-boshrelease deployment, and it’s been running well for over 4 months.
We have about 40 apps, with a couple of dozen of cf pushes each day.
Yesterday pushing apps became spotty and then impossible, with various errors.
Turned out the 100GB disk for the postgres instance on the data note was full.
I increased the disk size and things a running again.
But – what happened there? 100G and growing seems like awfully large database for a rather modest use.
And I’m worried it’ll just happen again in a few months.

thanks,
Matthias


Re: postgres out of disk space

CF Runtime
 

cf-release v213 fixed a bug where buildpack caches were not getting cleaned
up properly. Are you running a version prior to 213?

If so, you might need to go into the
`shared/run.10.10.2.37.xip.io-cc-droplets` directory and delete the
`buildpack_cache` subdirectory. Deleting the contents of buildpack_cache
will not cause failures in the system, the caches will simply get generated
from scratch the next time apps stage.

If you upgrade to 213 or later, you can just call the api endpoint to clean
out the buildpack cache. You can find the details in the v213 release notes:
https://github.com/cloudfoundry/cf-release/releases/tag/v213

Joseph & Natalie
CF Release Integration Team

On Fri, Sep 25, 2015 at 11:53 AM, Matthias Ender <Matthias.Ender(a)sas.com>
wrote:

ah, it’s not postgres:



90M postgres



it’s actually:



94G shared/run.10.10.2.37.xip.io-cc-droplets



Does it keep a copy of each artifact ever pushed?

Or is this part of the event storage, controlled by these properties:



app_events:

cutoff_age_in_days: 31

app_usage_events:

cutoff_age_in_days: 31

audit_events:

cutoff_age_in_days: 31



??





*From:* Aleksey Zalesov [mailto:aleksey.zalesov(a)altoros.com]
*Sent:* Friday, September 25, 2015 12:23 PM
*To:* Discussions about Cloud Foundry projects and the system overall. <
cf-dev(a)lists.cloudfoundry.org>
*Subject:* [cf-dev] Re: postgres out of disk space



Does your database occupy this 100 GB? Or something else like logs?



Aleksey Zalesov | CloudFoundry Engineer | Altoros

Tel: (617) 841-2121 ext. 5707 | Toll free: 855-ALTOROS
Fax: (866) 201-3646 | Skype: aleksey_zalesov

www.altoros.com | blog.altoros.com | twitter.com/altoros



On 25 Sep 2015, at 14:22, Matthias Ender <Matthias.Ender(a)sas.com> wrote:



I have a cf-aws-tiny cf-boshrelease deployment, and it’s been running well
for over 4 months.

We have about 40 apps, with a couple of dozen of cf pushes each day.

Yesterday pushing apps became spotty and then impossible, with various
errors.

Turned out the 100GB disk for the postgres instance on the data note was
full.

I increased the disk size and things a running again.

But – what happened there? 100G and growing seems like awfully large
database for a rather modest use.

And I’m worried it’ll just happen again in a few months.



thanks,

Matthias



Re: postgres out of disk space

Matthew Sykes <matthew.sykes@...>
 

Droplets and app packages should be pruned when the applications they're
associated with are deleted. Only one or two versions of the droplet are
ever held and only copy of the application bits.

There's another blob store that holds application resources for resource
match flow when uploading an app. Those resources are not pruned so you
should make sure that you disable that in your manifest if you don't want
that behavior.

The droplet blob store is clearly your issue - not events.

On Fri, Sep 25, 2015 at 2:53 PM, Matthias Ender <Matthias.Ender(a)sas.com>
wrote:

ah, it’s not postgres:



90M postgres



it’s actually:



94G shared/run.10.10.2.37.xip.io-cc-droplets



Does it keep a copy of each artifact ever pushed?

Or is this part of the event storage, controlled by these properties:



app_events:

cutoff_age_in_days: 31

app_usage_events:

cutoff_age_in_days: 31

audit_events:

cutoff_age_in_days: 31



??





*From:* Aleksey Zalesov [mailto:aleksey.zalesov(a)altoros.com]
*Sent:* Friday, September 25, 2015 12:23 PM
*To:* Discussions about Cloud Foundry projects and the system overall. <
cf-dev(a)lists.cloudfoundry.org>
*Subject:* [cf-dev] Re: postgres out of disk space



Does your database occupy this 100 GB? Or something else like logs?



Aleksey Zalesov | CloudFoundry Engineer | Altoros

Tel: (617) 841-2121 ext. 5707 | Toll free: 855-ALTOROS
Fax: (866) 201-3646 | Skype: aleksey_zalesov

www.altoros.com | blog.altoros.com | twitter.com/altoros



On 25 Sep 2015, at 14:22, Matthias Ender <Matthias.Ender(a)sas.com> wrote:



I have a cf-aws-tiny cf-boshrelease deployment, and it’s been running well
for over 4 months.

We have about 40 apps, with a couple of dozen of cf pushes each day.

Yesterday pushing apps became spotty and then impossible, with various
errors.

Turned out the 100GB disk for the postgres instance on the data note was
full.

I increased the disk size and things a running again.

But – what happened there? 100G and growing seems like awfully large
database for a rather modest use.

And I’m worried it’ll just happen again in a few months.



thanks,

Matthias




--
Matthew Sykes
matthew.sykes(a)gmail.com


Re: postgres out of disk space

Matthias Ender <Matthias.Ender@...>
 

ah, it’s not postgres:

90M postgres

it’s actually:

94G shared/run.10.10.2.37.xip.io-cc-droplets

Does it keep a copy of each artifact ever pushed?
Or is this part of the event storage, controlled by these properties:

app_events:
cutoff_age_in_days: 31
app_usage_events:
cutoff_age_in_days: 31
audit_events:
cutoff_age_in_days: 31

??


From: Aleksey Zalesov [mailto:aleksey.zalesov(a)altoros.com]
Sent: Friday, September 25, 2015 12:23 PM
To: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Re: postgres out of disk space

Does your database occupy this 100 GB? Or something else like logs?

Aleksey Zalesov | CloudFoundry Engineer | Altoros
Tel: (617) 841-2121 ext. 5707 | Toll free: 855-ALTOROS
Fax: (866) 201-3646 | Skype: aleksey_zalesov
www.altoros.com<http://www.altoros.com/> | blog.altoros.com<http://blog.altoros.com/> | twitter.com/altoros<http://twitter.com/altoros>

On 25 Sep 2015, at 14:22, Matthias Ender <Matthias.Ender(a)sas.com<mailto:Matthias.Ender(a)sas.com>> wrote:

I have a cf-aws-tiny cf-boshrelease deployment, and it’s been running well for over 4 months.
We have about 40 apps, with a couple of dozen of cf pushes each day.
Yesterday pushing apps became spotty and then impossible, with various errors.
Turned out the 100GB disk for the postgres instance on the data note was full.
I increased the disk size and things a running again.
But – what happened there? 100G and growing seems like awfully large database for a rather modest use.
And I’m worried it’ll just happen again in a few months.

thanks,
Matthias


Re: Environment variable changes in DIEGO

Mike Heath
 

By the `application_uris` data are broken logic, VCAP_SERVICES is also
broken and should be removed as it doesn't reflect service binding changes.

In my (strong) opinion it doesn't make any sense to run an application in a
dynamic environment and NOT expose its route(s). This has a lot of
implications. For example, an application running on Diego can no longer
register itself with a dynamic service registry since the information
needed to route to the application is totally obscured. (i.e. Spring
Cloud's integration with Eureka.)

It makes more sense to me to match the behavior of service bind/unbind by
notifying the user at route map/unmap time that they need to restart their
app for it to see the changes.

-Mike

On Wed, Sep 16, 2015 at 9:09 AM Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:

The changes, in general, were intentional. The `application_uris` data was
always broken as it didn't reflect route changes. I can't speak directly to
the time stamp data.

The host is present still so I don't know why you don't see it.

We also have a migration guide [1]. If you think additional information is
needed there, pull requests would be welcome.

[1]:
https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/migrating-to-diego.md

On Wed, Sep 16, 2015 at 10:19 AM, Jack Cai <greensight(a)gmail.com> wrote:

I notice the below changes in the environment variables of DIEGO:
1. VCAP_APP_HOST & VCAP_APP_PORT are removed.
2. These fields are removed from VCAP_APPLICATION value:
application_uris, started_at, start, started_at_timestamp, host,
state_timestamp

I suppose #1 is intentional. How about #2?

Jack


--
Matthew Sykes
matthew.sykes(a)gmail.com


Re: Running/Deploying UAA as a standalone service (not within CloudFoundry environment)

Filip Hanik
 

hi TJ,
because the UAA supports multi tenancy and it denotes a tenant by using a
subdomain, we need to know what the base URL is.
By default it is localhost

so

http://tenant1.localhost:8080/uaa
http://tenant2.localhost:8080/uaa

would support the 'default' zone at localhost, and tenant1,localhost and
tenant2.localhost tenants.

You can add more default host names to (in addition to localhost) by adding
hostnames to a Yaml configuration file.

zones:
internal:
hostnames:
- example.com
- test.com

and this would now also support

example.com (default tenant/zone)
tenant1.example.com (tenant1)
tenant2.example.com (tenant2)

On Fri, Sep 25, 2015 at 10:20 AM, TJ Brown <tjbrown(a)gmail.com> wrote:

I'm trying to evaluate UAA to be used as a user authentication /
authorization service to be used within a microservice architecture but not
within a CloudFoundry environment. When running UAA using

$ ./gradlew run

the application seems to work locally but I can't access it externally.
So, what do I need to configure to allow access from other hosts?

Also, are there instructions / guides / tutorial for how to deploy uaa on
an existing Tomcat server?

Thanks for your help.

7421 - 7440 of 9422