This message was deleted.

The code you write is reflective of your overall deployment, it doesn't create new resources unless they don't yet exist. Something you can do is use multiple stacks, or load in data from another source to define multiple VM resources in pulumi

Thanks for the reply this is already helping me tremendously! I started experimenting with the pulumi API here for a while but I'm not good with what to enter at "stack.workspace.install_plugin". In my case I am using vsphere should I fill in "stack.workspace.install_plugin("vsphere", "x.x.x.x")" there or?

@brash-nightfall-51586 the program you posted initially is a pure infrastructure program. You typically run this with the

pulumi

CLI. The Automation API that @dry-keyboard-94795 refers to allows you to wrap a full Pulumi project and run the CLI commands via an API. In the simplest setup, you can refer to a local program, meaning it is a local folder containing a workable infrastructure program. In such case there is no need to run

install_plugin

as this will be done automatically. A step up is if you combine your infrastructure as code program with the automation API code in a single program. From the automation API code you then use an "inline program". You then have to use "install_plugin" to install the plugin binaries. For VSphere, you indeed use

stack.workspace.install_plugin("vsphere", "4.9.1")

. The version should point to an existing version for the VSphere package (see Pulumi Registry) and should match the version of the Pulumi Python package for VSphere you have in your

requirements.txt

. Hope this clarifies a bit.

Hi @limited-rainbow-51650! Thanks for the reply after some searching and reading the docs I was able to create a fully working script! I am indeed a as you suggested Flemish. Am currently a final year student at Howest MCT with graduation profile infrastructure engineering. Am working on a research project "How to set up a one-click on-premise deployment pipeline for a full stack application using Infrastructure as Code and Configuration as code?". Where I am including pulumi, ansible etc. I will definitely keep CfgMgmtCamp in mind! Can always come in handy 🙂

I’m also new to Pulumi & also from a TF background. The conclusion I’m coming to is that Pulumi (in TF terms) is effectively using a coding language (Python) to create HCL that then gets applied: the output of Python is Pulumi configuration. Its not a Python script that also executes against the AWS APIs (like boto3) as it executes. You dont run the python code produced - pulumi does that & then uses the resulting config. You can call non-Pulumi python from Pulumi (as part of building the Pulumi elements/config, but not the other way round. I’ve yet to get into if having a standard python script that calls Pulumi outputs, but I assume thats possible. Hopefully someone will correct me if I’m wrong…

@green-alligator-4238 yep, you've got it. And yes, you can access outputs from other apps. I used the json formatted version of

pulumi output

to load it into other tooling

Thanks @dry-keyboard-94795 So, @brash-nightfall-51586, to answer your question, you’re running a TF apply every time you run pulumi up - you’ll get the same single deployment. Its not like boto3 when you’ll get (or try to get) a new deployment (say with a different VM name). Not that I’ve looked for it yet, but there may be a count/for_each equivalent. I’d be interested in any thoughts on building a Pulumi ‘engine’ to churn out VMs, which is possibly what you’re looking for. Interesting challenge…