Date   

Re: Reg cant find template : metron_agent

Jayarajan Ramapurath Kozhummal (jayark) <jayark@...>
 

Thanks a lot Rohit for replying back very quickly!
I have run the scripts/update command after cloning the cf-release GIT repo.
Please see the command output below:-


root(a)automation-vm-jayark:/opt/cisco/vms-installer/cf-release/src/loggregator# find . -type d -maxdepth 2

find: warning: you have specified the -maxdepth option after a non-option argument -type, but options are not positional (-maxdepth affects tests specified before it as well as those specified after it). Please specify options before other arguments.


.

./src

./src/doppler

./src/loggregator

./src/trafficcontroller

./src/syslog_drain_binder

./src/bitbucket.org

./src/monitor

./src/matchers

./src/signalmanager

./src/deaagent

./src/tools

./src/truncatingbuffer

./src/profiler

./src/logger

./src/lats

./src/common

./src/integration_tests

./src/metron

./src/github.com

./packages

./packages/doppler

./packages/loggregator_trafficcontroller

./packages/syslog_drain_binder

./packages/dea_logging_agent

./packages/loggregator_common

./packages/loggregator-acceptance-tests

./packages/golang1.4

./packages/metron_agent

./docs

./config

./jobs

./jobs/doppler

./jobs/loggregator_trafficcontroller

./jobs/syslog_drain_binder

./jobs/dea_logging_agent

./jobs/loggregator-acceptance-tests

./jobs/metron_agent

./bin

./git-hooks

./samples

Thanks
Jayaraj

From: Rohit Kumar <rokumar(a)pivotal.io<mailto:rokumar(a)pivotal.io>>
Date: Tuesday, February 16, 2016 at 9:30 AM
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>>
Cc: Jayarajan Ramapurath Kozhummal <jayark(a)cisco.com<mailto:jayark(a)cisco.com>>
Subject: Re: [cf-dev] Reg cant find template : metron_agent

Did you make sure to run "scripts/update" after cloning the cf-release repo? Can you run "find . -type d -maxdepth 2" from within the "src/loggregator" directory in cf-release and reply with what you get as output?

Rohit

On Tue, Feb 16, 2016 at 1:39 AM, Nithiyasri Gnanasekaran -X (ngnanase - TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com<mailto:ngnanase(a)cisco.com>> wrote:
Hi

I am working on cloud foundry and I could create a development bosh release of cloud foundry using the following source:
git clone https://github.com/cloudfoundry/cf-release.git (added some rules in haproxy.conf file)

When I tried to deploy with the dev release of cloud-foundry, I get the following error:

Started preparing deployment
Started preparing deployment > Binding releases. Done (00:00:00)
Started preparing deployment > Binding existing deployment. Done (00:00:00)
Started preparing deployment > Binding resource pools. Done (00:00:00)
Started preparing deployment > Binding stemcells. Done (00:00:00)
Started preparing deployment > Binding templates. Failed: Can't find template `metron_agent' (00:00:00)

Error 190012: Can't find template `metron_agent'

Kindly help me figure out the issue of the error, as this is a show-stopper for us..

Regards
Nithiaysri


Re: database migration

Amit Kumar Gupta
 

Hey Jeff,

Can you describe the burden you're feeling from the monolithic deployment?

We are actively working on splitting up *cf-release* into multiple smaller,
reusable, composable *releases*, but the *manifest deployment* will stay as
one unit to make it easier to ensure that your pieces are working together,
configurations make sense together, and knowing the state of your full
cluster is easier (if you're upgrading e.g. how do you know you've upgraded
all your smaller deployments if you separate them?)

Cheers,
Amit

On Mon, Feb 15, 2016 at 10:46 AM, Jeff Weber <jweber(a)cofront.net> wrote:

I've got a monolithic CF deployment that has become quite a burden to
upgraded because of it's all releases in one manifest nature. I'm currently
working on a plan to cleanup and disaggregate and the first step is to
migrate my core database into its own separate deployment.

After putting my plan together I wanted to confirm it's as simple as it
seems:

1) Deploy new database cluster
2) Stop CF services
3) Perform backup of databases on old cluster
4) Restore backups to new cluster
5) Reconfigure manifest to point to new database cluster
6) Redeploy / Start CF services with new manifest
7) Validate
8) Remove old database instance from the manifest

Is there anything outside of these basic steps to watch out for as gotchas
or should this be a straight forward set of tasks?


