Call a Python Script from vRO

[TheVMinator]

What is the proper and cleanest way to call a Python script from vRO?

[Burke-]

You have a couple choices here:

1) if running vCO on a SINGLE server (vs running in a cluster), then you can run scripts locally using the method described in this blog article: How to run a Perl Script from a vCenter Orchestrator Workflow

2) (Preferred) Setup a scripting host VM to run scripts. Then use the Guest Operations package to run your scripts for you from that host. See here: Guest script manager package

[TheVMinator]

OK thanks.  Would another option be to create a VCO plugin in python?

[rszymczak]

You would have to write a Java plug-in that will invoke python scripts unsing some remote connection (since your goal will not be to run python scripts on the vCO host) and return the data back to vCO in javascript. Sounds not very pleasing to me.

Way more straightforward would be using a scripting VM. As an alternative to the mentioned guest-management scripts I'd like to suggest useing the SSH plugin to connect to your host and call your python scripts. Returned value will be your shell output -  a String.

[TheVMinator]

Ideally, wouldn't I want to run my code, if possible, without having to make calls either to another application within my vCO appliance, or to another VM?  For example:  If I use a scripting host I have to:

1.  Make sure my workflow can authenticate to that host, and make sure authentication is maintained as credentials change, passwords expire, service accounts get accidentally deleted, etc.

2.  Make sure my network connection between those hosts is good as now I introduce a dependency I didn't have before on networking between vCO and the scripting host, without which my script will fail.

I guess there isn't any way to use Python without either making a call to an outside VM, or creating a python installation on my vCO machine? 

[Burke-]

Isn't Python already on the vCO appliance??

[rszymczak]

What you're asking for sound like a sandboxed python interpreter for vCO. That however is not the scope of vCO as I understand it. And I would strictly discourage you from running scripts directly on your vCO appliance. It's like using ESXi to test your linux scripts. Don't confuse vCO with a scripting host. It's a orchestration engine!

If I combine that request with your second request posted here (running java programs) than what you're looking for seems to me like a workflow-controlled operating system. Basicly you could install whatever [interpreter/programm] you can install on your normal OS (e.g. Linux) and controll all operations using workflows. The thing I can name that does stuff like this is good old pipe | on linux with bash as you workflow engine (yeah - powershell can do it aswell). But that's not what a orchestration engine is for, imo.

The issues you raised about script VMs are true, but it's the way things are done nowadays. Also:

1. I'm not sure but I think the SSH plugin does support certificate based SSH authentication - so no password expiration here and you could use one SSH key for multiple hosts

2. If you're worried about your network, why do you use vCO in first place? It's a product totaly dependent on a stable network.

[TheVMinator]

I don't know if Python is already on vCO - I'm trying to understand how vCO can use Python.  It seems to me that I don't want to call a python script on an external VM if I don't need to.  So if I rule that out, then what is the best way to use Python without doing that?  with javascript I can just cut and paste my code into a workflow.  I don't need a "javascript host".  With powershell I can paste powershell code into a workflow but I have to have a powershell host configure to run it on.

So I guess I'm trying to understand what my options are with python if I don't use an external scripting host on a different Vm, and what the best option is.

Beginner here so thanks for your patience...

[rszymczak]

just edited my last post, maybe it's more precise now

[Burke-]

Good points in that comment and yes, SSH DOES support key based authentication.

As for running things locally on your vCO Appliance, perl, python, and java are all on it and my article gives a simplified demo of how to run a local command on the appliance. The article focuses on a simple perl example, but this applies to ANY command locally available on your vCO server.

How to run a Perl Script from a vCenter Orchestrator Workflow

... I see I am repeating myself now... good luck, hope you have what you need now.

[TheVMinator]

Thanks all. 

This is very informative.  I think I'm caught in the middle between two consderations regarding using python locally in vCO, or externally on a scripting host.  Burke's article is clear and inviting for trying this on VCO itself, and rszymczak has some good points too.

