Date   

Removing ParentRequestID property from dropsonde's HttpStartStop event

Warren Fernandes
 

Hey CF-Dev,

We are making the following changes to the Dropsonde interface library used
by GoRouter to handle managing http headers to build the HttpStartStop
event:

- We replaced the X-CF-RequestID with X-Vcap-Request-ID to be more
consistent with other components.
- We're now using the same UUID X-Vcap-Request-ID that comes into the
InstrumentedRoundTripper rather than regenerating another requestId and
saving the original one as the ParentRequestID for Dropsonde-handled
requests.
- We're removing the ParentRequestID since its no longer necessary and
requests are further distinguishable by the appID.

This could be a backwards-incompatible change for anyone relying on
Dropsonde's behavior surrounding the passing of requestID headers.

This story <https://www.pivotaltracker.com/story/show/113195829> tracks its
progress.

Thanks.
CF-Loggregator


Making UAA work with Openstack Keystone

Noburou TANIGUCHI
 

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: Dc4cities-project post from hsiliev@gmail.com requires approval

Corentin Dupont <corentin.dupont@...>
 

Thanks Hristo.
I'm trying to retrieve the info from the API:

curl "https://api.[your-domain.com]/v2/app_usage_events?results-per-page=1&after_guid=5f9db08a-3e18-4b1e-a09b-14be78eb3dab"
-X GET \
-H "Authorization: bearer
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoidWFhLWlkLTQ2MSIsImVtYWlsIjoiZW1haWwtMzMyQHNvbWVkb21haW4uY29tIiwic2NvcGUiOlsiY2xvdWRfY29udHJvbGxlci5hZG1pbiJdLCJhdWQiOlsiY2xvdWRfY29udHJvbGxlciJdLCJleHAiOjE0NTQ0NTE2Mzl9.4MWgEkbhuyG21w9vyZ_p8UhkY_YU0UoiGdscbqvr5bM"
\
-H "Host: example.org" \
-H "Cookie: "

But how can I get my authorization token?



---------- Forwarded message ----------

From: Hristo Iliev <hsiliev(a)gmail.com>
To: "Discussions about Cloud Foundry projects and the system overall." <
cf-dev(a)lists.cloudfoundry.org>
Cc: dc4cities-project <dc4cities-project(a)create-net-ml.org>
Date: Tue, 9 Feb 2016 17:27:42 +0200
Subject: Re: [cf-dev] apps logs
Hi,

You can check the the App Usage Events API [1]. They are discarded after
some time (default: a month), so you should move the info to a dedicated DB
if you need audit events.

Regards,
Hristo Iliev

[1]
http://apidocs.cloudfoundry.org/230/app_usage_events/list_all_app_usage_events.html

2016-02-09 16:26 GMT+02:00 Corentin Dupont <corentin.dupont(a)create-net.org
:
Hi guys,
I would like to know if there is a log somewhere containing the number of
apps in CF (result of cf apps)? Or a log of the scale up/down commands?
I need to make an analysis of all the scaling up/down operations that
happened on the infrastructure.

Thanks a lot,
Corentin


--

Corentin Dupont
Researcher @ Create-Netwww.corentindupont.info


---------- Forwarded message ----------
From: dc4cities-project-request(a)create-net-ml.org
To:
Cc:
Date: Tue, 09 Feb 2016 16:28:08 +0100
Subject: confirm 44bfd373419fd479aecf4b351db7ff6b9772b32e
If you reply to this message, keeping the Subject: header intact,
Mailman will discard the held message. Do this if the message is
spam. If you reply to this message and include an Approved: header
with the list password in it, the message will be approved for posting
to the list. The Approved: header can also appear in the first line
of the body of the reply.
--

Corentin Dupont
Researcher @ Create-Netwww.corentindupont.info


Re: apps logs

Hristo Iliev
 

Hi,

You can check the the App Usage Events API [1]. They are discarded after
some time (default: a month), so you should move the info to a dedicated DB
if you need audit events.

Regards,
Hristo Iliev

[1]
http://apidocs.cloudfoundry.org/230/app_usage_events/list_all_app_usage_events.html

2016-02-09 16:26 GMT+02:00 Corentin Dupont <corentin.dupont(a)create-net.org>:

Hi guys,
I would like to know if there is a log somewhere containing the number of
apps in CF (result of cf apps)? Or a log of the scale up/down commands?
I need to make an analysis of all the scaling up/down operations that
happened on the infrastructure.

Thanks a lot,
Corentin


--

Corentin Dupont
Researcher @ Create-Netwww.corentindupont.info


Re: Memory settings on the java buildpack

Noburou TANIGUCHI
 

Amishi,

Please give us more information about your question.

1. What is "the memory settings in the java buildpack"?
2. What is "memory sizes"?
3. What did you do with changing "memory sizes",
and how did you confirm they were successfully changed?
4. What is "the memory heuristics"?
5. What did you do with changing "the memory heuristics",
and how did you confirm they failed?

Basically, java-buildpack configures an app memory with
java-buildpack-memory-calculator [1].
It divides the total memory assigned to an app to heap, metaspace, native,
permgen, and stack, depending on its "containers" (you may find the list of
containers at [2]) determined by the `detect` script in java-buildpack.

[1] https://github.com/cloudfoundry/java-buildpack-memory-calculator
[2]
https://github.com/cloudfoundry/java-buildpack/tree/5ceccb103a41c20644a64d74cae8c8f4332598c9/config


Amishi Shah (amishish) wrote
Hey team,

I am trying to modify the memory settings in the java buildpack. I see
that the changes on memory sizes work, but I don't see the memory
heuristics work.

Can anyone please suggest if there is any other change required with the
memory heuristics to take place?

Thanks in advance.

Regards,
Amishi Shah




-----
I'm not a ...
noburou taniguchi
--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-Memory-settings-on-the-java-buildpack-tp3606p3702.html
Sent from the CF Dev mailing list archive at Nabble.com.


apps logs

Corentin Dupont <corentin.dupont@...>
 

Hi guys,
I would like to know if there is a log somewhere containing the number of
apps in CF (result of cf apps)? Or a log of the scale up/down commands?
I need to make an analysis of all the scaling up/down operations that
happened on the infrastructure.

Thanks a lot,
Corentin


--

Corentin Dupont
Researcher @ Create-Netwww.corentindupont.info


Re: app auto-scaling in OSS CF contribution

Darren Ratcliffe
 

Hi Dies,

Have your thoughts on this moved on any since you posted this. We would be really interested to see this in the OSS release

Thanks
Darren


Application failed to stage with Error: 'No such file or directory [STG/0] ERR /usr/bin/env: ruby'

nitin padalia
 

Hi,

I am trying to deploy my app on cloudfoundry using a custom offline buildpack. Buildpack creation goes fine but when I push an app referring that buildpack application fails to stage at compilation step with below error:
No such file or directory [STG/0] ERR /usr/bin/env: ruby

Any pointer, what I am missing here?

Thanks!
-Nitin


Re: Issue in deploying Docker images on Cloud Foundry via Diego

Daniel Mikusa
 

You are correct. PWS is a shared platform and so user account do not and
cannot obtain admin privileges. If you have any additional questions,
please email support(a)run.pivotal.io as this forum is specifically for the
open source projects around CF.

On that note, if you want to play around with Docker support you might
check out bosh-lite [1]. It's a way that you can deploy your own CF
installation on your local machine in a VM. You can then get admin control
and do whatever you want with the system.

[1] - https://github.com/cloudfoundry/bosh-lite

Dan

On Mon, Feb 8, 2016 at 6:01 PM, Nanduni Nimalsiri <nandunibw(a)gmail.com>
wrote:

Thank you.
In that case, I am running the 60 days trial version of Pivotal.io. So I
have no administrator as I suppose. Can I set my account to get admin
privileges or can I set me as an admin?


Re: ERR Failed to stage application: insufficient resources

Amit Kumar Gupta
 

Hey Stanley,

Looks like you have a zombie (Z) process with 99.9% CPU shares, which
sounds like this issue:
https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/VNFKTVQN42SMDNXHA7PWP2K37JQD2I3I/#VNFKTVQN42SMDNXHA7PWP2K37JQD2I3I

This is an issue in the kernel and an official stemcell with the fix is
making its way through the pipelines. In the mean time, you can try the
3146.7 version of the stemcells:
http://bosh.io/stemcells/bosh-aws-xen-ubuntu-trusty-go_agent

But please note that version has not gone through the main CF and Diego
integration test pipelines. The next officially released stemcell should
have the fix for this bug and it will go through the integration test
pipelines tomorrow or the day after.

Best,
Amit

On Thu, Feb 4, 2016 at 11:52 PM, Stanley Shen <meteorping(a)gmail.com> wrote:

Hello, all

I am running into this issue again.

With change cell VM to c3.xlarge(7.5G memory), I have successfully pushed
2 applications to my cf/diego environment.
app1 asked 2g memory and app2 asked 3g memory.

But it failed to push app3 again for same reason, which asks 3g memory too.
I had a look on my cell VM, I do see there are not enough memory for my
app3.

