Date   

Re: How does an application know it's running in DIEGO?

Dieu Cao <dcao@...>
 

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


Re: How does an application know it's running in DIEGO?

Kris Hicks <khicks@...>
 

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


Re: cf ssh APP_NAME doesn't work in AWS environment

Stanley Shen <meteorping@...>
 

After adding below properties, it works now:

app_ssh:
host_key_fingerprint: a6:d1:08:0b:b0:cb:9b:5f:c4:ba:44:2a:97:26:19:8a
oauth_client_id: ssh-proxy
cc:
allow_app_ssh_access: true


Re: How does an application know it's running in DIEGO?

Jack Cai
 

Hi Ronak,

Thanks for answering it. The public API needs a CF user credential. It's
much easier for the app/buildpack to get such info from an env variable.

My scenario is that during our transition to DIEGO, we will have DEA and
DIEGO side by side for a while, and one of our runtime agent may need to
behave a little differently among these two environment, so that it can
leverage new features in DIEGO (like SSH).

Jack


On Mon, Feb 1, 2016 at 10:49 AM, ronak banka <ronakbanka.cse(a)gmail.com>
wrote:

Hi Jack,

Any specific use case where your application should be aware of the runner
itself??

If you just want to check for a particular application from command line ,
you can use
cf curl /v2/apps/$(cf app APPLICATION_NAME --guid) | grep diego

Ronak

On Tue, Feb 2, 2016 at 12: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


Re: How does an application know it's running in DIEGO?

Ronak Banka
 

Hi Jack,

Any specific use case where your application should be aware of the runner
itself??

If you just want to check for a particular application from command line ,
you can use
cf curl /v2/apps/$(cf app APPLICATION_NAME --guid) | grep diego

Ronak

On Tue, Feb 2, 2016 at 12: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


How does an application know it's running in DIEGO?

Jack Cai
 

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


Re: ERR Failed to stage application: insufficient resources

Stanley Shen <meteorping@...>
 

Thanks for answering.


Re: ERR Failed to stage application: insufficient resources

Matthew Sykes <matthew.sykes@...>
 

So the question is, when staging the application, it asks the same
resources we specified for the application?

It asks for the larger of the minimum staging resources or the requested
application instance resources. [1]

[1]:
https://github.com/cloudfoundry/cloud_controller_ng/blob/master/lib/cloud_controller/diego/protocol.rb#L23

On Mon, Feb 1, 2016 at 4:03 AM, Stanley Shen <meteorping(a)gmail.com> wrote:

Thanks for your information.

After more check, my issue turns out related to the cell VM.
The cell VM is c3.large, which has 2 vCPU and 3.75G memory, and my
applications asks for 4G memory.
After I changed the cell VM size to c3.xlarge (4 vCPU, 7.5G memory), I
didn't meet this issue again.

So the question is, when staging the application, it asks the same
resources we specified for the application?

---
applications:
- name: myAPP
disk_quota: 2048M
memory: 4096M


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


Re: Error 500 when testing new v229 CF deployment

James Leavers
 

Hi,

I couldn't see any issues with the certificate, however it turns out that the original deployment was actually using SSL termination via an external pair of loadbalancers - so I configured the new deployment to match which resolved this initial problem.

Thanks
James


Re: ERR Failed to stage application: insufficient resources

Stanley Shen <meteorping@...>
 

Thanks for your information.

After more check, my issue turns out related to the cell VM.
The cell VM is c3.large, which has 2 vCPU and 3.75G memory, and my applications asks for 4G memory.
After I changed the cell VM size to c3.xlarge (4 vCPU, 7.5G memory), I didn't meet this issue again.

So the question is, when staging the application, it asks the same resources we specified for the application?

---
applications:
- name: myAPP
disk_quota: 2048M
memory: 4096M


cf ssh APP_NAME doesn't work in AWS environment

Stanley Shen <meteorping@...>
 

Hello, all

I have one cf/diego instance deployed on AWS environment based on the https://github.com/cloudfoundry/cf-release/tree/master/example_manifests

I added the consul job and also diego jobs to that manifest.
And it works well as far as I can see.

After pushing one APP to it, I tried to SSH to the container via "cf ssh APPNAME", it returns error message like "dial tcp 52.11.111.111:2222: getsockopt: connection refused"

Here 52.11.111.111 is the public IP of HAProxy VM, and I also opened 2222 port for HAProxy VM.
If I try "telnet 52.11.111.111 2222", I get "telnet: Unable to connect to remote host: Connection refused"

Can anyone help on it?

Thanks in advance.


Re: [abacus] Handling Notifications

Chaskin Saroff <chaskin.saroff@...>
 

I apologize in advance for the length of this email. This is a complicated topic, so I want to ensure that everyone is on the same page. TL;DR I define different types of pub/sub and list questions at the bottom.

