https://pulumi.com
Join Slack
Hey guys. I really don't like to ask such simple question, but am I missing something? Shouldn't tho...
# 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
8 Views
Open in Slack
PreviousNext
Powered by

Pulumi Community

No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Powered by