Tasks: 181 total, 1 running, 175 sleeping, 1 stopped, 4 zombie
%Cpu(s): 0.5 us, 25.6 sy, 0.0 ni, 73.6 id, 0.3 wa, 0.0 hi, 0.0 si,
0.0 st
KiB Mem: 7658564 total, 7440796 used, 217768 free, 100632 buffers
KiB Swap: 7663000 total, 14464 used, 7648536 free. 2427600 cached Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
18303 vcap 10 -10 0 0 0 Z 99.9 0.0 4517:57 ruby
28051 root 10 -10 18516 3516 2716 S 1.0 0.0 47:23.30
destroy.sh
18599 root 10 -10 18520 3496 2692 S 0.7 0.0 47:27.56
destroy.sh
9 root 20 0 0 0 0 S 0.3 0.0 1:39.41 rcuos/0
13306 vcap 10 -10 7560576 2.906g 23652 S 0.3 39.8 19:08.94 java
18552 root 10 -10 18516 3480 2680 S 0.3 0.0 9:28.66 stop.sh
24772 vcap 10 -10 564180 15964 6612 S 0.3 0.2 18:39.04 rep
1 root 20 0 33324 3600 2504 S 0.0 0.0 0:08.31 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.03
kthreadd
3 root 20 0 0 0 0 S 0.0 0.0 0:05.72
ksoftirqd/0
5 root 0 -20 0 0 0 S 0.0 0.0 0:00.00
kworker/0:0H
7 root 20 0 0 0 0 S 0.0 0.0 6:08.60
rcu_sched

In my opinion the resource used in staging an application will be released
soon after the stage process is done, but from my testing result, it seems
it's not true.

Can someone give some guide on how to solving this problem?


Re: Auto Mysql Database Creation

Raymond J Steele
 

Thanks! The documentation seems to imply that this can only be done if you have a spring application. Is this true?

“Cloud Foundry provides extensive support for connecting a Spring application to services such as MySQL, PostgreSQL, MongoDB, Redis, and RabbitMQ.”
http://docs.cloudfoundry.org/buildpacks/java/spring-service-bindings.html


Re: Issue with crashing Windows apps on Diego

Aaron Huber
 

It will totally depend on the app/buildpack. For example, the static file
buildpack and PHP buildpack just launch Nginx and then host the application
inside it. As soon as the web server is up it will accept connections so
they would work identically to IIS HWC with just a TCP healthcheck. For
others the framework would still likely start up and accept connections
before the app itself is ready, and again it would be very possible that the
app itself would crash the first time you actually hit it but the
healthcheck would still think the container is healthy.

Again, I'm not arguing that any of that is "good", just that is how the
platform is expected to work with a port check and it should work
consistently. I also agree that the (annoying) 30-60 second app warmup on
.NET makes this even uglier.

Assuming you do eventually make the port healthcheck for Windows work by
checking the port, it should be made to work. My understanding right now is
you do the following (high level):

* Spin up the "container" via the app lifecycle (create user, set quota,
create FW rules, etc.)
* Start up the HWC process
* Start running the healthcheck which hits the root of the app and checks
for 200-299 with a 1s timeout
* Add it to the router once the healthcheck passes

What if you did something like this:

* Spin up the container
* Start up the HWC process
* Hit the app once via HTTP as part of the startup to get the app going
* Put in a hard coded delay like 30 seconds to give the app time to start
(.NET penalty)
* Start the healthcheck after the delay
* Add it to the router when passing

Just brainstorming. :-)

Aaron



--
View this message in context: http://cf-dev.70369.x6.nabble.com/Issue-with-crashing-Windows-apps-on-Diego-tp3586p3695.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: Issue with crashing Windows apps on Diego

Steven Benario
 

My understanding is that because the app droplet itself typically includes
the webserver (as opposed to Windows where the server is run by the host),
it would be rare for the web server to be available before the app is up
and running.

On Windows, it would be the common case for the web server to start
accepting TCP connections almost immediately, and you could wait a long
time before the app is ready. Hence the discrepancy.

Thanks for understanding and weighing in. Looking forward to hearing more
about how disabling the checks works in your environment -- and of course
keep an eye out here for the proposal and updated timeline on the more
robust checks.

Cheers,
Steven

On Mon, Feb 8, 2016 at 4:49 PM, aaron_huber <aaron.m.huber(a)intel.com> wrote:

I understand what you're trying to avoid, I just think that is actually the
normal case for the port healthchecks. Nothing on the Linux or Docker side
ever touches the app so it's entirely possible it will be added to the
router without it actually working and that is what I expect the platform
to
do. Hopefully the more generic HTTP check can be added quickly to all the
right places so that we'll at least have more sensible options.

Now we just have to decide if we hang onto Iron Foundry that just uses a
port check until then, or try to explain to my users that most of their
apps
won't work unless they turn off the healthcheck. I'm expecting most of
them
won't RTFM and we'll get constant complaints about how our .NET support is
broken because their apps won't start up.

Aaron



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/Issue-with-crashing-Windows-apps-on-Diego-tp3586p3690.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: Issue in deploying Docker images on Cloud Foundry via Diego

Nanduni Nimalsiri
 

Thank you.
In that case, I am running the 60 days trial version of Pivotal.io. So I have no administrator as I suppose. Can I set my account to get admin privileges or can I set me as an admin?


Re: Issue with crashing Windows apps on Diego

Aaron Huber
 