I'm going to highlight my general understanding of the common types and subtypes of publish/subscribe models for clarification.

Publishers publish objects or messages(collections of key, value pairs). Subscribers only receive a subset of publications. Filtering is done by two general methods.

From Wikipedia:

Topic-based Filtering- "Messages are published to "topics" or "channels." Subscribers in a topic-based system will receive all messages published to the topics to which they subscribe, and all subscribers to a topic will receive the same messages.

Content-based Filtering - "Messages are only delivered to a subscriber if the attributes or content of those messages match constraints defined by the subscriber."[1]

The article goes on to say that there are hybrid based approaches where content based subscription filtering is done within a topic.

Topic Based Filtering
---

Topic based delivery seems relatively easy. You save an entry in a database for each subscription with the entry containing a subscriber's address, secret and channel.

When a publication occurs, SELECT (Address, Secret) FROM Subscriptions WHERE Channel=<publication channel>

Content based filtering seems to be much more challenging. Unfortunately, topic based filtering does not seem to be expansive enough for the use cases that Subhash listed above.

Content Based Filtering
---

Let a message, m = {(k_1, v_1), (k_2, v_2), ..., (k_n, v_n)}

Let a predicate, p = <messagekey> <operator> <value>

Ex)

For a message, m,

m = {
"event_type": "usage_increase",
"organization": "af41dcc7-54cc-4489-89a6-b20c2abadc79"
"aggregate_rated_usage": 1234.5,
"region": "us-south",
"country": "USA"
"currency": "USD"
}

p = "aggregate_rated_usage" > 1000

In the widely used and simple case of content filtering, we would only allow subscriptions to be *conjunctions* of predicates. Let's refer to this as "simple conjunctive filtering" or "canonical filtering".

For a subscription, s, and predicates p_1, ..., p_n

s = p_1 ^ p_2 ^ ... ^ p_n

Ex)

s = "aggregate_rated_usage" > 1000 AND "organization" = af41dcc7-54cc-4489-89a6-b20c2abadc79 AND "currency" = "USD"

In such cases where only conjunctions of predicates are allowed, efficient algorithms are known. [2]

As you might already have considered, there are cases where a subscriber may want a subscription that is more than a flat list of predicates that are joined by conjunctions.

Let us refer to any collection of predicates joined with conjunctions, disjunctions and parentheses as "non-canonical filtering" or "generalized junctive filtering"[3]

Ex)
s = "aggregate_rated_usage" > 1000 AND ("country" = "USA" OR "currency" = "USD")

The final, and most generalized form of content-based filtering could be called "generalized logical filtering". This would allow for the use of the remainder of the logical operators such as the unary NOT operator, and the XOR operator.

Ex)
s = "aggregate_rated_usage" > 1000 XOR NOT("country" = "USA" OR "currency" = "USD")


This leads me to several questions.

1. If topic based filtering is not expressive enough for our use case, which of the types of content based filtering are required to express what we need while maintaining a scalable pub/sub system?

Also, we ended up discussing a little bit on the high level on how to do the matching
algorithm, so I'll relay it here.
2. @Ben Would you be able to provide a reference to the algorithm that you are describing? Which form of content based filtering are you referring to?

3. What are the general scalability goals of this system(How many subscriptions would be allowed? How complex would the subscriptions be allowed to be? etc.)

4. Are you tied to a document based database, or can you use a traditional, relational DBMS for this if it proves to be more efficient?

Cheers,
Chaskin

[1] https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern#Message_filtering
[2] https://www.cs.cornell.edu/Courses/cs614/2003SP/papers/ASS99.pdf
[3] http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=0F159B2E9BE3145BC0F8C51F79C4DEB0?doi=10.1.1.483.1899&rep=rep1&type=pdf


Re: Issue with crashing Windows apps on Diego

Steven Benario
 

Hi Aaron,

Thanks for the report!

I'd recommend either extending the healthcheck timeout, or disabling health
checks completely to see if that fixes the problem. You can do this with:
`cf set-health-check APPNAME none`

If that doesn't fix the problem, is the app something you can share with
the CF Windows development team?

Thanks,
Steven Benario
Cloud Foundry PM for Greenhouse

On Fri, Jan 29, 2016 at 4:45 PM, aaron_huber <aaron.m.huber(a)intel.com>
wrote:

We've started testing Windows apps on Diego in our lab and everything
appears
to be working correctly except for occasional crashes of the .NET apps.
The
frequency is very random - some times I can go a day or more without any
and
then I'll get many in a day. As far as I can tell from the logs the only
issue is that the healthcheck in the lifecycle is timing out due to
exceeding the 1 second wait here:


https://github.com/cloudfoundry/windows_app_lifecycle/blob/master/Healthcheck/Program.cs#L29

