Generate all Agama json profiles using jsonnet profiles

[okynos]

We have added one method to auto-generate JSON profiles that can be later imported into Agama.

• Related ticket: https://progress.opensuse.org/issues/175728
• Needles: N/A
• Verification run: https://openqa.suse.de/tests/overview?distri=sle&version=16.0&build=4.2&groupid=583

[github-actions]

Great PR! Please pay attention to the following items before merging:

Files matching lib/**.pm:

• Consider adding or extending unit tests in t/

This is an automatically generated QA checklist based on modified files.

[jknphy]

this block should go under if agama auto above, so if it is x86_64 we will go with this and if not, the previous mechanism for the other architectures. It is preparation, doesn't need to to be in the middle of the ui code, anyway it runs in the workers, you don't need openqa api.

[jknphy]

in case of failure we might not have the uploaded json file, so I think we should also diag for example the generated json file to display it in the screen, otherwise could be hard to dissect.

[jknphy]

Let's have all the initialization together, so you can move this block before jsonnet execution.

[jknphy]

this extra line is not needed, the whole thing could be logic block, kind of blocks (1) preparation (2) execution (3) post-stuff and no need for comment in each block because it is obvious that is the structure.

[jknphy]

AGAMA_PROFILE_OPTIONS so it goes with the same type of naming than we have for Puppeteer.

Another important point here that would make less error-prone these openQA variable, as we can guess with string 'true' of 'false' that they are string or code, we should avoid to pass --tla-str and --tla-code. Could you please implement a simple parse for that.

[jknphy]

call it workaround_* and document it before some other contributors starts to scream :) because it is not good practice and we are being promised that will be packaged for all architectures but it wouldn't be the case we would need to rise the point or salt this other repo.

[jknphy]

as I mentioned to you, the 'default' word is too tricky and it is already used by jsonnet schema, so it difficult its understanding, we could go just with storage='' if that is allow?

[jknphy]

no need for a function here, let's use the external variable directly, otherwise we cannot reuse for openSUSE, each product needs to pass it.

[okynos]

Actually, it works like that, if you run jsonnet --tla-str product="Tumbleweed" template.jsonnet the output will contains Tumbleweed in the product id.
Example:

> jsonnet --tla-str product="Tumbleweed" data/yam/agama/auto/template.jsonnet 
{
   "product": {
      "id": "Tumbleweed"
   },
   "root": {
      "hashedPassword": true,
      "password": "$6$vYbbuJ9WMriFxGHY$gQ7shLw9ZBsRcPgo6/8KmfDvQ/lCqxW8/WnMoLCoWGdHO6Touush1nhegYfdBbXRpsQuy/FTZZeg7gQL50IbA/"
   },
.
.
.

[okynos]

The function allow us to set a default variable, avoid errors on empty of parameters run.

[okynos]

Ok I removed the function, the product id definition will be in the template.

[jknphy]

we should not make wipefs (let's use full names, wipe_filesystem) dependent on enable_root_login, we should compose them, add them seprately. Because this logic for these kind of workarounds tends to disappear in future builds (we don't know but happens a lot) so no logic is required, all dummy building blocks as much as possible.

[jknphy]

why to add this here if it is not used?

[jknphy]

we should be able to reference the array item, so we can use more than one pre.

[jknphy]

this could be a way to reuse it to avoid repetition below, passing the value from the openQA variable with the list of options.

[jknphy]

we have right now a case for "import profile" that add only scripts, so in a way user and root are also optional.

[jknphy]

I guess we should import here all the libs and not have import libraries in libraries for simplicity.

[jknphy]

I don't understand when we use it, I would expect something like:

if (agama_auto && x86)
   create json profile
else
   existing code (expand profile)

otherwise existing change would run for interactive installation.
we need to point in AGAMA_AUTO to the template yam/agama/auto/template.jsonnet

[jknphy]

try to avoid loops at all cost and use higher-order functions, Perl provides grep, map, the code is much more concise, something like this:
return map { " --tla-" . (/true|false/ ? "code" : "str") . " $_" } split ' ', trim($options);
You could even avoid to create a function and just include it below.

[jknphy]

the lines which contains some logic should go below, the casedir is just an assignation and should go here instead.

[jknphy]

let's not invent words here, the only schema that we have is the one in the Agama repo against which the profile is validated, this should just be storage, we should make all the libraries looks like so, so above local storage_lib same for any other library.

[jknphy]

for the same reason to make it flexible for openSUSE, product=''

[jknphy]

perhaps this could be scripts_pre so we don't need to invent names in the future, but to follow from outer to inner the structure and use that always as parameter names.

[jknphy]

in case we do some more multipath actions, better "activate_multipath".

[jknphy]

I find really unlikely that we use a pre script also as post script, wouldn't make more sent to separate them in different files, so the user of this feature can see clearly the catalog for each.

[jknphy]

shouldn't be any default for this, looks to me like some external variable.