I understand what you're trying to avoid, I just think that is actually the
normal case for the port healthchecks. Nothing on the Linux or Docker side
ever touches the app so it's entirely possible it will be added to the
router without it actually working and that is what I expect the platform to
do. Hopefully the more generic HTTP check can be added quickly to all the
right places so that we'll at least have more sensible options.

Now we just have to decide if we hang onto Iron Foundry that just uses a
port check until then, or try to explain to my users that most of their apps
won't work unless they turn off the healthcheck. I'm expecting most of them
won't RTFM and we'll get constant complaints about how our .NET support is
broken because their apps won't start up.

Aaron



--
View this message in context: http://cf-dev.70369.x6.nabble.com/Issue-with-crashing-Windows-apps-on-Diego-tp3586p3690.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: Auto Mysql Database Creation

Steele, Raymond <raymond.steele@...>
 

Thanks! The documentation seems to imply that this can only be done if you have a spring application. Is this true?

"Cloud Foundry provides extensive support for connecting a Spring application to services such as MySQL, PostgreSQL, MongoDB, Redis, and RabbitMQ."
http://docs.cloudfoundry.org/buildpacks/java/spring-service-bindings.html


Re: Auto Mysql Database Creation

Steele, Raymond <raymond.steele@...>
 

Thanks! The documentation seems to imply that this can only be done if you have a spring application. Is this true?

"Cloud Foundry provides extensive support for connecting a Spring application to services such as MySQL, PostgreSQL, MongoDB, Redis, and RabbitMQ."
http://docs.cloudfoundry.org/buildpacks/java/spring-service-bindings.html


Re: Need help for diego deployment

Amit Kumar Gupta
 

Hi Kinjal,

Sorry for the delayed response. Are you still hitting compilation
timeouts? I cannot access the gist you linked to with the debug output of
your failed BOSH task.

Amit

On Tue, Feb 2, 2016 at 10:50 AM, Kinjal Doshi <kindoshi(a)gmail.com> wrote:

Sorry, for the typo I meant 6868

Thanks,
Kinjal

On Tue, Feb 2, 2016 at 11:04 PM, Kinjal Doshi <kindoshi(a)gmail.com> wrote:

Hi Amit,

This does not seem to be a port issue on 6968. I tried the same
deployment by modifying the security groups (both bosh and cf ) to allow
All Protocol All Ports. even wit this change the deployment fails while
compiling packages.

Would be great i you could provide some pointers to have this corrected.
One thing I noticed is that the config ha_proxy is set to null in the
generate deployment manifest.

Thanks,
Kinjal

On Tue, Feb 2, 2016 at 12:35 AM, Kinjal Doshi <kindoshi(a)gmail.com> wrote:

Hi Amit,

I checked the ports on all the security groups and found that 6868 is
enabled on the inbound for 0.0.0.0/0 in all the groups.

Am sending you the the bosh logs on your personal email address.

Would be great if you could please take a look.

Thanks,
Kinjal

On Sat, Jan 30, 2016 at 4:00 AM, Amit Gupta <agupta(a)pivotal.io> wrote:

Hey Kinjal,

Happy to help!

Looks like your director is failing to connect to your compilation
VMs. In your manifest you have a network called "cf1" with an associated
subnet ID and security groups. I believe specifically trying to reach
those VMs on port 6868. Can you look at the security group rules,
including the security groups applied to the micro bosh VM, and see why
there might be problems communicating?

Best,
Amit

On Fri, Jan 29, 2016 at 12:49 PM, Kinjal Doshi <kindoshi(a)gmail.com>
wrote:

Hi Amit,

Really appreciate all the help I receive on this forum. Hats off to
you all.

Here is the deployment log output:
https://gist.github.com/kinjaldoshi/0925fdf6022b079ca2b5

Thanks,
Kinjal

On Sat, Jan 30, 2016 at 2:03 AM, Amit Gupta <agupta(a)pivotal.io> wrote:

Since you started with the "minimal-aws" flow which happens to
document using micro bosh, you should be fine to continue with micro bosh,
instead of the newer bosh-init workflow. You may run into some
discrepancies in the downstream documentation depending on whether it
assumed a bosh-init workflow vs a micro bosh workflow, but we can guide you
through those should you hit any problems.

On Fri, Jan 29, 2016 at 12:24 PM, Kinjal Doshi <kindoshi(a)gmail.com>
wrote:

Hi Amit,

Thanks a lot for the quick response.

I am currently sanitizing the output, will send it soon. In the mean
while, I wanted to confirm if I have created microbosh using the correct
process. I have followed the instructions at:
https://bosh.io/docs/deploy-microbosh-to-aws.html. However, I see
that there are other instructions too to create microbosh as follows:
https://docs.cloudfoundry.org/deploying/aws/setup_aws.html
and
http://bosh.io/docs/init-aws.html

I am guessing I have used the wrong procedure, is taht correct?

Thanks in advance,
Kinjal


On Sat, Jan 30, 2016 at 1:27 AM, Amit Gupta <agupta(a)pivotal.io>
wrote:

