The launch configuration test exposed that our integration tests don't
retry for very long, and wait a long time in between retries.
Create a RunTasksOptions type to hold the parameters, in particular
max task time, and the amount of time we wait when all tasks have
failed.
This PR implmenents a new custom error that is returned when a task
lifecycle set to fi.LifecycleExistsAndWarnIfChanges. This will allow
a task to to fail validation, but the task is marked as completed and
the error is cleared.
This lets us configure cross-project permissions while ourselves needing
minimal permissions, but also gives us a nice hook for future lockdown
of object-level permissions.
We move everything to the models. We feature-flag it, because we
probably want to change the names etc, and we aren't going to be able to
offer smooth upgrades until that is done.
This:
- reworks how retries are handled in fi/executor.go to a time-based scheme
- changes the single-task limit to 10m (from about 30s of no-progress)
- eliminates the inner IAM propagation retry for LaunchConfigurations,
because the task itself will just be redriven for a while. This also
eliminates any long-pole delay caused by this error (since task Run()
should be 'fast').
A managed file is templated kops-side, but then stored in the S3 bucket
(aka state store)
This will be used to pass the channel containing the core addons.
This is needed so that we can have encrypted storage and complex keys
(e.g. multiple CA certs). Multiple CA certs are needed for an in-place
upgrade from kube-up v1.
If there is an error performing a task, we will reattempt it as long as
forward progress is still being made (i.e. at least one other task
completed successfully)
This makes everything more reliable (though we should still fix these
problems), but it also lays the groundwork for parallel execution.
We call the Render methods on Tasks by reflection, and some of them
don't care about the Target, but do care about the Context (e.g. the PKI
tasks, which only care about the CAStore)
* GCE support only
* Key and secret generation
* "Direct mode" makes API calls
* "Dry run mode" previews the changes
* Terraform output (though key generation not working for master ip)
* cloud-init output (though debian image does not ship with cloud-init)
Justin Santa Barbara