0

Where is the Orchestrator 6.0 client installation file?

Usually you can start the Orchestrator client just via Java WebStart using the link on the welcome page of your vRO server.

However, due to several security restrictions in current Java versions, and OSX versions, that might be quite an effort to configure your system that this actually works (permanently).

In older vCO versions there were direct links to the standalone client installation downloads on the welcome page, but these links disappeared in vRO 6.0 (that comes with vRA 6.2, and the upcoming vSphere release).

So, here’s where you find the installation files: They are zipped in the file


/usr/lib/vco/downloads/welcome-page-resources.zip

on the appliance (it’s about 165MB!). Use for example scp to copy them to your local system (SSH has to be enabled in the appliance configuration):


scp root@your-vro-server:/usr/lib/vco/downloads/welcome-page-resources.zip .

Then you can unzip the file, and voila, find the standalone installation files…

0

vRO and the OpenStack Admin API

In this post we will start to interact with the OpenStack admin API. If you already followed my first two post, many things here are similar. The first two post can be found here:

Part 1:

http://www.vcoportal.de/2015/02/vro-and-openstack-thoughts-on-the-orchestrator/

Part 2:

http://www.vcoportal.de/2015/02/vro-and-the-openstack-public-api/

So before we can start to interact with the Admin API we have to create a new REST Host entry in vRO.

The approach to create the Rest Host is the same then described in the Posts before. The difference here is the used Port which we take to access the Rest Host. If you have created different IPs for your OpenStack environment and access the Admin API over a different IP (which can be configured in the files for the service)  you have to adjust your URL. Like before we doesn’t use authentication for the Rest Host.

After we have created the REST Entry we have to take a look at the Authentication. For the Administration OpenStack uses an Admin Token which is created during installation. We can use this Admin Token for Authentication. You can find this token in the file /etc/keystone/keystone.conf

We can use that token to operate the Admin Interface. From Security prospective we must be aware, that everyone who can execute the Workflow with the Token has administration rights. So if you use the Workflow in production limit the access to the Workflow!

So let’s create a new Action element. I named it OpenStackCreateUser. In the Action we need some Inputs.

After we have created the Inputs we have to insert the code for our need:

// We need a Json fomated String for Authentication. We create the string with this Workflow

var content = '{"user": {"id": "' + TenantID + '","name": "' + Username + '","email": "' + Email + '","enabled": ' + UserEnabled + '}}';

//Authenticate the request with the Admin-Token

var SessionRequest = RestHost.createRequest("POST", "/v2.0/users", content);

SessionRequest.setHeader("X-Auth-Token", SessionID);

SessionRequest.contentType = "application/json";

var SessionResponse = SessionRequest.execute();

// Show the Output

System.log("Session Response: " + SessionResponse.contentAsString);

I insert some Comments in the Code for explanation. Take a look at the

var content = '{"user": {"id": "' + TenantID + '","name": "' + Username + '","email": "' + Email + '","enabled": ' + UserEnabled + '}}';

code. Be aware that if you have to use a type of Boolean you are not allowed to use double quotes for the value.

After we finished our Action element we can build up our Workflow. I created a new Workflow with the Name “OpenStackAddUser”

In this Workflow we add the Action Element OpenStackGetTenantID which we created before.

Here we use the Visual Binding Editor to create the In- and Outputs. After we are finished the Visual Bindings should like this:

Next we insert the Action element “OpenStackCreateUser” which we build up before.

Also here we use the Visual Binding Editor to create the needed In- and Outputs.

As you can see we doesn’t have an output from the action since the OpenStack API doesn’t provide one for that operation. We can see the success in the log files which we write to System.log.

After Validation of the Workflow we can start with a first run.

Some notes for the run:

-          We use the Rest Host Admin API Connection.

-          We Use the Session ID from the admin_token value in /etc/keystone/keystone.conf

-          We provide a Username and an Email Address.

-          The TenantID is catched from the Tenant Name dynamically

If everything went well you should see and output like mine.

 

 

So now let’s verify this on a console. As we can see the user is created

 

 

This is only a short example hot to work with vRO and OpenStack. As you could see a lot is possible and could be done in an easy way.

I have uploaded the Actions and Workflows with I showed in the Blogpost on Flowgrab (https://flowgrab.com/). From there you can install the vCO Plugin and download the content directly into your vCO.

 

 

I you have feedback, comments or when I showed / explained something wrong please comment.

Have fun and Orchestrator the World ;-)