Hi Kinjal,

The task logs have sensitive credentials in them. "bosh tasks 255
--debug" will give that output, and will probably also include the full
manifest in the output. You may wish to sanitize the output before sharing
it or send me the output privately (agupta(a)pivotal.io) if you're
concerned about leaking some info.

Best,
Amit

On Fri, Jan 29, 2016 at 11:44 AM, Kinjal Doshi <kindoshi(a)gmail.com>
wrote:

Hi

I have resolved the errors in generating deployment manifest. on
executing bosh deploy, the below error is encountered while compiling
packages:

Started compiling packages
Started compiling packages >
rtr/2d7de4f6fc25938c21c5be87174f95583feb14b5
Started compiling packages >
syslog_drain_binder/3c9c0b02c11c8dba10d059fe07e6d2ee641ec053
Started compiling packages >
routing-api/b4a3e7034c4a925aa42d45419b46ad6b128d92b1
Started compiling packages >
collector/158398837665181c70bd786b46e6f4d772523017
Failed compiling packages >
routing-api/b4a3e7034c4a925aa42d45419b46ad6b128d92b1: Timed out pinging to
dc15da09-8086-4231-a5b4-15efafa27eaf after 600 seconds (00:11:03)
Failed compiling packages >
syslog_drain_binder/3c9c0b02c11c8dba10d059fe07e6d2ee641ec053: Timed out
pinging to d150aff4-095c-4d48-8c6d-f182fc3738c7 after 600 seconds (00:11:03)
Failed compiling packages >
collector/158398837665181c70bd786b46e6f4d772523017: Timed out pinging to
824b2de9-bb39-4b24-8491-4e26f79adb50 after 600 seconds (00:11:03)
Failed compiling packages >
rtr/2d7de4f6fc25938c21c5be87174f95583feb14b5: Timed out pinging to
4d636c66-690a-43e7-8481-71258732d066 after 600 seconds (00:11:35)

Error 450002: Timed out pinging to
dc15da09-8086-4231-a5b4-15efafa27eaf after 600 seconds

Task 255 error

Would be great if some pointers can be provided to proceed
further. Please let me know if the logs for this bosh task are required.

Thanks in advance,
Kinjal


On Fri, Jan 29, 2016 at 10:45 PM, Kinjal Doshi <kindoshi(a)gmail.com
wrote:
Hi Amit,

Please ignore the unresolved nodes error in the above email. I
have been able to correct it, running into some more problems, checking it
right now.

Please do let me know about my question on the dbs, though.

Thanks in advance,
Kinjal

On Fri, Jan 29, 2016 at 1:29 PM, Kinjal Doshi <kindoshi(a)gmail.com
wrote:
Hi Amit,

Thanks a lot for your response on this.

I was trying to use the manifest generation scripts to redeploy
cf but I ran into errors during spiff merge as below:

ubuntu(a)ip-172-31-45-52:~/cf-deployment/cf-release$
scripts/generate_deployment_manifest aws ../cf-stub.yml > cf-deployment.yml
2016/01/29 07:49:05 error generating manifest: unresolved nodes:
(( static_ips(1) )) in
/home/ubuntu/cf-deployment/cf-release/templates/cf-infrastructure-aws.yml
jobs.[0].networks.[0].static_ips
(( static_ips(5, 6, 15, 16, 17, 18, 19, 20) )) in
/home/ubuntu/cf-deployment/cf-release/templates/cf-infrastructure-aws.yml
jobs.[1].networks.[0].static_ips
(( static_ips(27, 28, 29) )) in
/home/ubuntu/cf-deployment/cf-release/templates/cf-infrastructure-aws.yml
jobs.[5].networks.[0].static_ips
(( static_ips(10, 25) )) in
/home/ubuntu/cf-deployment/cf-release/templates/cf-infrastructure-aws.yml
jobs.[6].networks.[0].static_ips


The public gist pointing to the cf-stub created for this attempt
is at: https://gist.github.com/kinjaldoshi/b0dc004876d2a4615c65

I am not very sure but I think this has something to do with the
way I configured the subnets. Could you please guide me on the
corrections required here. I know how (( static_ips(27, 28, 29) )) works,
but not sure why there is a problem in resolving to the required values.

Another question, I have is on the editing instructions at:
http://docs.cloudfoundry.org/deploying/aws/cf-stub.html#editing

For the ccdb and uaadb, as per comments, is it required for me
to create a service and host these DBs as mentioned in the 'Editing
Instructions' column? In that case where can i find the DDL to create the
db and tables?


Thanks a lot in advance,
Kinjal


On Fri, Jan 29, 2016 at 10:31 AM, Amit Gupta <agupta(a)pivotal.io>
wrote:

Hi Kinjal,