routing-api and cf-230?

Tom Sherrod <tom.sherrod@...>
 

Openstack, cf 230

Following a manifest for 225, routing-api is part of the api_z instance.
Generating the manifest for 230, routing-api is not included. Following on what worked, I added it. Api would not start.
routing-api failed:
{"timestamp":"1455647513.437552214","source":"routing-api","message":"routing-api.uaa-key-fetcher.fetch-key-started","log_level":1,"d
ata":{"session":"1"}}
{"timestamp":"1455647513.450663328","source":"routing-api","message":"routing-api.uaa-key-fetcher.http-error-fetching-key","log_level
":2,"data":{"error":"http-error-fetching-key","session":"1"}}
{"timestamp":"1455647513.450931787","source":"routing-api","message":"routing-api.uaa-key-fetcher.fetch-key-completed","log_level":1,
"data":{"session":"1"}}
{"timestamp":"1455647513.451057196","source":"routing-api","message":"routing-api.Failed to get verification key from UAA","log_level
":2,"data":{"error":"http-error-fetching-key"}}
{"timestamp":"1455647583.828899622","source":"routing-api","message":"routing-api.database","log_level":1,"data":{"etcd-addresses":["
http://192.168.20.19:4001"]}}

Removed routing-api. CF deploy works fine, all appears ok.
What features will I lose with this not being deployed? We have scripts make rest calls for routes. I haven't taken a crack at those yet.
Any additional pointers welcome.

Thanks,
Tom


Re: database migration

James Bayer
 

that looks pretty good. i'd probably change the following:

8) Stop jobs on old database cluster
9) Validate CF is working and connected to new database
10) Validate old database files are not changed since last backup and
back-up to new set of backup files just in case
11) Remove old database instance from the manifest

On Mon, Feb 15, 2016 at 10:46 AM, Jeff Weber <jweber(a)cofront.net> wrote:

I've got a monolithic CF deployment that has become quite a burden to
upgraded because of it's all releases in one manifest nature. I'm currently
working on a plan to cleanup and disaggregate and the first step is to
migrate my core database into its own separate deployment.

After putting my plan together I wanted to confirm it's as simple as it
seems:

1) Deploy new database cluster
2) Stop CF services
3) Perform backup of databases on old cluster
4) Restore backups to new cluster
5) Reconfigure manifest to point to new database cluster
6) Redeploy / Start CF services with new manifest
7) Validate
8) Remove old database instance from the manifest

Is there anything outside of these basic steps to watch out for as gotchas
or should this be a straight forward set of tasks?
--
Thank you,

James Bayer


Re: Reg cant find template : metron_agent

Rohit Kumar
 

Did you make sure to run "scripts/update" after cloning the cf-release
repo? Can you run "find . -type d -maxdepth 2" from within the
"src/loggregator" directory in cf-release and reply with what you get as
output?

Rohit

On Tue, Feb 16, 2016 at 1:39 AM, Nithiyasri Gnanasekaran -X (ngnanase -
TECH MAHINDRA LIM at Cisco) <ngnanase(a)cisco.com> wrote:

Hi



I am working on cloud foundry and I could create a development bosh
release of cloud foundry using the following source:

git clone https://github.com/cloudfoundry/cf-release.git (added some
rules in haproxy.conf file)



When I tried to deploy with the dev release of cloud-foundry, I get the
following error:



Started preparing deployment

Started preparing deployment > Binding releases. Done (00:00:00)

Started preparing deployment > Binding existing deployment. Done
(00:00:00)

Started preparing deployment > Binding resource pools. Done (00:00:00)

Started preparing deployment > Binding stemcells. Done (00:00:00)

Started preparing deployment > Binding templates. Failed: Can't find
template `metron_agent' (00:00:00)



Error 190012: Can't find template `metron_agent'



Kindly help me figure out the issue of the error, as this is a
show-stopper for us..



Regards

Nithiaysri





Re: Making UAA work with Openstack Keystone

Noburou TANIGUCHI
 

Thank you, Filip.

Your information makes the situation clear.
Now our team can go to the next step considering how to cope with the
situation.


Filip Hanik wrote
Yes, Keystone support was intentionally removed.
There were no contributions, and the keystone repository kept changing
making our continuous integration pipeline break, and there was no one to
support it.
We're happy to accept an working contribution with both tests and code and
we can incorporate it again.

Filip

