Hey guys. I really don't like to ask such simple q...
# general
m
Hey guys. I really don't like to ask such simple question, but am I missing something? Shouldn't those resources be created in a tree hierarchy?
d
For a tree hieracy, you'd use
parent
. It's possible the preview output isn't respecting dependsOn, what's the behaviour when you actually apply?
m
I created this simplified example just to check out if It's producing correct order. It doesn't work with
parent
as well
In real world I have following code that is executed without explicite order neither
d
When you apply the changes, are they created in the wrong order as well?
m
Yes, platform and operators are applied simultaneously
I mean, last week I've tried to instantiate k8s ovh cluster, and then deploy the platform resources, it didn't wait for cluster as well
I thought It's just something wrong with ovh packages but I think the problem might be somewhere else
d
Can you show the output of
pulumi up --parallel 1
, including preview and apply please. This seems like a bug with depending on component resources
m
Screenshot 2024-06-29 at 12.21.05.png
Screenshot 2024-06-29 at 12.33.44.png
I had both, dependsOn and parent set in this example. Isn't that wild?
d
I'm surprised this didn't cause the stack to break. Setting parent should have the parent wait for the child, and having the child depend on the parent should cause a hang as the parent shouldn't resolve. If you just use dependsOn, do they create in the same order? I believe
-d
will show individual operations in the order they happen
m
Screenshot 2024-06-29 at 12.51.04.png
with dependsOn only
root created in the end
Maybe related?
https://github.com/pulumi/pulumi-keycloak/issues/519#issuecomment-2167371752 "Hi @ChristianRaoulis. I'm sorry your hitting this issue. I believe that this is a bug in the Pulumi engine, so I have opened an issue there: pulumi/pulumi#16395." Sounds almost impossible
d
so I'm testing it here, and I think what you're seeing is empty component resources not being created in order. As soon as I add a resource into Root, it all works as expected
for mine, I used
local.command
Copy code
import * as pulumi from "@pulumi/pulumi";
import * as command from "@pulumi/command";

class Root extends pulumi.ComponentResource {
    constructor(name: string, opts?: pulumi.ResourceOptions) {
        super("test:index:Root", name, {}, opts);
        const c = new command.local.Command("echo", { create: "sleep 5" }, { parent: this });
        this.registerOutputs({});
    }
}
as for the platform resources not depending on the cluster, I assume you have something along the lines of: • component resource creates a cluster • a provider is defined based on the cluster in the component resource • platform resources are created in another component In this case, the provider would be implicitly dependent on the cluster resource if it's using attributes like the endpoint to connect to, so it does sound like it'd be a bug in the ovh provider
m
Damn you are right. I added const c = new command.local.Command("echo", { create: "sleep 60" }, { parent: this }); to my ComponentResource and It has changed order of scripts completely
also, in a components that I had issues with deps, I noticed I didn't pass {} as third argument to super in constructor
I assume that could be an issue as well, not necesarrly ovh providers
Thank you for your time and support 🙏
Yeah I can see it was a major bug {}
d
Ah, I missed that. Yes, opts were being passed in as props instead, so dependencies weren't being registered