Closed tylerauerbeck closed 4 years ago
@tylerauerbeck can you give some examples of this? its not something I have encountered much in the field.
@etsauer
So I think I might walk this back a little. We may be digging in a bit too far on building in the waiting for other objects to become available. This should probably be handled by things like pre-steps and post-steps.
I still think that second use case might be useful though. I'm thinking something like the following:
We have an application (I'll use Kubevirt as an example):
If the CRD's fail (for one reason or another), we obviously want to skip the operator and the CRs because they won't be all that useful without the CRD's. But maybe there are other things in our inventory that deploy just fine regardless of this other app that's having issues (i.e. there's nothing wrong with the entire inventory, just those few items).
So maybe something that looks like:
version: 3.0
context: global-context
namespace: global-default
resource_groups:
- name: Group 1
namespace: group1-stuff
resources:
- name: A CRD
namespace: this-deployment
type: openshift
template: my-crd-template
params: some-crd-params
- name: my-operator
namespace: this-deployment
type: openshift
template: my-operator-template
params: my-operator-params
dependencies:
- A CRD
Wanted to start the conversation here to see if this is something we would want to include in dash.
In my experience there can sometimes be objects that need to wait until something else is available. There are a number of ways to get around this now (manually, we can use
include_tags
andexclude_tags
and in pipelines we can do the same, then write custom logic to wait for certain things to become available). But are dependencies something that we want to handle inside of dash itself?Areas I can see this being useful are for things like:
Wanted to gather some feedback before thinking about how to include this further.