Problem using FILES_DS context attribute in 4.14.2-2

Hi all

Since we have updated our testing cluster to OpenNebula 4.14.2 we have notice a issue trying to instantiate a template which contains FILES_DS values into CONTEXT, here is our template:

CONTEXT=[
FILES_DS=“run_user_script.sh”,
NETWORK=“YES”,
SCRIPT=“build_all_repos.sh”,
TARGET=“hda”,
TOKEN=“YES” ]

And now we get this error from ONE using oneadmin user:

$ onetemplate instantiate 1 --name test
[TemplateInstantiate] Error allocating a new virtual machine. Error parsing: run_user_script.sh. syntax error, unexpected RSTRING, expecting VARIABLE at line 1, columns 1:19

It was working before, it seems that OpenNebula is trying to parse the bash script and it fails… Do you known if this is a known issue or if we should change FILES_DS by another value?

Cheers and thanks!
Álvaro

Hi @alvaro_simongarcia,

I have similar issue bu it was due to a bug in 4.14.0. IMO FILE_DS should contain index to the file in the files datastore and INIT_SCRIPTS must have the name of the scripts that should be called. Here is an example where i have uploaded set-root-password.sh in the FILES datastore and it has ID 18,

FILE_DS=$FILE[IMAGE_ID=18]
INIT_SCRIPTS="set-root-password.sh"

You can arrange the thing in the template wizard and then switch to advanced to see exact context variables.

Kind Regards,
Anton Todorov

Hi @atodorov_storpool

yes that’s it! in our case I think that the template was changed during 4.14.2 upgrade, I have changed the template to the original value:

CONTEXT=[
FILES_DS=“$FILE[IMAGE_ID=155] $FILE[IMAGE_ID=164]”,
INIT_SCRIPTS=“run_user_script.sh”,
NETWORK=“YES”,
SCRIPT=“build_all_repos.sh”,
TOKEN=“YES” ]

And now is working correctly :smile:

Thanks a lot!
Álvaro

Hi Álvaro,

The onedb tool doesn’t change the FILES_DS attribute, and the parser hasn’t been touched lately…
What OpenNebula version were you using before? Are you sure that exact same template was working?

Hi Carlos

We did a minor update from 4.14.0 to 4.14.2 but at this moment I’m not sure how or when it was modified, (probably it was modified by a human being :smile:). In any case I will try to reproduce the issue, but nothing to be worried about, sorry for the noise…

Cheers
Alvaro

Hi Álvaro,

I was able to reproduce it on 4.14.0. It was due to bug #4049.

Here is my (duplicate)report #4153.

As 4.14.2 is out and working smoothly I would like to suggest to not waste your time on this issue as it seems patched now.

Cheers,
Anton

Hi Anton

Thanks a lot for the info! This is a test machine and its updated frequently so I was not sure when it was modified. I didn’t found any issue running 4.14.2 either :blush:

Cheers
Álvaro