0

vRO and the OpenStack Public API

This is the second post regarding the interaction of vRealize Orchestrator and OpenStack. The first Post can be found here:

http://www.vcoportal.de/2015/02/vro-and-openstack-thoughts-on-the-orchestrator/

As I already mentioned in the first post it is possible to interact from vRO with OpenStack. Before we start with an example I would point you to the OpenStack API structure.

OpenStack knows two different APIs.

-          The Public API

-          The Admin API

The APIs are accessible over different Ports. The Standard Port for the Public API is port 5000. The Admin API is accessible over Port 35357. The Ports can be changed in the configuration files. I used the standard ports in my environment. So when you try to build the workflows for our environment take a look at the used ports. I created my OpenStack Installation on a single host. This isn’t the best configuration and most installations will have different servers for the services. This is also something which a take care when you start to create the Demos.

Now let’s come back to the admin and the public API. The public API offers some functions but not all. For example you cannot create a user on the public API. Therefore you have to use the Admin API.

For the two APIs you have to use different authentication ways but we will come to that later.

OpenStack offers a lot of documentation regarding the functions which are available on the API. Here is a links which are useful for the development of the workflows.

http://docs.openstack.org/api/openstack-identity-service/2.0/content/preface.html

Every service in OpenStack has such a documentation. In my examples I will work with the Identify services were the link above pointed to.

First thing we have to do is to add the Rest Host to vRO. Due the circumstance, that you must use different ports to access the public and admin API you have to create to REST Hosts with different ports.

Just insert the needed information’s in the workflow for the host. If you server provide the possibility to use HTTPS just change the URL to use the secure Protocol to access the API. This is recommended!

I doesn’t need a proxy server so I can go  fast over this screen.

The last page is for Authentication. We provide the user information in our workflow so we doesn’t need the Host Authentication and set it to “none”.

After we have insert the REST Host we can start with the first workflow. Before we can “access” public API functions we have to authenticate to the Identity service.

The authentication is done with JSON formatted call to the API. The API response is also in JSON. To create the Authentication Token we have to make the Call to the OpenStack Server. The call is done as a PUT command to the /v2.0/tokens extension.

Here a quote from the API documentation mentioned above.

Client authentication is provided through a ReST interface by using the POST method with v2.0/tokens supplied as the path. Include a payload of credentials in the body.

The Identity API is a ReSTful web service. It is the entry point to all service APIs. To access the Identity API, you must know its URL.

Each ReST request against the Identity Service requires the X-Auth-Token header. Clients obtain this token, along with the URL to other service APIs, by first authenticating against Identity with valid credentials.

So, let’s use this information for a first workflow or better a first action which handles the authentication. My Action is named “OpenStackCreateAuthToken”. In vRO we start with a new action element. The Action itself need some parameter.

This parameter are required to specific the REST Host with parameter, Username, Password and so on. In the Scripting Section we insert this code:

// We need a Json formatted String for Authentication. We build together the JSON String with the information we request for the Workflow.

var content = '{"auth": {"passwordCredentials": {"username": "' + authUserName + '","password": "' + authPassword + '"}}}';

// After we have built the Json String we create the Session and insert the Answer in the Response

var SessionRequest = RestHost.createRequest("POST", "/v2.0/tokens", content);

SessionRequest.contentType = "application/json";

var SessionResponse = SessionRequest.execute();

// Show the Content

System.log("Session Response: " + SessionResponse.contentAsString);

//Split the response as Json

var JsonContent = JSON.parse(SessionResponse.contentAsString);

// Here we get the ID with is used for Authentication in the following sections.

var SessionIDKey = JsonContent.access.token.id

// Just for information

System.log(" Session Key: " + SessionIDKey);

// The Session ID Key were will work with

return SessionIDKey

I provided required information in the code itself for explanation.

After we have created our action, we create a New Workflow. I put it in a OpenStack Folder with the name “OpenStackGetTenants”.

On the Schema Tab I added the Action which I created before.

Now we need to Create Inputs for the Action. You can do this via Drag and Drop on the Visual Binding.

In the Attributes, I already insert some Values for the connection.

These values are required for the connection. Now let’s start with a first run.

When everything worked fine you become an Output similar to mine.