cityindex/logsearch-development-flow — pull request #136 by sopel (2013-08-15 13:44:44+00:00)
Title: Compose TemplateURLs from parameters

This composes the formerly hard coded nested stack `TemplateURL` prorperties from parameters. The current pattern resembles the one in place so far, e.g.:

```json
"https://s3.amazonaws.com/ci-elasticsearch-development-flow/aws-cloudformation/master/secgrp-single-default.template"
```
becomes

```json
"https://s3.amazonaws.com",
{ "Ref": "S3BucketName" },
{ "Ref": "S3BucketPrefix" },
{ "Ref": "RepositoryBranch" },
"secgrp-single-default.template"
```

### Rationale

The slight template noise introduced like so aside, this makes sense to me given the following assumptions:

* `S3BucketName` - a user would like to use an arbitrary bucket
* `S3BucketPrefix` - a bucket might be used for various projects/contexts, distinguished by prefix
* `RepositoryBranch` - a user mirrors the branches of an existing GitHub repository to S3 (we should automate that, either via Jenkins or maybe even a self contained GitHub commit hook based PaaS solution)
* `RepositoryBranch` is also used for bootstrapping already, so tying these seems reasonable

#### Questions

* :question: Should the template name also be a parameter?
* Given the branch approach outlined above probably not, but it would make sense if users would upload templates to a S3 bucket manually rather than mirroring there GitHub repo, which is also a reasonable approach.
* :question: Should the S3 base URL also be a parameter?
* I'd pretty much prefer that, but we can skip it for simplification here right now
* Background is the (odd) CloudFormation API requirement of having the `TemplateURL` on S3 in the very region you create a stack from (this requirement has fortunately been dropped from the nested stack `TemplateURL`)
* This issue is further complicated by the utterly annoying legacy [Amazon Simple Storage Service (S3) endpoints](http://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region) inconsistency, where they have named the us-east-1 constrained endpoint `s3-external-1.amazonaws.com` rather than just `s3-ùs-east-1.amazonaws.com`, with the latter allowing easy composition, whereas the former requires a map lookup for a cross region solution