[5d] Research: Figure out what's needed to stand-up Diego next to DEAs

mogul commented 8 years ago

In order to be able to write stories that will help us get Diego deployed next to the DEAs, we'll spend 5 days researching the current state of Diego and how best to deploy it in our environment.

Acceptance Criteria

[x] We've got enough information to create a backlog that results in Diego deployed in an entirely separate GovCloud account

ghost commented 8 years ago

[Addressed in https://github.com/18F/cg-atlas/issues/96]

The currently deployed CF release as of Thursday, June 16 was v234, which has a recommended Diego release v0.1463.0. Both CF v234 and Diego v0.1463.0 have bugs that I think we should address by upgrading to a later release of CF (and thus Diego). Notably:

CF: https://www.pivotaltracker.com/story/show/112562131 Diego: https://www.pivotaltracker.com/n/projects/1003146/stories/112308797

ghost commented 8 years ago

Already done. ~~In order to make use of new bosh features and bug fixes as required by newer versions of CF and Diego, as ops engineers we need to verify and possibly upgrade the currently deployed bosh version.~~

Acceptance Criteria

[x] Deployed bosh release is at least 225.4 as required for Diego v0.1473.0

Implementation Sketch

ghost commented 8 years ago

[Moved to https://github.com/18F/cg-atlas/issues/101]

To ensure we can adequate service customers, as ops engineers we need to appropriately size our Diego deployment.

Acceptance Criteria

[ ] Establish manifest parameters with regards to size and number of Diego cells and other components
[ ] Determine and document thresholds where sizing should be adjusted

Implementation Sketch

Maybe look at how big our DEA footprint is?

ghost commented 8 years ago

[Moved to https://github.com/18F/cg-atlas/issues/102]

In order to make Diego available to platform users, as ops engineers we need to deploy Diego integrated with the existing CF deployment.

Acceptance Criteria

[ ] A concourse pipeline task that pulls in the dynamically generated CF manifest and feeds it to the Diego manifest generation script
[ ] A concourse pipeline that deploys an appropriate version of Diego for the deployed version of CF
[ ] A concourse pipeline task that runs the smoke tests to exercise diego
[ ] A concourse pipeline task that runs the acceptance tests to exercise diego

Implementation Sketch

ghost commented 8 years ago

Research notes:

As of June 15, cg is on v234 (https://github.com/cloudfoundry/cf-release/releases/tag/v234), which was released on April 6

Recommended Diego version for that release is https://github.com/cloudfoundry-incubator/diego-release/tree/v0.1463.0
Recommended Garden Linux release is https://github.com/cloudfoundry-incubator/garden-linux-release/tree/v0.335.0
Recommended etcd release is https://github.com/cloudfoundry-incubator/etcd-release/releases/tag/v43

Notable since Diego 1463:

stderr through ssh: https://www.pivotaltracker.com/n/projects/1003146/stories/112308797 fixed in 1465
Volume drivers (experimental)
Move to SQL from etcd (as of 1474 still experimental) : experimental support added starting with 1466
1468-1471 have known vulnerabilities.
cflinuxfs2 is now its own release and must be uploaded to the director first
The Garden team has recently renamed 'guardian' to 'garden-runc'
1473 requires a relatively new bosh
Diego 1469 (https://github.com/cloudfoundry-incubator/diego-release/releases/tag/v0.1469.0) requires at least CF v236 or later

ghost commented 8 years ago

Since we upgraded to CF v237 in 18F/cg-atlas#96, we should look to deploying Diego v0.1472.0 or later.

cloud-gov / product