On Tue, Feb 9, 2016 at 10:30 AM, Noburou TANIGUCHI &lt;
dev(a).m001
&gt; wrote:

Hi team,

We've recently been trying to make UAA work with OpenStack Keystone.

With UAA 2.7.0.3 (used by cf-release v222) or before, they works fine
together, by setting `uaa.keystone.enabled` and
`uaa.keystone.authenticationUrl` properties in BOSH deployment manifest.

However, with UAA 2.7.1 (used by cf-release v223) or after, UAA doesn't
work
properly with Keystone.

It outputs logs on startup such like:

```
YamlConfigurationValidator: Failed to load YAML validation bean. Your
YAML
file may be invalid.
Can't construct a java object for
tag:yaml.org,2002:org.cloudfoundry.identity.uaa.UaaConfiguration;
exception=Cannot create property=keystone for
JavaBean=org.cloudfoundry.identity.uaa.UaaConfiguration(a)4b0efc0d; Unable
to
find property 'keystone' on class:
org.cloudfoundry.identity.uaa.UaaConfiguration
```

then become running. But when we try to authenticate a user only in the
Keystone server, simply it fails.

Finally we've found the reason why authentication fails.

In UAA 2.7.0.3, DynamicZoneAwareAuthenticationManager#authenticate is:


https://github.com/cloudfoundry/uaa/blob/2.7.0.3/login/src/main/java/org/cloudfoundry/identity/uaa/authentication/manager/DynamicZoneAwareAuthenticationManager.java#L61-L71

```
61 @Override
62 public Authentication authenticate(Authentication authentication)
throws AuthenticationException {
63 IdentityZone zone = IdentityZoneHolder.get();
64 //if zone==uaa just use the authzAuthenticationMgr bean
65 if (zone.equals(IdentityZone.getUaa())) {
66 return
authzAuthenticationMgr.authenticate(authentication);
67 } else {
68 //chain it exactly like the UAA
69 return
getChainedAuthenticationManager(zone).authenticate(authentication);
70 }
71 }
```

And when the uaa.keystone properties exist in BOSH deployment manifest,
the
zone of Keystone identity provider becomes `uaa`, so the first `if`
(l.65)
falls `true` and `authzAuthenticationMgr.authenticate(authentication)` is
called.

But UAA v2.7.1, the same method is:


https://github.com/cloudfoundry/uaa/blob/2.7.1/login/src/main/java/org/cloudfoundry/identity/uaa/authentication/manager/DynamicZoneAwareAuthenticationManager.java#L58-L63

```
58 @Override
59 public Authentication authenticate(Authentication authentication)
throws AuthenticationException {
60 IdentityZone zone = IdentityZoneHolder.get();
61 //chain it exactly like the UAA
62 return
getChainedAuthenticationManager(zone).authenticate(authentication);
63 }
```

There is no `if` and always calling
`getChainedAuthenticationManager(zone).authenticate(authentication)`.

And DynamicZoneAwareAuthenticationManager#getChainedAuthenticationManager
is:


https://github.com/cloudfoundry/uaa/blob/2.7.1/login/src/main/java/org/cloudfoundry/identity/uaa/authentication/manager/DynamicZoneAwareAuthenticationManager.java#L65-L94

```
65 protected ChainedAuthenticationManager
getChainedAuthenticationManager(IdentityZone zone) {
66 IdentityProvider ldapProvider = getProvider(Origin.LDAP,
zone);
67 IdentityProvider uaaProvider = getProvider(Origin.UAA, zone);
68
69 List
<AuthenticationManagerConfiguration>
delegates = new
LinkedList<>();
70
71 if (uaaProvider.isActive()) {
72 AuthenticationManagerConfiguration uaaConfig = new
AuthenticationManagerConfiguration(internalUaaAuthenticationManager,
null);
73 uaaConfig.setStopIf(AccountNotVerifiedException.class,
AuthenticationPolicyRejectionException.class);
74 delegates.add(uaaConfig);
75 }
76
77 if (ldapProvider.isActive()) {
78 //has LDAP IDP config changed since last time?
79 DynamicLdapAuthenticationManager existing =
getLdapAuthenticationManager(zone, ldapProvider);
80 if

(!existing.getDefinition().equals(ldapProvider.getConfigValue(LdapIdentityProviderDefinition.class)))
{
81 ldapAuthManagers.remove(zone);
82 existing.destroy();
83 }
84 DynamicLdapAuthenticationManager ldapAuthenticationManager
=
getLdapAuthenticationManager(zone, ldapProvider);
85 AuthenticationManagerConfiguration ldapConfig =
86 new
AuthenticationManagerConfiguration(ldapAuthenticationManager,
87
delegates.size()>0
? ChainedAuthenticationManager.IF_PREVIOUS_FALSE : null);
88 delegates.add(ldapConfig);
89 }
90
91 ChainedAuthenticationManager result = new
ChainedAuthenticationManager();
92 result.setDelegates(delegates.toArray(new
AuthenticationManagerConfiguration[delegates.size()]));
93 return result;
94 }
```