Using it locally: I think rszymczak has a good point about determining whether vCO should be used as a scripting host, if it wasn't designed to be used that way.  This also raises some other questions.  For example, if I upgrade my VCO appliance with an update, what happens to my setup between VCO and the local python instance and scripts?  Are there other problems / gotchas to getting vCO to interact with a local python instance if vCO wasn't designed to run like an operating system with python installed, but was truly designed as a one-application show to run orchestrator on top of a specialized virtual appliance designed just for that one purpose? I'm afraid of the unknown...

Using it remotely:  To answer rszymczak's question number 2 - why would I be concerned about calling a remote scripting host if the goal of the script is to interact with a remote system?  The goal is to interact with a remote system - yes.  We have to accept some of the risks involved in doing that - that we are introducing a dependency on physical and virtual networks, that we are introducting latency, that we are introducting a dependency on that other system being up instead of just vCO being up, having sufficient performance, instead of needing only vCO to have sufficient performance.  All these new factors and variables are being introduced.  We have to introduce them and accept them, not because it makes the script more robust, but because they are unavoidable constraints.   however, if I can accomplish my integration by having only one external system to interface with, why use 2?  Why introduce a third set of dependencies if not needed?  The goal is to interact with external systems allow for, mitigate and reduce the risks of those integrations, and not introduce more risks than are required to do the job.  If using a scripting host is a necessary risk to get the scripting task done cleanly, then that is what we need to do.  But I want to make sure of that, because adding more risks, dependencies is good when there is a requirement or a good use case to do so, but not if there isn't.  So that is why I want to make sure that running the python locally is not a better option before I create a scripting host.  Also a scripting host has to be maintained, patched, monitored, upgraded, takes up disk space, etc.  If the script fails, there is one more system I may need to look at, analyze logs in, check services on, and do more troubleshooting on.  Maybe having to do that is still a requirement for the best overall design, but I want to weigh all the factors.  As I said, I'm just a beginner, learner, so thanks for your input / patience / suggestions.

[rszymczak · Accepted solution]

however, if I can accomplish my integration by having only one external system to interface with, why use 2?

It's really a tradeoff you do: what happens if your network breaks vs what happens if your vco breaks. which of both is more likely and which will be worse in consequence.

By useing a external scripting host you split your execution environment from your control environment. While this introduces some dependencies - such a network availability - it is done for good reasons. You don't want a malicious script to render your control environment broken. You want to seperate and isolate the script execution environment so that any error that might happen while executing jobs dosn't affect any other system or system component. That's why we're doing virtualization in the end. Otherwise we would run just everything on a bunch of linux hosts.

Thinking about it you can really look at orchestrator as some kind of hypervisor for your job runs: it has some basic script interpreter (javascript) that will let you control what you want to do but is pretty sandboxed when it comes to operations on the ->real<- hardware where vCO runs on, so it isolates execution from control. just like esxi has some operating system but hides everything that would make it possible for vms to have any inpact on other vms.

Also you want the executon host to be a replaceable and cheap component that you don't really care about. The extra effort (e.g. any cluster method) you invest to protect your central components - e.g. your orchestrator host - is probably oversized for your job-executors. Script execution host dies? Who cares, roll the automated workflow for deploying a new one and be happy again. In big environments (~2000 hosts) it's totaly normal that you got 10+ host failures - a day! It's nothing you can control, it's just the sum of the components MBF. So what you should care about is not how resilient your infrastructure is - because it is not - but how resilient your services are.

Thus, when it comes down to "breaking your vCO due to scripts run on your vCO host" versus "loosing a compleatly replaceable scripting host" I'd always choose the scripting host to execute my jobs.

[TheVMinator]

OK great - thanks again.  That gives some good design principle perspective so the question of a scripting host. I guess the last time I used a powershell host as an execution host, there were a lot of moving parts, a lot of troubleshooting stuff to get it up and running. WinRM, Powershell versions and settings in them had to be tweaked quite a bit, we hit bugs and did research to fix and tweak WinRM, change powershell version to one that worked, etc.  The idea of maintaining an execution host might be great just brings back bad memories. I guess that brings me back to if I want to use python at all, or try to move to a language that runs natively like javascript or java plug-in in vCO, without requiring either an external scripting execution host or doing modifications to the vCO appliance underlying OS by cracking open the hood.  Lest I prolong this discussion unduly, I'll address that in a different post.  Thanks for all the input!