Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enhance non-modifiable attributes list #99

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 5 additions & 6 deletions docs/deployment-manifests-part-1.md
Original file line number Diff line number Diff line change
Expand Up @@ -137,13 +137,12 @@ Compare this manifest to the earlier version and see that we have modified the f

These were the only attributes in our manifest subset that were easily modifiable or renameable.

Conversely, the following attributes of the manifest were not easily modifiable:

* the `name` of each item in the `releases` section comes from the BOSH release we use; we cannot rename or alias them within the manifest
* the `version` and `url` are related to each other to describe which BOSH release to use; if we want to upgrade to a newer release we would change these
* within `jobs` sections of instance groups the `release` must match one of the names in the top-level `releases` section. At the top-level these are immutable, so they are correspondingly immutable within the `jobs` sections of instance groups.
* within `jobs` sections of instance groups, the `name` of a job template is derived from the BOSH release itself (more on this soon), and cannot be renamed or aliased within a deployment manifest.
Conversely, the following attributes of the manifest are not easily modifiable:

* The `name` of each item in the `releases` section comes from the BOSH release. We cannot rename or alias the name of a BOSH release within the deployment manifest.
* The `version` and `url` are related to each other to describe which BOSH release to use. If we want to upgrade to a newer release, we would change them accordingly.
* The `release` in the instance group's `jobs` section must match one of the names in the top-level `releases` section. At the top-level these are immutable, so they are correspondingly immutable within the `jobs` sections of instance groups.
* The `name` of a job template in the instance group's `jobs` section is derived from the BOSH release itself (more on this soon). We cannot rename or alias the job template of a BOSH release within the deployment manifest.

## Cloud Config, Part 1

Expand Down