Yes that should work too, but it's still nice to be able to install the
gems during staging.

Jack


On Tue, Feb 2, 2016 at 2:33 PM, Evan Farrar <evanfarrar(a)gmail.com> wrote:

Could using a custom gem mirror be achieved by caching the dependencies
before push? Operating in a "airgapped" or "Disconnected environment" and
operating in a "whitelist firewall environment" often require similar
approaches, so following the advice for disconnected environments might
help:


https://github.com/cloudfoundry/buildpack-packager/blob/master/doc/disconnected_environments.md

On Tue, Feb 2, 2016 at 11:22 AM, Jack Cai <greensight(a)gmail.com> wrote:

Can someone merge this PR: [1]? It provides useful features to allow
operators to set a global gem repo mirror (via environment variable group)
where the default repo is slow to reach. Thanks!!

Jack


[1] https://github.com/cloudfoundry/ruby-buildpack/pull/47

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

Could using a custom gem mirror be achieved by caching the dependencies
before push? Operating in a "airgapped" or "Disconnected environment" and
operating in a "whitelist firewall environment" often require similar
approaches, so following the advice for disconnected environments might
help:


https://github.com/cloudfoundry/buildpack-packager/blob/master/doc/disconnected_environments.md

On Tue, Feb 2, 2016 at 11:22 AM, Jack Cai <greensight(a)gmail.com> wrote:

Can someone merge this PR: [1]? It provides useful features to allow
operators to set a global gem repo mirror (via environment variable group)
where the default repo is slow to reach. Thanks!!

Jack


[1] https://github.com/cloudfoundry/ruby-buildpack/pull/47

Can someone merge this PR: [1]? It provides useful features to allow
operators to set a global gem repo mirror (via environment variable group)
where the default repo is slow to reach. Thanks!!

Jack


[1] https://github.com/cloudfoundry/ruby-buildpack/pull/47

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

Your mileage may vary, but if you look at the full processes's environment
there are differences. In our case, we'll see things like the ssh port in
the diego environment but not the DEA, as well as INSTANCE_INDEX. On the
flip side, the deprecated VCAP_APP_PORT is present when we deploy apps to
DEA but not Diego.

-Matt

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

Hi Jack,

There are not any explicit environment variables that we expose that an
app is running on DEAs or on Diego.
My best suggestion here would be to set an environment variable
explicitly and trigger your agent's behavior based on that.

-Dieu

On Mon, Feb 1, 2016 at 8:48 AM, Kris Hicks <khicks(a)pivotal.io> wrote:

You can use the CF CLI with the Diego-Enabler plugin to query whether an
application is running on Diego or not:
https://github.com/cloudfoundry-incubator/Diego-Enabler

e.g. `cf has-diego-enabled App_Name`

On Mon, Feb 1, 2016 at 7:25 AM, Jack Cai <greensight(a)gmail.com> wrote:

Hi,

Is there a way for the application to know whether it's running in DEA
or DIEGO? Looking at [1], there is no environment variable that can tell
this.

Jack

[1]
https://docs.cloudfoundry.org/devguide/deploy-apps/environment-variable.html

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