This idea is essentially superseded by the Release Pipeline which will undoubtedly incorporate or interact with a k8s cluster in one way or another.
Also needed add an annotation to the default namespace to satisfy our custom RegistryEnforcer admin controller:
So I think I got most of what was required for setup into the submitted puppet patch. The only other manual steps include:
Thu, Mar 16
Also, it's probably worth pointing out at this point that 'manifest' is not really the right word for what we're talking about here; a manifest as it's defined in all of the existing specifications is actually a bundled filesystem image (agnostic to how it was built) and runtime metadata about how to set up the container and how to invoke some application binary. What we've been discussing is a slightly higher level abstraction that covers the metadata but also system level package dependencies. The manifest + image will be a product of our build step.
Some related reading material on container standards (both de facto and burgeoning) that illustrates their separation of concerns and overlap.
Feb 22 2017
Feb 16 2017
Feb 14 2017
Feb 13 2017
@Halfak: The Deployment Cabal discussed this a bit more in our meeting this morning and decided that disallowing/excluding empty groups may indeed be a better long-term fix since empty input could lead to further unexpected behavior if left unvalidated.
Feb 9 2017
Oh and one little nit about the commit message: Please use the "Refs T123" or "Fixes T123" auto-close syntax to reference tasks. See https://secure.phabricator.com/book/phabricator/article/diffusion_autoclose/
To clarify: I think your changes are beneficial and should stay as well. :) Can you please add a unit test to tests/scap/test_targets.py to verify the edge case? Thanks!
I think the correct fix here would be to ensure a non-zero group size in the first place. Any idea how that may have happened? I suspect a percentage failure_rate that was converted to an integer and floored to 0 perhaps...
Feb 8 2017
Feb 7 2017
An additional follow up to make the prompt conditional more clear
Implemented suggested re-prompting following bad prompt input
Feb 6 2017
Looks like I caused the regression rMSCA98247477db5d: Improve failure handling and rollback behavior and called it out in the commit message as a "behavior change". :)
Jan 25 2017
Jan 19 2017
Jan 10 2017
Your changes look good but provision fails on account of checkoutMediaWiki not existing any longer:
Jan 4 2017
Should we just make it the cwd during check execution?
Dec 23 2016
Updating Diff summary to be consistent with most recent commit message. I'm probably doing this wrong! So weird.
Replace use of utils.ask with utils.confirm
Edited Diff summary since it's not done automatically when you amend a commit message. :/
Dec 22 2016
Implemented @hashar's recommended solution which is to simply add __init__.py files.
Dec 21 2016
Moving commit for rename of test directory to a separate Diff.
Dec 20 2016
Yet another refactoring, simplification of rollback invocation using existing _execute_for_group method, and moved finalize stage to execute following primary stages for all groups which ensures rollback can actually function as expected.
Dec 15 2016
From our notes for the 12/8 meeting with Ops regarding the direction of CI:
Requesting re-review after some minor changes.
Fixed a small bug in the rollback message for when failure_limit is exceeded
Dec 14 2016
- Refactored targets.TargetsList to no longer split groups but return first-class instances of a new targets.DeployGroup class
- Stage execution methods now considers the failure_limit for the entire original group, not individual subgroups
- Some additional behavior changed slightly as a result of this refactoring (see the commit message)
Dec 13 2016
Dec 12 2016
- Rename test directory so nosetests will read it
Dec 7 2016
Install newer pip using setuptools
Dec 5 2016
Dec 2 2016
Stage execution now correctly skips failed targets and rollback executes over all reachable target hosts
In testing this locally, I noticed a new issue with the failure_limit functionality. If a target fails during one stage and the threshold for failure isn't reached, the next stage will execute on said target. This is wrong obviously, but how to proceed? There are two options I can think of.