This message was deleted.

To clarify what I want to achieve. Two services: A, and B. Flow is then: 1. Provision A 2. Run some code, that depends on A, to calculate value Y 3. Provision B with value from Y

I think you should use

.apply(...)

in your scenario. To clarify, and somebody correct me if I'm wrong, but you asked:

Will it resolve when the property has a value or will it resolve when the resource is ready?

I don't believe any of those output properties will have a value until the resource is ready. At the very least, the `Output<T>`s provided by a given resource contain information such that when they are passed into the

Input<T>

of another resource that resource is made aware that it depends on the previous, and must wait for it to be provisioned.

What I would like to have though is

A.apply

or something, that is, on the resource and not on the properties... I'll try and see how it goes. With that said, reading this I get a little bit confused:

During some program executions, apply doesn’t run. For example, it won’t run during a preview, when resource output values may be unknown. Therefore, you should avoid side-effects within the callbacks. For this reason, you should not allocate new resources inside of your callbacks either, as it could lead to pulumi preview being wrong. - https://www.pulumi.com/docs/intro/concepts/inputs-outputs/#apply

Does this mean that if I have a change in the result from 2 (see flow above) it won't be recognized during preview?

It's a good question. I know that provisioning doesn't happen in preview so some values it is not able to know, such as those that are derived from other resources. But if the resource is already deployed, than it is able to use the state of a previous deployment when calculating your preview.

What I would like to have though is 

A.apply

 or something, that is, on the resource and not on the properties

I don't think this is necessary, because like I said, the

Output<T>

contains information detailing what Resource it came from so that pulumi is able to build your dependency tree implicitly.

So if A changes causing the output from 2 to change, will B also then be provisioned updated? I guess (and hope) it will.

This is all handled correctly within Pulumi. Usually you don't want to create B within A.apply; instead, use the fact that

.apply

returns an output:

const a = new A("a", {});
const b = new B("b", {
  y: a.y.apply(y => doExtraWork(y)
});