The minimal-aws manifest would be quite difficult to augment to
get it to work with diego. You would need to add static IP to your private
network, add a resource pool or increase the size of an existing one, add
the consul job, colocate the consul agent with some of the CF jobs, and add
a few configuration properties that aren't in the minimal one (e.g.
loggregator.tls.ca). It's probably simpler to use the
manifest generations scripts to redeploy cf (before deploying diego).

Use:

*
http://docs.cloudfoundry.org/deploying/common/create_a_manifest.html
* http://docs.cloudfoundry.org/deploying/common/deploy.html

Let us know if you run into some difficulties. These documents
ask you to define stubs, which require you to input data from your AWS IaaS
setup, and may not exactly play nicely with the AWS setup described in the
minimal-aws doc, I'm not sure.

Best,
Amit



On Wed, Jan 27, 2016 at 3:17 AM, Kinjal Doshi <
kindoshi(a)gmail.com> wrote:

Hi Eric,

Thanks a lot for the detailed response to my query.

I used the minimal-aws.yml configuration (
https://github.com/cloudfoundry/cf-release/tree/v226/example_manifests
) to create my deployment manifest which does not have the
consul VMs set up. I am guessing that the first step would be to change
this.

In this case should I use the script generators to generate
the CF deployment manifest and re-deploy cloud foundry, or are there any
other techniques/shorter path for doing this?

Thanks in advance,
Kinjal



On Mon, Jan 25, 2016 at 6:57 AM, Eric Malm <emalm(a)pivotal.io>
wrote:

Hi, Kinjal,

The stub I included in-line in my previous email may not have
come through so well for all mail clients, so I've also included it in a
public gist at
https://gist.github.com/ematpl/149ac1bac691caae0722.

Thanks,
Eric

On Fri, Jan 22, 2016 at 6:32 PM, Eric Malm <emalm(a)pivotal.io>
wrote:

Hi, Kinjal,

Thanks for asking: this is an area in which the Diego team
is looking forward to improving documentation and tooling in the near term.
For the time being, here are some more manual instructions:

Assuming you have AWS infrastructure already provisioned for
your CF deployment (VPC, subnets, NAT box, ELBs, etc.), you should need
only to add one or more additional subnets for the VMs in the Diego
deployment, and optionally an ELB for the SSH proxy routing tier (you can
also use the HAproxy in the CF deployment to do the same load-balancing,
but you'll need to give it an Elastic IP). If you're brave, and can
coordinate the reserved sections in the CF and Diego deployment manifests'
networking configs correctly, you could even share the same subnet(s)
between the two deployments.

Once you have those subnets provisioned, you'll need to
translate their properties into the iaas-settings.yml stub that you supply
to the generate-deployment-manifest script in diego-release. Since you're
deploying CF v226, we recommend you use Diego final version v0.1442.0 and
the associated manifest-generation script in that version of the release.
The other stubs should be independent of that iaas-settings one, and should
be pretty much the same as the ones for the BOSH-Lite deployment. You'll
likely want to provide different secrets and credentials in the
property-overrides stub, though, and perhaps different instance counts
depending on the availability needs of your deployment. I've included at
the end of this email a representative iaas-settings.yml file from one of
the Diego team's environments, with any specific identifiers for AWS
entities replaced by PLACEHOLDER values.

As a side note, if you don't already have the consul VMs
deployed in your CF deployment, you'll need to enable them so that the
Diego components can use it to communicate. We recommend you operate an odd
number of consul VMs: 1 if don't need high availability, and 3 or 5 if you
do (as in a production environment). You can enable them by changing the
instance count on the consul_z1 and consul_z2 jobs in the CF manifest.

After you've customized those stubs and adjusted your CF
manifest if necessary, you can generate the Diego manifest by running
something like the following from your diego-release directory:

$ ./scripts/generate-deployment-manifest \
PATH/TO/MY/CUSTOMIZED-PROPERTY-OVERRIDES.YML \
PATH/TO/MY/CUSTOMIZED-INSTANCE-COUNT-OVERRIDES.YML \

manifest-generation/bosh-lite-stubs/persistent-disk-overrides.yml \
PATH/TO/MY/CUSTOMIZED-IAAS-SETTINGS.YML \
manifest-generation/bosh-lite-stubs/additional-jobs.yml \
manifest-generation/bosh-lite-stubs/release-versions.yml \
PATH/TO/MY/MANIFEST/DIRECTORY \
> PATH/TO/MY/MANIFEST/DIRECTORY/diego.yml

'PATH/TO/MY/MANIFEST/DIRECTORY' should contain your CF
manifest in a file named 'cf.yml'. Also, please note that if you move to CF
v227 or later, which recommend Diego v0.1445.0 or later, the
manifest-generation script has changed to take its stub arguments via
flags, instead of as these positional arguments, and some of the stubs have
changed slightly.

We also realize this is currently an obscure and potentially
error-prone process, and the Diego team does have a couple stories queued
up to do soon to provide more information about how to set up Diego on AWS:

- We plan in
https://www.pivotaltracker.com/story/show/100909610 to
parametrize, document, and publish the tools and additional templates we
use to provision the AWS environments we use for CI and for our developers'
experiments and investigations, all the way from an empty account to a VPC
with BOSH, CF, and Diego.
- We plan in
https://www.pivotaltracker.com/story/show/100909610 to
provide more manual instructions to set up a Diego environment compatible
with the 'minimal-aws' CF deployment manifest and infrastructure settings,
including provisioning any additional infrastructure such as subnets and
translating their information into the stubs for the diego-release
manifest-generation script.

We'll also be eager to adopt and to integrate with the
tooling the CF Infrastructure and CF Release Integration teams will produce
at some point to automate environment bootstrapping and CF manifest
generation as much as possible.

Please let me and the rest of the team know here if you need
further assistance or clarification.

Thanks again,
Eric, CF Runtime Diego PM

*****

Example iaas-settings.yml file, with PLACEHOLDER entries for
your environment's info:

iaas_settings:
compilation_cloud_properties:
availability_zone: us-east-1a
instance_type: c3.large
resource_pool_cloud_properties:
- cloud_properties:
availability_zone: us-east-1a
elbs:
- PLACEHOLDER-SSHProxyELB-ID
instance_type: m3.medium
name: access_z1
- cloud_properties:
availability_zone: us-east-1b
elbs:
- PLACEHOLDER-SSHProxyELB-ID
instance_type: m3.medium
name: access_z2
- cloud_properties:
availability_zone: us-east-1c
elbs:
- PLACEHOLDER-SSHProxyELB-ID
instance_type: m3.medium
name: access_z3
- cloud_properties:
availability_zone: us-east-1a
instance_type: m3.medium
name: brain_z1
- cloud_properties:
availability_zone: us-east-1b
instance_type: m3.medium
name: brain_z2
- cloud_properties:
availability_zone: us-east-1c
instance_type: m3.medium
name: brain_z3
- cloud_properties:
availability_zone: us-east-1a
instance_type: m3.medium
name: cc_bridge_z1
- cloud_properties:
availability_zone: us-east-1b
instance_type: m3.medium
name: cc_bridge_z2
- cloud_properties:
availability_zone: us-east-1c
instance_type: m3.medium
name: cc_bridge_z3
- cloud_properties:
availability_zone: us-east-1a
ephemeral_disk:
iops: 1200
size: 50000
type: io1
instance_type: m3.large
name: cell_z1
- cloud_properties:
availability_zone: us-east-1b
ephemeral_disk:
iops: 1200
size: 50000
type: io1
instance_type: m3.large
name: cell_z2
- cloud_properties:
availability_zone: us-east-1c
ephemeral_disk:
iops: 1200
size: 50000
type: io1
instance_type: m3.large
name: cell_z3
- cloud_properties:
availability_zone: us-east-1a
instance_type: m3.large
name: colocated_z1
- cloud_properties:
availability_zone: us-east-1b
instance_type: m3.large
name: colocated_z2
- cloud_properties:
availability_zone: us-east-1c
instance_type: m3.large
name: colocated_z3
- cloud_properties:
availability_zone: us-east-1a
instance_type: m3.large
name: database_z1
- cloud_properties:
availability_zone: us-east-1b
instance_type: m3.large
name: database_z2
- cloud_properties:
availability_zone: us-east-1c
instance_type: m3.large
name: database_z3
- cloud_properties:
availability_zone: us-east-1a
instance_type: m3.medium
name: route_emitter_z1
- cloud_properties:
availability_zone: us-east-1b
instance_type: m3.medium
name: route_emitter_z2
- cloud_properties:
availability_zone: us-east-1c
instance_type: m3.medium
name: route_emitter_z3
stemcell:
name: bosh-aws-xen-hvm-ubuntu-trusty-go_agent
version: latest
subnet_configs:
- name: diego1
subnets:
- cloud_properties:
security_groups:
- PLACEHOLDER-InternalSecurityGroup-ID
subnet: PLACEHOLDER-subnet-id-A
dns:
- 10.10.0.2
gateway: 10.10.5.1
range: 10.10.5.0/24
reserved:
- 10.10.5.2 - 10.10.5.9
static:
- 10.10.5.10 - 10.10.5.63
- name: diego2
subnets:
- cloud_properties:
security_groups:
- PLACEHOLDER-InternalSecurityGroup-ID
subnet: PLACEHOLDER-subnet-id-B
dns:
- 10.10.0.2
gateway: 10.10.6.1
range: 10.10.6.0/24
reserved:
- 10.10.6.2 - 10.10.6.9
static:
- 10.10.6.10 - 10.10.6.63
- name: diego3
subnets:
- cloud_properties:
security_groups:
- PLACEHOLDER-InternalSecurityGroup-ID
subnet: PLACEHOLDER-subnet-id-C
dns:
- 10.10.0.2
gateway: 10.10.7.1
range: 10.10.7.0/24
reserved:
- 10.10.7.2 - 10.10.7.9
static:
- 10.10.7.10 - 10.10.7.63


On Fri, Jan 22, 2016 at 4:28 AM, Kinjal Doshi <
kindoshi(a)gmail.com> wrote:

Hi,

After deploying CF version 226 on AWS using microbosh, I am
trying to understand how to deploy Diego now to work with this version of
CF but have not been able to figure out much yet. I was able to find steps
for deploying Diego on BOSH-Lite at
https://github.com/cloudfoundry-incubator/diego-release#deploying-diego-to-bosh-lite
but not for BOSH.

Would appreciate some pointers in this direction .

Thanks in advance,
Kinjal


Re: - CC configuration in deployment manifest

Amit Kumar Gupta
 

Hi Kinjal,

You are mixing the minimal deployment instructions with the "standard"
deployment instructions. When using the "standard" instructions (where you
create a stub), both cf1 and cf2 networks are generally expected to be
private, and separate from any subnets you create for BOSH itself. In the
minimal setup, I think you create a public and private subnet, I'm not sure
what would happen if using the public subnet as your second cf2 subnet?
You could try it, but this isn't a combination we test, so I can't make any
guarantees. If you do try it, I'd be interested to hear your results.

Best,
Amit

On Tue, Feb 2, 2016 at 12:00 PM, Kinjal Doshi <kindoshi(a)gmail.com> wrote:

Thanks a lot Dieu, that answers my question.

I have another question about creating a deployment manifest using the
following as guidelines: http://do
<http://docs.cloudfoundry.org/deploying/aws/cf-stub.html#editing>
cs.cloudfoundry.org/deploying/aws/cf-stub.html#editing
<http://docs.cloudfoundry.org/deploying/aws/cf-stub.html#editing>

The stud mentions that it requires 2 networks cf1 and cf2. I have created
a VPC with CIDR as 10.10.0.0/16 and am creating two public subnets cf1
and cf2 with CIDR as 10.10.160/20 and 10.10.80.0/20. Is that the correct
approach? Or are these required to be private subnets.

In case of the minimal-aws deployment one private and one public subnet
was required but here since they are used for different zones, I am not
sure if both should be private or public or 1 each. Would be great if you
could please help me understand.

Thanks,
Kinjal





On Wed, Feb 3, 2016 at 1:05 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi Kinjal,

We generally recommend naming it with a specific identifiable folder name
that is not the bucket root.

This might look like:
...
buildpack_directory_key: buildpacks
....
droplet_directory_key: droplets
...

or
...
buildpack_directory_key: dev-cc-buildpacks
...
droplet_directory_key: dev-cc-droplets
...

Hope that helps.
Similarly for app_package_directory_key and resource_directory_key

-Dieu
CF CAPI PM

On Tue, Feb 2, 2016 at 7:29 AM, Kinjal Doshi <kindoshi(a)gmail.com> wrote:

Hi,

I have a question regarding the configuration of cloud controller.

It is described at
http://docs.cloudfoundry.org/deploying/aws/cf-stub.html#editing that
DROPLET_DIRECTORY_KEY should be replaced with the directory/bucket used to
store the droplets and BUILDPACK_DIRECTORY_KEY should be replaced with the
directory/bucket used to store buildpacks

Please help me understand if there should be specific values for these
two parameters or it could be just any random directory name which is
created later?

Thanks,
Kinjal






Re: Issue with crashing Windows apps on Diego

Steven Benario
 

Hi Aaron,

You can track the progress of the story for DiegoWindows here on the public
tracker [1].

As it stands, we don't yet have a solution that we could do within the
DiegoWindows codebase that wouldn't break existing applications by allowing
them to return "healthy" before the app has even started up.

I absolutely agree that have an inconsistent pattern between Linux and
Windows is something to avoid (and something that is mis-labeled is even
worse), but I can totally see how this decision was made originally, and I
don't yet have any ideas for something that could fix it in the short term.

I think long term, we'd like to see a general healthcheck that looks like
some combination or user-selection of:
- Process monitoring
- Port check
- HTTP check (with configuration options previously discussed)

...with some "sane" settings selected by default.

For the short term, until we have a strong proposal of what to do to
significantly improve the state of the world without breaking existing
applications, we will probably not make any changes.


Thanks,
Steven Benario
PM for Windows Support


[1] https://www.pivotaltracker.com/story/show/112914163

On Mon, Feb 8, 2016 at 1:21 PM, aaron_huber <aaron.m.huber(a)intel.com> wrote:

Based on this discussion, where are we on the priority of switching the
current "port" check for the Windows lifecycle back to actually be a port
check? I get the impression that the changes to support a new HTTP check
in
the CC, CLI, BBS, etc. will probably take a while so until then I'm hoping
we can make the other change a bit quicker.

Aaron



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/Issue-with-crashing-Windows-apps-on-Diego-tp3586p3686.html
Sent from the CF Dev mailing list archive at Nabble.com.