Our test environment is definitely running on very slow storage so it
doesn't surprise me that it gets a bit slow sometimes, but I'm worried that
taking more than 1 second for a simple HTTP request to respond seems
unlikely. I've looked through the logs and can't find any indication of
root cause other than the healthcheck returning exit code 1 instead of
zero:


{"timestamp":"1454113322.534542084","source":"garden-windows","message":"garden-windows.garden-server.run.spawned","log_level":1,"data":{"handle":"c41ecf17-6e8c-4b50-a103-4e32323ef53e-bdfa601f-0a44-48fd-8d05-e5551ac9af7a-3a193046-43ed-4811-7bc4-3595809a409c","id":"5920","session":"1.104644","spec":{"Path":"/tmp/lifecycle/healthcheck","Dir":"","User":"vcap","Limits":{"nofile":1024},"TTY":null}}}


{"timestamp":"1454113324.545698404","source":"garden-windows","message":"garden-windows.garden-server.run.exited","log_level":1,"data":{"handle":"c41ecf17-6e8c-4b50-a103-4e32323ef53e-bdfa601f-0a44-48fd-8d05-e5551ac9af7a-3a193046-43ed-4811-7bc4-3595809a409c","id":"5920","session":"1.104644","status":1}}


{"timestamp":"1454113324.987732887","source":"garden-windows","message":"garden-windows.garden-server.destroy.destroyed","log_level":1,"data":{"handle":"c41ecf17-6e8c-4b50-a103-4e32323ef53e-bdfa601f-0a44-48fd-8d05-e5551ac9af7a-3a193046-43ed-4811-7bc4-3595809a409c","session":"1.104647"}}

There are no other event log messages at the same time to indicate anything
is wrong on the system. Theoretically I could just try increasing the wait
time on the healthcheck but I'd love to get some more data on exactly
what's
going on. Anyone have any ideas?

Aaron Huber
Intel Corporation





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


Re: AUFS bug in Linux kernel

Simon Johansson <simon@...>
 

Great, thanks for lettings us know!

This is hitting us pretty badly ATM, so Im happy we now know why. :)


Re: AUFS bug in Linux kernel

Simon Johansson <simon@...>
 

Great! This has hit us pretty badly, good know what is causing it.


Issue with crashing Windows apps on Diego

Aaron Huber
 

We've started testing Windows apps on Diego in our lab and everything appears
to be working correctly except for occasional crashes of the .NET apps. The
frequency is very random - some times I can go a day or more without any and
then I'll get many in a day. As far as I can tell from the logs the only
issue is that the healthcheck in the lifecycle is timing out due to
exceeding the 1 second wait here:

https://github.com/cloudfoundry/windows_app_lifecycle/blob/master/Healthcheck/Program.cs#L29

Our test environment is definitely running on very slow storage so it
doesn't surprise me that it gets a bit slow sometimes, but I'm worried that
taking more than 1 second for a simple HTTP request to respond seems
unlikely. I've looked through the logs and can't find any indication of
root cause other than the healthcheck returning exit code 1 instead of zero:

{"timestamp":"1454113322.534542084","source":"garden-windows","message":"garden-windows.garden-server.run.spawned","log_level":1,"data":{"handle":"c41ecf17-6e8c-4b50-a103-4e32323ef53e-bdfa601f-0a44-48fd-8d05-e5551ac9af7a-3a193046-43ed-4811-7bc4-3595809a409c","id":"5920","session":"1.104644","spec":{"Path":"/tmp/lifecycle/healthcheck","Dir":"","User":"vcap","Limits":{"nofile":1024},"TTY":null}}}

{"timestamp":"1454113324.545698404","source":"garden-windows","message":"garden-windows.garden-server.run.exited","log_level":1,"data":{"handle":"c41ecf17-6e8c-4b50-a103-4e32323ef53e-bdfa601f-0a44-48fd-8d05-e5551ac9af7a-3a193046-43ed-4811-7bc4-3595809a409c","id":"5920","session":"1.104644","status":1}}

{"timestamp":"1454113324.987732887","source":"garden-windows","message":"garden-windows.garden-server.destroy.destroyed","log_level":1,"data":{"handle":"c41ecf17-6e8c-4b50-a103-4e32323ef53e-bdfa601f-0a44-48fd-8d05-e5551ac9af7a-3a193046-43ed-4811-7bc4-3595809a409c","session":"1.104647"}}

There are no other event log messages at the same time to indicate anything
is wrong on the system. Theoretically I could just try increasing the wait
time on the healthcheck but I'd love to get some more data on exactly what's
going on. Anyone have any ideas?

Aaron Huber
Intel Corporation





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


Re: Need help for diego deployment

Amit Kumar Gupta
 

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: Need help for diego deployment

Kinjal Doshi
 

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: Need help for diego deployment

Amit Kumar Gupta
 

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: Need help for diego deployment

Kinjal Doshi
 

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

5781 - 5800 of 9387