OK, I see, thanks.
On Mon, 1 May 2023, 22:12 Alex Heneveld, <a...@cloudsoft.io> wrote:
> Geoff -
>
> On stop/destroy it wouldn't run the pre-apply workflow - it would just use
> the value that was set when that workflow was run, on the last apply.
>
> Best
> Alex
>
>
> On Mon, 1 May 2023, 19:32 Geoff Macartney, <geom...@apache.org> wrote:
>
> > Hi Alex,
> >
> > How does (A) work exactly? What difference does it make if the
> > attributeWhenReady is in a pre-apply workflow or not? Why doesn't the
> same
> > problem occur as you've described?
> >
> > Geoff
> >
> >
> >
> > On Mon, 1 May 2023 at 09:21, Alex Heneveld <a...@cloudsoft.io> wrote:
> >
> > > Hi folks,
> > >
> > > I've got a question about the best way to do some "start-only" DI using
> > the
> > > downstream Brooklyn-Terraform project, and I wondered what people's
> > > thoughts are on the best way to do something.
> > >
> > > The situation is that we have a mid-tier TF and a data-tier TF, and as
> > you
> > > might expect we need to pass the data-tier URL to the mid-tier. We
> > > currently do this as a config `tf_var.db_url =
> > > $brooklyn:entity("data_tier").attributeWhenReady("db_url")`. It works
> > > great in almost all cases.
> > >
> > > Where it doesn't work well is if we stop the data-tier before the
> > > mid-tier. In this case when we stop mid-tier, it fails because the
> > > attribute sensor `db_url` isn't available and isn't expected to be
> > > available. Of course we don't need the `db_url` to tear down the
> > mid-tier,
> > > but there's no way currently to indicate that.
> > >
> > > So what's the best way to indicate that `db_url` is only needed during
> > > plan/apply?
> > >
> > > There are a few options I can think of:
> > >
> > > (A) Add a `pre_apply.workflow` (and probably a `pre_plan.workflow`,
> > > `pre_stop.workflow`, and maybe also `post_<step>.workflow`) config to
> the
> > > terraform entity, providing a way to supply an optional workflow to be
> > run
> > > prior to apply/plan. In this workflow we could say `wait db_url =
> > > $brooklyn:entity("data_tier").attributeWhenReady("db_url")` then
> > > `set-config db_url = db_url`. And the `tf_var.db_url` points at
> > > `$brooklyn:config("db_url")`. This means it is only updated on apply,
> > and
> > > a `stop` or other `plan` instruction will simply use the last set
> > > variable. (And in the `pre_plan.workflow` we could be more forgiving,
> > > update config `db_url` if there is a new `db_url` available but
> otherwise
> > > just leave it as it was.)
> > >
> > > (B) Add new special handling for vars of the form `apply.tf_vars.V`
> > > (optionally `plan.tf_vars.V`, `stop.tf_vars.V`) where these vars are
> only
> > > used if that is the step being done.
> > >
> > > (C) Add a `$brooklyn:if(condition, when_matched, when_unmatched)`
> > function
> > > to the DSL in Apache Brooklyn. Then in Brooklyn Terraform we could say
> > > something like `$brooklyn:if( { sensor: service.status, equals:
> starting
> > },
> > > $brooklyn:entity("data_tier").attributeWhenReady("db_url"),
> > > $brooklyn:sensor("last_vars.db_url"))`.
> > >
> > > (D) Add a `depends_on` keyword which creates a relationship between two
> > > entities. If such a relationship is present, the dependent entity
> won't
> > be
> > > allowed to start until the dependency is ready, and the dependency
> isn't
> > > allowed to stop until the dependent is stopped. This would solve the
> > > problem in a different way, because the `data_tier` wouldn't be allowed
> > to
> > > be stopped while the `mid_tier` is active. This is how it is addressed
> > > within Terraform.
> > >
> > > I think I lean towards (A), because although (B) and (C) are more
> > concise,
> > > they aren't as clear or as powerful as (A). (D) would be nice but
> feels
> > > like quite a bit more work, and some subtle things to consider around
> > > start/stop checking these dependencies. And if enforced out-of-the-box
> > on
> > > start/stop likely to be slightly crude and obscure. (D) seems like a
> > nice
> > > thing to consider, maybe adding workflow steps to facilitate is, so
> e.g.
> > as
> > > part of (A) a developer could say, e.g. in the `pre_start.workflow`
> "wait
> > > for all dependencies to be ready" and in the `pre_stop.workflow` "wait
> > for
> > > all dependents to be stopped", but not something to bake in.
> > >
> > > Please if you have thoughts on the above, or you can think of other
> good
> > > ways to do it, let me know!
> > >
> > > Best
> > > Alex
> > >
> > >
> > > [1] https://github.com/cloudsoft/brooklyn-terraform
> > >
> >
>
