Error on Provisioning Workflow

[#1]

Ok Ok…

So I have a provisioning workflow, and have added a task that keeps bombing out. The task is very simple (bash):

1. Gather Data
2. Use them in curl calls

I’ve tried this in both provision and post-provision, but both fail with the error message of:
Task Execution Failed on Attempt 1
No such property: user

If I run the same workflow as an operational this works just fine.
it seems the lines in question are:

displayname="<%= user.displayName %>"
email="<%= user.email %>"

However. I’ve commented out those two lines, and used static strings. It still fails with the same error. This leads me to believe either:

1. The bash is cached somewhere, and running the old script (it is “Local”)
2. The error has nothing to do with my bash

Any ideas would be awesome.

[cbunge]

SeditiousSov:

accesskey="<%= cypher.read('secret/accesskey') %>"
secretkey="<%= cypher.read('secret/secretkey') %>"	 

My only other idea is one of your secrets is breaking the quoting of the rest of your script. If your access or secret key have a " in it, it may be getting interpreted funky by the wrapping double quotes. If so, you could invert the wrapper like accesskey='<%= cypher.read("secret/accesskey") %>'

If you just do the echo user as it’s own task and run it, does that also break?

[cbunge]

Correct it works for me. May need a support case to understand why it’s not available to you. There’s also instance vars for display name and email those may get you past issues.

[#4]

Thanks for that.

[#5]

So this variable was expanded in later versions of 5.4 … 5.4.11 is a very old version and will probably be resolved when you move to 6.0.2+ here in Q2

[cbunge]

So just a note on that script for the future. If you comment out a line with a Morpheus variable, we still do a find replace, so the fact that the <%=user.email%> is in there it’s still going to get interpreted by Morpheus. That said:

1. If you just have a task echo "<%=user%>" and only run that, what do you get?
2. What version of Morpheus are you on?

[#7]

I can confirm that an owner is set. It is set before it fails the provisioning workflow.

[cbunge]

Can you share the full script? Is this locally defined or pulling from git?

[#9]

Following up,

I created a new task, made sure the variables were hard coded names (for displayname and email) and still received the same error.

Also a point to note, I only seem to get that error when I set the task to run local as the execute target. If I set it to the “worker system” (remote to a host that handles tasks), I don’t get any output (even my bash echo’s). It just fails with Task Execution Failed on Attempt.

[dgaharwar]

SeditiousSov:

displayname="<%= user.displayName %>"
email="<%= user.email %>"

Can you confirm if the instance has an owner assigned?

You should see that on the instance summary page

or can edit the instance and check

[#11]

It’s locally defined:

#!/bin/bash
 
accesskey="<%= cypher.read('secret/accesskey') %>"
secretkey="<%= cypher.read('secret/secretkey') %>"	 
#displayname="<%= user.displayName %>"
#email="<%= user.email %>"
displayname="that one guy"
email="somewhere@something.com"
instance_id="<%= instance.id %>"
instance_name="<%= instance.name %>"
hostname="<%= instance.hostname %>"
now=$(date '+%m/%d/%Y')
appname="<%= customOptions.applicationName %>"
appgroup="<%= customOptions.applicationGroup %>"
appgroupcontact="<%= customOptions.applicationGroupContact %>"
environment="<%= customOptions.environment %>"
replication_tool="<%= customOptions.replicationTool %>"
ticket="<%= customOptions.serviceDeskTicket %>"
 
json=$(jq -n --arg instance_id "${instance_id}" --arg request_date "${now}" --arg application "${appname}" --arg application_group "${appgroup}" --arg application_group_contact "${appgroupcontact}" --arg environment "${environment}" --arg hostname "${hostname}" --arg replication_tool "${replication_tool}" --arg requester "${displayname}" --arg ticket "${ticket}" '$ARGS.named')
 
curl pu-cntutils-01.cac.com:8074/log -d 'requesttype=New_Build' -d "requester=${displayname}" -d "notes=${json}" -d "accesskey=${accesskey}" -d "secretkey=${secretkey}"
 
curl pu-cntutils-01.cac.com:8074/newbuild -d "instance_id=${instance_id}" -d "request_date=${now}" -d "application=${appname}" -d "application_group=${appgroup}" -d "application_group_contact=${appgroupcontact}" -d "environment=${environment}" -d "hostname=${hostname}" -d "replication_tool=${replication_tool}" -d "requester=${displayname}" -d "ticket=${ticket}" -d "accesskey=${accesskey}" -d "secretkey=${secretkey}"
 
exit 0

[#12]

That’s good to know that comments with morpheus variables are still parsed! Thanks for that.
The version is 5.4.11, we will be upgrading to whatever the latest LTS is at the start of Q2.

Running the task without any <%=user%> variables in the code at all, works like a champ (but not being able to get the user executing the workflow/provision is problematic).

Adding back in the user variable with echo "<%=user%>" gives me the failure.
Could it be an integration that breaks the available vars?

We have route 53, shared services, AWX (Ansible Tower) and Bitbucket enabled.

[#13 · Accepted solution]

I’ve got it working by bypassing the use of the user variable. Now, I have a task that kicks off a routine that polls (every minute) morpheus for the GET instances api, and pulls the necessary data from that. Not ideal, but it works for now.

Just so I’m not crazy, using <%= user %> in a provisioning workflow does work for you though right?

[#14]

So a simple task with nothing but:

#!/bin/bash
echo "<%= user %>"

Fails on provision and post provision. It very clearly does not like the user object.

It works perfectly fine in an operational workflow.

I guess I could write some go code that gets called from the provisioning workflow, in a thread (goroutine), so that it can return immediately (so the provisioning workflow completes), wait and then kicks off the workflow as an operational to get all the variables it needs.

Seems like a bit of an obtuse way to do it.