Variable for resource pool (Looking for GCP project name)

[#1]

I am trying to find the variable for the resource pool information and cannot seem to find it. If anyone knows of a method to see this through a morpheus variable or api call, please let me know. I am specifically looking to create a task to allow for network tags to be added to google compute instances after they have been deployed. In order to do this, I need to be able to pull the variables for the project that the vms reside in (morpheus resourcepool). The item I am looking for is in this pic as an example:

[cbunge]

Are you running the task against the instance or individual server? This would need to run against the instance itself.

https://docs.morpheusdata.com/en/latest/troubleshooting/Variables_Examples.html?highlight=variables#instance

[cbunge]

It looks like from a native variable aspect, we are only capturing the Resource Pool ID <%=instance.resourcePoolId%>. Assuming you’d have to curl to Morpheus to get the pool name. If you have jq installed you could run this as a local shell script, for example:

serverUrl='<%=morpheus.applianceUrl%>'
accessToken='<%=morpheus.apiAccessToken%>'
cloud='<%=instance.input.zoneId%>'
pool='<%=instance.resourcePoolId%>'

poolName=$(curl "$serverUrl/api/zones/$cloud/resource-pools/$pool" -H "Authorization: BEARER $accessToken" | jq .resourcePool.name)

[cbunge]

Also any desired functionality can be added to the Ideas section to capture for future improvements!

[#5]

Whenever you get a chance for the placing in cypher and pulling from it to the task, but definitely not when you are on PTO! I was able to get it to function overall by creating the service account and creating the key and storing it locally. It was a bit of a task due to gcloud commands requiring the projectID and not name, so additional calls were required. Overall, it is working though. I just didn’t know if I could utilize whatever method that morpheus uses already to make it happen instead of going into a custom setup. Thanks!

[#6]

I went ahead and submitted in the idea section as well. I am getting null for <%=instance.resourcePoolId%> and don’t see it listed in the documentation either… running 5.4.5

[#7]

Hey Cbunge, I have finally gotten back around to this, and able to get the project name from the morpheus variables, which is fantastic, but now I am stuck as to how to get gcloud to run from the morphes server. It is installed, but I am getting stuck as to what user the tasks are getting ran as, if outside of sudo. If I can get the task to auth with gcloud, I think I am set. Any chance you or anyone else has performed gcloud commands within a task?

[cbunge]

Ah so you are using gcloud sdk? I’ve ran this by installing as the morpheus-local user (this is the local execution user and needs access to any modules you plan on using).

You can store the credential JSON in cypher and call it to auth. I can try and build an example next week when I’m back from PTO.

[KoreyG]

Hey @smittyt2,

When I’ve worked with the gcloud command, I needed to auth using a service account. Using the gcloud auth activate-service-account command, it appears it requires a key file. For myself, I did end up writing it to disk temporarily in the task but maybe @cbunge will have an even better example laying around.

Not the full code but you should get the gist:

$creds = '<%=cypher.read("secret/gcloud")%>'
$region = '<%=results.getinfo.regionName%>'
$projectId = '<%=results.getinfo.projectId%>'

$filename = (New-Guid).guid

Set-Content -Path "$env:HOME/$filename" -Value $creds
gcloud auth activate-service-account --key-file "$env:HOME/$filename" --quiet --user-output-enabled=false
gcloud compute addresses create $addressName --region=$region --project=$projectId --quiet --user-output-enabled=false
Remove-Item "$env:HOME/$filename"

In the case above, $creds contains a Cypher secret that contains the contents of a key file I downloaded from my service account, example:

{
  "type": "service_account",
  "project_id": "serviceaccounts-######",
  "private_key_id": "redacted",
  "private_key": "-----BEGIN PRIVATE KEY-----redacted-----END PRIVATE KEY-----\n",
  "client_email": "redacted@serviceaccounts-######.iam.gserviceaccount.com",
  "client_id": "redacted",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://oauth2.googleapis.com/token",
  "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
  "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/redacted%40serviceaccounts-######.iam.gserviceaccount.com"
}

I did find that at least in the same phase, the authentication session remained between tasks, so you can create the file on the first task and remove it on the last.

Hope that helps!

[KoreyG]

To add to what @cbunge mentioned, it matters in the case of the context. See the below output from a quick PowerShell script using server.resourceId and instance.resourceId. 8:15 was using the instance as the context, 8:16 was using the same task at the server context: