This message was deleted.

Can you explain more about your use-case?

Hey @witty-candle-66007 in my case I have a deployment (keikoproj/instance manager) that creates and maintains our eks node fleet. But in order for instance manager to start, it needs some amount of compute available to be scheduled. In our current process I provision the eks control plane, manually create a managed node group, once the pods are running I cordon the bootstrap nodes and reschedule the pods. This causes cluster auto scaler to create the required nodes on the instance groups. Then I can remove the managed node group

Hi @cuddly-dusk-95227 It’s not clear to me why you delete the node group - but that could be just a bit of eks-noobism on my part. If it’s not really required to delete the node group, you can manage the node group and eks cluster and containers, etc as part of a Pulumi stack. See the eks package: https://www.pulumi.com/docs/reference/pkg/eks/ or the eks provider: https://www.pulumi.com/docs/reference/pkg/aws/eks/ for the related resources. (The eks package is an abstraction on top of eks to make provisioning eks clusters easier.)

The reason is that all the compute is provisioned and maintained by https://github.com/keikoproj/instance-manager If we keep the managed node group we then need maintain this node group.

Ah ok. So, I suppose you could have a dynamic provider whose “create” method does the procedural stuff you describe around creating the node group, cordoning the nodes and destroying the node group. And the rest of the dynamic provider’s methods could basically be no-ops or written to handle cases where changes to the eks cluster or other pulumi-managed resources require updates related to the node groups stuff. Another option, may be the automation api such that it stands up one or more stacks of pulumi-managed resources and in between you make procedural calls to do the node group stuff.