Merge lp:~pedronis/adt-continuous-deployer/ols-tweak into lp:adt-continuous-deployer
Proposed by
Samuele Pedroni
Status: | Merged |
---|---|
Approved by: | Celso Providelo |
Approved revision: | 65 |
Merged at revision: | 66 |
Proposed branch: | lp:~pedronis/adt-continuous-deployer/ols-tweak |
Merge into: | lp:adt-continuous-deployer |
Diff against target: |
11 lines (+2/-0) 1 file modified
mojo.py (+2/-0) |
To merge this branch: | bzr merge lp:~pedronis/adt-continuous-deployer/ols-tweak |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Celso Providelo (community) | Approve | ||
Review via email: mp+262424@code.launchpad.net |
Commit message
check in tweak lying about on wendigo for ols deployments
Description of the change
code tweak as found on wendigo
To post a comment you must log in.
Samuele,
I have mixed feelings about generating configuration on-the-fly.
I think we have to evolve in the way we deal with *configurations* and split then in 3 groups: 'service', 'system' and 'secrets' characteristics.
The 'service' parameters influence how the service works (timeouts, database names, log filename, etc) and per immutable-services could as well be code 'constants' (changes in service aspects are recorded in the code history, not as a separate branch).
The 'system' characteristics (basically server IPs/DNS) come from a service-discovery infrastructure and don't necessarily need to be precisely tracked because changes to not impact the system (i.e. the system is prepared for changes).
Finally the 'secrets' ones, which might remain in wendigo disk and be distributed from there, because that's the only place they make sense.
That said, I don't mind you committing this now, but we could also start thinking about removing on-the-fly configs from our workflow.