Pulumi Programming Model: Difference between revisions
(Created page with "=Internal= * Pulumi Concepts =Overview= I think there is a misunderstanding here. Apologies if the below info is redundant, but I thin...") |
|||
Line 3: | Line 3: | ||
=Overview= | =Overview= | ||
=Creating an Infrastructure Resource in Code= | |||
=Updating an Infrastructure Resource in Code= | |||
=Importing (Adopting) an Infrastructure Resource= | |||
=Deleting an Infrastructure Resource in Code= | |||
Revision as of 22:05, 14 April 2022
Internal
Overview
Creating an Infrastructure Resource in Code
Updating an Infrastructure Resource in Code
Importing (Adopting) an Infrastructure Resource
Deleting an Infrastructure Resource in Code
I think there is a misunderstanding here. Apologies if the below info is redundant, but I think we can clear this up. Pulumi uses a statefile to capture a “current” state of resources contained in the current stack, from a physical cloud provider perspective and a pulumi metadata perspective. The statefile is just that, a file or dumb storage that is the result of a pulumi up. When you execute a pulumi up against a Pulumi program, Pulumi is taking the existing statefile (if one exists) and comparing it to the desired state, which is declared by the code in your Pulumi program. So what is happening here is, you’ve imported the resource into your Pulumi state and you’ve not included the resource definition (in code) in your Pulumi program. So when you run a pulumi up Pulumi looks at the statefile, sees the datadog dashboard and compares it with your code, which does not contain the resource definition and correctly determines it needs to delete the resource The Pulumi programming model defines the core concepts in use when creating infrastructure as code programs. These concepts are made available in the Pulumi SDKs, that support Python, TypeScript and Go.