This message was deleted.
s
sparse-intern-71089
10/08/2019, 1:59 PMThis message was deleted.
w
white-balloon-205
10/08/2019, 3:58 PM
Yeah - I think in general there are roughly three steps:
1. Break up into multiple file and just import
2. Move things into functions with arguments for simple abstraction and re-use
3. Turn into components for cleaner inheritance of parent options (providers, aliases, transformations, etc) and for nicer visualization
c
clever-sunset-76585
10/08/2019, 4:29 PMFrom my experience, I find myself going with #3 usually. 🙂
r
rhythmic-finland-36256
10/09/2019, 7:39 AMAfter noticing that I’ll need several inputs (k8sProvider, namespace name, identifiers, urls …) and require some specific order I now went with a ComponentResource which worked pretty straightforward. My approach was passing the (kubernetes) provider in the
argsComponentResourceOptionsproviderparent:thisrhythmic-finland-36256
10/09/2019, 7:44 AMAt first, some simple functions that are imported and executed once looked like the way to go. But when it comes to shared config, passing several basic things (e.g. the provider, the namespace name) in every function and additionally leaking the information in which order things must be run to the caller soon got cumbersome. So for anybody running over this question: I’d go with a ComponentResource as soon as there is some first item I would otherwise have to provide in every function call.
2 Views
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