So it seems only aware of providers whose origin is `Origin.LDAP` or
`Origin.UAA`, not aware of the Keystone provider whose origin is
`Origin.KEYSTONE`.


So my questions are below:

Q1: The change between 2.7.0.3 and 2.7.1 seems excluding the Keystone
support. Is this done intentiolnally? I mean, is the Keystone support
intentionally excluded after 2.7.1?

(One thing that makes tracing the change's intention harder is that the
commit of UAA v2.7.1 is a root commit abruptly emerges in the Git log
graph.
I think it's not like the "Git way".)

If Q1 is "No",

Q2: Is this a bug?

or,

Q3: Is there any way to use UAA (after 2.7.1) with Keystone?


Thanks in advance.




-----
I'm not a ...
noburou taniguchi
--
View this message in context:
http://cf-dev.70369.x6.nabble.com/Making-UAA-work-with-Openstack-Keystone-tp3706.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/Making-UAA-work-with-Openstack-Keystone-tp3706p3779.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: apps logs

Corentin Dupont <corentin.dupont@...>
 

Thanks, it worked!
however the results (attached) does not show the precise start time of
individual containers...
For example the app "bend" goes directly from 16 instances to 26.

I wanted to study the scale-up operation precisely, i.e. see the start time
of each container.
Any way how to do that?

On Wed, Feb 10, 2016 at 6:22 PM, Warren Fernandes <wfernandes(a)pivotal.io>
wrote:

You can obtain the "Authorization: bearer" token using the cf cli.

cf login
cf oauth-token


--

Corentin Dupont
Researcher @ Create-Netwww.corentindupont.info


Re: Making UAA work with Openstack Keystone

Filip Hanik
 

Yes, Keystone support was intentionally removed.
There were no contributions, and the keystone repository kept changing
making our continuous integration pipeline break, and there was no one to
support it.
We're happy to accept an working contribution with both tests and code and
we can incorporate it again.

Filip

On Tue, Feb 9, 2016 at 10:30 AM, Noburou TANIGUCHI <dev(a)nota.m001.jp> wrote:

Hi team,

We've recently been trying to make UAA work with OpenStack Keystone.

With UAA 2.7.0.3 (used by cf-release v222) or before, they works fine
together, by setting `uaa.keystone.enabled` and
`uaa.keystone.authenticationUrl` properties in BOSH deployment manifest.

However, with UAA 2.7.1 (used by cf-release v223) or after, UAA doesn't
work
properly with Keystone.

It outputs logs on startup such like:

```
YamlConfigurationValidator: Failed to load YAML validation bean. Your YAML
file may be invalid.
Can't construct a java object for
tag:yaml.org,2002:org.cloudfoundry.identity.uaa.UaaConfiguration;
exception=Cannot create property=keystone for
JavaBean=org.cloudfoundry.identity.uaa.UaaConfiguration(a)4b0efc0d; Unable
to
find property 'keystone' on class:
org.cloudfoundry.identity.uaa.UaaConfiguration
```

then become running. But when we try to authenticate a user only in the
Keystone server, simply it fails.

Finally we've found the reason why authentication fails.

In UAA 2.7.0.3, DynamicZoneAwareAuthenticationManager#authenticate is:


https://github.com/cloudfoundry/uaa/blob/2.7.0.3/login/src/main/java/org/cloudfoundry/identity/uaa/authentication/manager/DynamicZoneAwareAuthenticationManager.java#L61-L71

```
61 @Override
62 public Authentication authenticate(Authentication authentication)
throws AuthenticationException {
63 IdentityZone zone = IdentityZoneHolder.get();
64 //if zone==uaa just use the authzAuthenticationMgr bean
65 if (zone.equals(IdentityZone.getUaa())) {
66 return authzAuthenticationMgr.authenticate(authentication);
67 } else {
68 //chain it exactly like the UAA
69 return
getChainedAuthenticationManager(zone).authenticate(authentication);
70 }
71 }
```

And when the uaa.keystone properties exist in BOSH deployment manifest, the
zone of Keystone identity provider becomes `uaa`, so the first `if` (l.65)
falls `true` and `authzAuthenticationMgr.authenticate(authentication)` is
called.

But UAA v2.7.1, the same method is:


https://github.com/cloudfoundry/uaa/blob/2.7.1/login/src/main/java/org/cloudfoundry/identity/uaa/authentication/manager/DynamicZoneAwareAuthenticationManager.java#L58-L63

```
58 @Override
59 public Authentication authenticate(Authentication authentication)
throws AuthenticationException {
60 IdentityZone zone = IdentityZoneHolder.get();
61 //chain it exactly like the UAA
62 return
getChainedAuthenticationManager(zone).authenticate(authentication);
63 }
```

There is no `if` and always calling
`getChainedAuthenticationManager(zone).authenticate(authentication)`.

And DynamicZoneAwareAuthenticationManager#getChainedAuthenticationManager
is:


https://github.com/cloudfoundry/uaa/blob/2.7.1/login/src/main/java/org/cloudfoundry/identity/uaa/authentication/manager/DynamicZoneAwareAuthenticationManager.java#L65-L94

```
65 protected ChainedAuthenticationManager
getChainedAuthenticationManager(IdentityZone zone) {
66 IdentityProvider ldapProvider = getProvider(Origin.LDAP, zone);
67 IdentityProvider uaaProvider = getProvider(Origin.UAA, zone);
68
69 List<AuthenticationManagerConfiguration> delegates = new
LinkedList<>();
70
71 if (uaaProvider.isActive()) {
72 AuthenticationManagerConfiguration uaaConfig = new
AuthenticationManagerConfiguration(internalUaaAuthenticationManager, null);
73 uaaConfig.setStopIf(AccountNotVerifiedException.class,
AuthenticationPolicyRejectionException.class);
74 delegates.add(uaaConfig);
75 }
76
77 if (ldapProvider.isActive()) {
78 //has LDAP IDP config changed since last time?
79 DynamicLdapAuthenticationManager existing =
getLdapAuthenticationManager(zone, ldapProvider);
80 if

(!existing.getDefinition().equals(ldapProvider.getConfigValue(LdapIdentityProviderDefinition.class)))
{
81 ldapAuthManagers.remove(zone);
82 existing.destroy();
83 }
84 DynamicLdapAuthenticationManager ldapAuthenticationManager =
getLdapAuthenticationManager(zone, ldapProvider);
85 AuthenticationManagerConfiguration ldapConfig =
86 new
AuthenticationManagerConfiguration(ldapAuthenticationManager,
87
delegates.size()>0
? ChainedAuthenticationManager.IF_PREVIOUS_FALSE : null);
88 delegates.add(ldapConfig);
89 }
90
91 ChainedAuthenticationManager result = new
ChainedAuthenticationManager();
92 result.setDelegates(delegates.toArray(new
AuthenticationManagerConfiguration[delegates.size()]));
93 return result;
94 }
```

So it seems only aware of providers whose origin is `Origin.LDAP` or
`Origin.UAA`, not aware of the Keystone provider whose origin is
`Origin.KEYSTONE`.


So my questions are below:

Q1: The change between 2.7.0.3 and 2.7.1 seems excluding the Keystone
support. Is this done intentiolnally? I mean, is the Keystone support
intentionally excluded after 2.7.1?

(One thing that makes tracing the change's intention harder is that the
commit of UAA v2.7.1 is a root commit abruptly emerges in the Git log
graph.
I think it's not like the "Git way".)

If Q1 is "No",

Q2: Is this a bug?

or,

Q3: Is there any way to use UAA (after 2.7.1) with Keystone?


Thanks in advance.




-----
I'm not a ...
noburou taniguchi
--
View this message in context:
http://cf-dev.70369.x6.nabble.com/Making-UAA-work-with-Openstack-Keystone-tp3706.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: Diego: Permission denied when starting application with startup command

Daniel Mikusa
 

On Tue, Feb 16, 2016 at 4:21 AM, Meng, Xiangyi <xiangyi.meng(a)emc.com> wrote:

Hi,



Our application is started by a shell script. So we pushed our application
with –c option. It works fine with dea. Application could be started
successfully. But when I pushed the application into diego, I got “bash
bin/start.sh permission denied”. I also found if I pushed and started the
application into dea first and enabled diego later, the error was gone. I
guess that is because dea will update file permission during staging.
I suspect you're running into this:

https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/migrating-to-diego.md#file-permission-modes




I also tried to grant permission when zipping the applciation. But diego
totally ignore the setting. Could someone help me to solve this problem?
What version of cf are you using? What is your OS? What do you mean by
"grant permission when zipping the application", what commands are you
running to do that?

Dan



Re: Cloud Foundry being used for an EU social learning games platform

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

Many thanks for the invitation


Re: Binding an App to the controller hostname

Tim Lawrence
 

Thanks,

I guessed this would be the recommendation. I was slightly surprised there is no function for this built in.
The suggestion about adding routes In a system domain is good too although do you think there is any value in a system wide "reserved routes" feature? One which didn't require a system org..

Sent from my iPad

On 16 Feb 2016, at 10:11, James Leavers <james(a)cloudhelix.io> wrote:

Hi,

Do you have separate system & app domains in your manifest? E.g.

properties:
domain: DOMAIN
system_domain: SYSTEM_DOMAIN
app_domains:
- APP_DOMAIN

If so you would be able to push an app to api.APP_DOMAIN, as the cf api is on api.SYS_DOMAIN.

James


On 15 February 2016 at 17:15:00, Tim Lawrence (da_rude2k2(a)yahoo.co.uk) wrote:

Hi all,

We have been testing one of our CF deployments and have found that we can deploy an app bound to the "api" hostname. eg "api.domain.com".
It appears that the router then forwards traffic to this app rather than the CF API. Clearly this is a fairly big problem for us.
This deployment is not currently completely up to date so wondered if anyone else has seen this and if it has patched this in a subsequent release?


Re: Is there any mechanism for restoring the Cloud Foundry state with Diego after rebooting the machine

Nanduni Nimalsiri
 

Hi Hristo,

Thank you so much. The script seems to be very useful to me. I will use it and report you if I get any errors. Thank you again.

Best regards,
Nanduni.


Re: Is there any mechanism for restoring the Cloud Foundry state with Diego after rebooting the machine

Nanduni Nimalsiri
 

Hi Gwenn,

Well I did not know about this 'microPCF'. I found something called MicroCloudFoundry, which I suppose is not available any more. Thank you very much for this valuable information. I will definitely try this out.

Can I deploy docker images using microPCF?

Best regards,
Nanduni


Re: Is there any mechanism for restoring the Cloud Foundry state with Diego after rebooting the machine

Nanduni Nimalsiri
 

Hi Hristo,

Thank you so much. The script seems to be very useful for me. I will use it and report you if I get any errors. Thank you again.

Best regards,
Nanduni.


Re: Is there any mechanism for restoring the Cloud Foundry state with Diego after rebooting the machine

Hristo Iliev
 

I use a script [1] for restoring my BOSH-lite after computer restart.
Basically it starts the VM, adds routes and then targets bosh with specific
deployment manifest so BOSH knows what to check for.

Regards,
Hristo Iliev

[1]
https://github.com/hsiliev/workstation-scripts/blob/master/scripts/restore.sh

2016-02-16 10:03 GMT+02:00 Nanduni Nimalsiri <nandunibw(a)gmail.com>:

Hi Hristo,

Thank you so much for the information. Where should I use this command? Is
it at workspace/cf-release and workspace/diego-release and then enable
Docker support in Cloud Foundry?

Best regards,
Nanduni.


Re: Error dialing loggregator server: unexpected EOF

Felix Friedrich
 

Hello Ramon,

I think I remember having seen this message when we used an Local
Traffic Manager (F5) as the entrypoint. I could not figure out the root
cause, but there obviously went something wrong with the websocket
connection which is used to fetch the logs. If you also use another
entrypoint than ha_proxy, you could use ha_proxy for these kind of
websocket connections by adding a DNS entry for
{loggregator,doppler}.your.cf.installation.com which point to ha_proxy
rather than the entrypoint used for all other traffic.


Felix

On Fri, 12 Feb 2016, at 12:24, Ramon Makkelie wrote:
i just created a new cloudfoundry deployment for testing purposes
and i can push a application but the the following error

Warning: error tailing logs
Error dialing loggregator server: unexpected EOF.
Please ask your Cloud Foundry Operator to check the platform
configuration (loggregator endpoint is
wss://loggregator.cf.dev.eden.klm.com:4443).

cf logs trace http://pastebin.com/KkpAJ8x0

doppler/loggeragor logs http://pastebin.com/c8giCvua

deployment manifest http://pastebin.com/XQMfWqDJ

can maby someone point me in the right direction?
i think im missing something


Re: Binding an App to the controller hostname

Jesse T. Alford
 

Tim,

Alternatively, if you don't want to have a separate system domain for
whatever reason, I recommend you create a "system" org and space with the
admin account and use create-route to reserve any routes you'd like to make
unavailable for use by apps on the shared domain. Having a separate system
domain is definitely cleaner, but if that doesn't work for you, this should
help.

On Tue, Feb 16, 2016 at 12:12 PM James Leavers <james(a)cloudhelix.io> wrote:

Hi,

Do you have separate system & app domains in your manifest? E.g.

properties:
domain: DOMAIN
system_domain: SYSTEM_DOMAIN
app_domains:
- APP_DOMAIN

If so you would be able to push an app to api.APP_DOMAIN, as the cf api is
on api.SYS_DOMAIN.

James


On 15 February 2016 at 17:15:00, Tim Lawrence (da_rude2k2(a)yahoo.co.uk)
wrote:

Hi all,

We have been testing one of our CF deployments and have found that we can
deploy an app bound to the "api" hostname. eg "api.domain.com".
It appears that the router then forwards traffic to this app rather than
the CF API. Clearly this is a fairly big problem for us.
This deployment is not currently completely up to date so wondered if
anyone else has seen this and if it has patched this in a subsequent
release?


Re: Binding an App to the controller hostname

James Leavers
 

Hi,

Do you have separate system & app domains in your manifest? E.g.

properties:
  domain: DOMAIN
  system_domain: SYSTEM_DOMAIN
  app_domains:
   - APP_DOMAIN

If so you would be able to push an app to api.APP_DOMAIN, as the cf api is on api.SYS_DOMAIN.

James

On 15 February 2016 at 17:15:00, Tim Lawrence (da_rude2k2(a)yahoo.co.uk) wrote:

Hi all,

We have been testing one of our CF deployments and have found that we can deploy an app bound to the "api" hostname. eg "api.domain.com".
It appears that the router then forwards traffic to this app rather than the CF API. Clearly this is a fairly big problem for us.
This deployment is not currently completely up to date so wondered if anyone else has seen this and if it has patched this in a subsequent release?


Re: Cloud Foundry being used for an EU social learning games platform

Dieu Cao <dcao@...>
 

Dr. Nic created the cloudfoundry-community github org but anyone who is a
current member of the org can invite others.
I've sent you an invite.

Please keep in mind that org is not managed by the Cloud Foundry Foundation.

-Dieu
CF CAPI PM




On Wed, Jan 27, 2016 at 2:39 AM, Juan Antonio Breña Moral <
bren(a)juanantonio.info> wrote:

Good morning Danny,

"This is interesting and I'd like to obtain a better understanding of the
use cases this library supports that drove you to publish it"

Can you describe in detail the question?
I suppose that the use case could be similar than Java does. In this stage
the development has the focus on app deployment and a basic interaction
with logging component and uaa provided by pivotal/bluemix and local
instance from nise installer: https://github.com/yudai/cf_nise_installer
but In next months, I would like to add bosh-lite in the tests. Besides, I
would like to increate the tests with the deployment with Docker
containers. In this area, I have some tests, but I recognice that I have to
evolve to bosh-lite:

https://github.com/prosociallearnEU/cf-nodejs-client/blob/master/test/lib/model/cloudcontroller/DockerTests.js

Cheers

Juan Antonio


Diego: Permission denied when starting application with startup command

MaggieMeng
 

Hi,

Our application is started by a shell script. So we pushed our application with -c option. It works fine with dea. Application could be started successfully. But when I pushed the application into diego, I got "bash bin/start.sh permission denied". I also found if I pushed and started the application into dea first and enabled diego later, the error was gone. I guess that is because dea will update file permission during staging.

I also tried to grant permission when zipping the applciation. But diego totally ignore the setting. Could someone help me to solve this problem?

Thanks,
Maggie

5541 - 5560 of 9330