mojo uses stage specific files inconsistently
Bug #1660608 reported by
Jacek Nykis
This bug affects 2 people
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Mojo: Continuous Delivery for Juju |
Triaged
|
Wishlist
|
Unassigned | ||
Bug Description
I have a spec with files like this:
collect-golive
services-golive
partners/
partners/
And this is my manifest:
collect config=
deploy config=
What happens is:
* mojo uses partners/
* mojo uses both services-golive and partners/
This is inconsistent, unexpected and non obvious behavior. Could mojo treat config for all phases in the same way?
I think it's best to use the most specific file (so partners/
mojo 0.4.1
Ubuntu 14.04.5 LTS
Revision history for this message
| Paul Gear (paulgear) wrote | #1 |
| Changed in mojo: | |
| importance: | Undecided → Wishlist |
| status: | New → Triaged |
To post a comment you must log in.
This is a distinction that has caught me out several times, and I think it needs fixing. There are pros & cons for using only a stage-specific file vs. updating collect to behave like deploy.
Removing inheritance from deploy (and possibly other phases?) requires:
- Add facility to include other files within deploy configs
- Remove all but the stage-specific configuration from call to juju-deployer
- Update IS-owned specs to account for this
- Announce this to mojo-announce as a backwards-
The risk with this is that it holds the possibility that specs could deploy 100% correctly in CI, including passing all their Nagios checks, and yet still be incomplete because they were depending on the common deploy config to deploy a significant portion of their application units.
Updating collect to behave like deploy requires:
- Add a facility to exclude a collect which has been previously included; this could probably be as simple as prefixing the line with a dash
- Update collect phase to collect from all applicable files; this could be as simple as multiple calls to codetree
- Review IS-owned specs to see if any changes are needed
- Announce this to mojo-announce
The risk is that some charms will be collected when they aren't needed; if they're not referenced in the deploy config, this seems harmless enough.
Another option would be to deprecate stage-specific collect/deploy files entirely, and use conditionals within the master versions. In general, I've found this to result in more comprehensible specs with less duplication.
Next step: make a decision about which direction to go.