Initial issues spotted in the training material

[gcasale]

• "api_title" is not accepted as a valid property from xOpera SaaS
• ListTodoItem
  -- the statement_id is now "list-statement" not "list-stmt"
  -- also name: "list-items" is now name: "list-todos"
• the runtime in the official example is now "nodejs12.x" no longer "nodejs10.x"
• The final TOSCA service template should be added to the github repo so that one can diff to find the problems
• It's not clear at start why one needs to clone RADON-workshop, ultimately the artifacts are pulled in the instructions from the FunctionHub
• Explain at "https://github.com/radon-h2020/RADON-workshop/blob/main/labs/gmt.md" how to open the GMT from within the IDE and start a new project. The former is absent, the latter is done but under the section Tasks in the markdown file and should be done at start instead (does one need to write “radon.nodes.aws” rather than "example.org.tosca.servicetemplates" also upon creating the New Service Template?).
• In the description of NodeProperties at "https://github.com/radon-h2020/RADON-workshop/blob/main/labs/gmt.md", the description uses textual labels in TOSCA, not the Winery properties. For example, "AwsAPIGateway" in GMT only has the fields "api_description", "api_version", "entries", "name" so where should one put "ServerlessToDoListAPI"?
• In https://github.com/radon-h2020/RADON-workshop/blob/main/labs/xopera.md, "You can login using your radon credentials" what if one doesn't have it? This needs to be explained.
• "Create credentials", xOpera no longer have credentials, it's probably called Secrets.
• "Invoke opera SaaS deploy from IDE" this should explain how to do it, eg screenshot?
• "Provide the Service template name ( you need to download the csar and unzip it. " -> the description before doesn't seem to explain how one creates a CSAR from Winery and where does it appear in the IDE.
• "It can be an empty inputs.yaml (containing :{})" this seems obsolete now as xOpera should be able to deploy without?

[AlexSpart]

Thanks for the issue report @gcasale
Bulleted issues 2-7 have been addressed by #6 .
Could you provide more info for the bullet 1?
For bullets 8-12 will need to ping @cankarm or @anzoman as the validated instructions of the workshop are for Opera-cli.
The instructions of Opera-SaaS might be WIP.

[gcasale]

Issue 1 is a property of the AWSAPIGateway listed in the gmt part

[AlexSpart]

Did you write the property with quotes?
Does this issue occur during deployment with Opera?

[gcasale]

I wrote it in the tosca file directly with similar syntax as the others of AWSAPIGateway. Anyway I fixed it removing it and it worked fine

[gcasale]

It occurs during opera saas deployment I think, I don't recall perfectly right now

[cankarm]

In https://github.com/radon-h2020/RADON-workshop/blob/main/labs/xopera.md, "You can login using your radon credentials" what if one doesn't have it? This needs to be explained.

One needs credentials for IDE also, (s)he can use the same one?

"Create credentials", xOpera no longer have credentials, it's probably called Secrets.

Indeed, actually this was renamed some ago to Secrets, as one could also store other secrets, not only credentials.

"Invoke opera SaaS deploy from IDE" this should explain how to do it, eg screenshot?

Some help is accessible here: https://xlab-si.github.io/xopera-docs/saas.html#eclipse-che-plugin-for-xopera-saas

"Provide the Service template name ( you need to download the csar and unzip it. " -> the description before doesn't seem to explain how one creates a CSAR from Winery and where does it appear in the IDE.

This should be expained from Winery.

"It can be an empty inputs.yaml (containing :{})" this seems obsolete now as xOpera should be able to deploy without?

Indeed, we also fixed just this week the issue of reloading the last used inputs. Now the inputs are stored for the future invocations.

[miwurster]

Add csar generation to the GMT PR: #4

[AlexSpart]

Hi @cankarm,
The xOpera-cli section was written by EFI for the completion of the workshop as we used the xOpera-cli version to deploy the application at that time of the project.
The Opera-SaaS version which was also written by EFI is just a sequence of high-level steps that a user would have to go through, to deploy the application but definitely not giving the detail that is expected in a tutorial providing screenshots etc.

It's up to XLAB to choose whether you keep both sections in xOpera section but I think that a refinement to both sections from your side will solve @gcasale points of ambiguity related to xOpera, and will provide a complete guide for deployment.