QA (public) » openQA Project (public) » openQA Tests (public) » qe-yam

AutoYaST rules and classes prepares more than one file, might help:
tests/autoyast/prepare_rules_and_classes.pm

We want to include a short summary of the research path to take a decision on which approach to implement.

We take into account three approaches with different features and requirements:

• Approach 1 (A1): Based on files, each file contains specific use case and a common section imported from a library. In this approach we won't need additional variables due to the use case contains all the required data into JSONNET template. For example: We have sle_lvm.jsonnet with the specific definition of LVM test and a common sections imported from base.libsonnet.

local default = import '../lib/base.libsonnet';

{
  product: base['product'],
  user: base['user'],
  root: base['root'],
  scripts: base['scripts'],
  storage: {
    drives: [
      {
        alias: 'pvs-disk',
        partitions: [
          { search: "*", delete: true }
        ]
      },
    ],
    volumeGroups: [
      {
        name: 'system',
        physicalVolumes: [
          { generate: ['pvs-disk'] },
        ],
        logicalVolumes: [
          { generate: 'default' },
        ],
      },
    ],
  }
}

The file sle_root_filesystem_ext4.jsonnet has the same target with different storage configuration.
In this approach we take advantage of code re-usability.

• Approach 2 (A2): Based on libraries, there is one base library as previous approach called base.libsonnet that contains common sections. In addition, we create additional libraries with specific use cases like LVM or root_filesystem_ext4. The libraries can be selected by using variables to produce a final JSON profile. For example:

local lib = import 'lib/base.libsonnet';

function(storage='default') {
  product: lib.getProduct(),
  user: lib['user'],
  root: lib['root'],
  scripts: lib['scripts'],
  [if storage == 'lvm' then 'storage']: lib.storage['lvm'],
  [if storage == 'ext4' then 'storage']: lib.storage['ext4'],
}

It provides more potential and scalability with the counterpart of complexity of the code and traceability.
We need to use variables.

• Approach 3 (A3): Based on a single file, with conditionals and variables to manage the output JSON. This approach give us easier learning curve but it could grow to unmaintainable levels. For example:

local getProduct(product_id='SLES') = {
  id: product_id
};

local getFSPartition(format='ext4') = {
  drives: [
    {
      partitions: [
        { search: "*", delete: true },
        { generate: 'default' },
        { filesystem: { path: '/', type: format } },
      ],
    },
  ],
};

local getMultipathScript() = {
  pre: [
    {
      name: 'activate multipath',
      body: |||
        #!/bin/bash
        if ! systemctl status multpathd ; then
          echo 'Activating multipath'
          systemctl start multipathd.socket
          systemctl start multipathd
        fi
      |||,
    },
  ]
};

local getDefaultScript() = {
  post: [
    {
      name: 'enable root login',
      chroot: true,
      body: |||
        #!/usr/bin/env bash
        echo 'PermitRootLogin yes' > /etc/ssh/sshd_config.d/root.conf
      |||,
    },
  ],
};

local getPassword(hashed=true) = if hashed then '$6$vYbbuJ9WMriFxGHY$gQ7shLw9ZBsRcPgo6/8KmfDvQ/lCqxW8/WnMoLCoWGdHO6Touush1nhegYfdBbXRpsQuy/FTZZeg7gQL50IbA/'
  else 'nots3cr3t';


{
  product: getProduct(std.extVar('product')),
  user: {
    fullName: 'Bernhard M. Wiedemann',
    password: getPassword(std.extVar('passwordHashed')),
    hashedPassword: true,
    userName: 'bernhard',
  },
  root: {
    password: getPassword(std.extVar('passwordHashed')),
    hashedPassword: true,
  },

  // Scripts selector, if multipath is defined then added multipath scripts.
  scripts: if std.extVar('scripts') == 'multipath' then getMultipathScript() else getDefaultScript(),

  // Storage section generator, available options [lvm, ext4, xfs]
  [if std.extVar('storage') == 'lvm' then 'storage']: {
    drives: [
      {
        alias: 'pvs-disk',
        partitions: [
          { search: "*", delete: true }
        ]
      },
    ],
    volumeGroups: [
      {
        name: 'system',
        physicalVolumes: [
          { generate: ['pvs-disk'] },
        ],
        logicalVolumes: [
          { generate: 'default' },
        ],
      },
    ],
  },
  [if std.extVar('storage') != 'lvm' then 'storage']: getFSPartition(std.extVar('storage'))
}

In addition, it requires variable management to not duplicate sections.

Finally, we decided to go on approach 2 plus functions as approach 3, giving us the potential of using variables and conditionals to select each key-value and the easy to use of functions which could avoid variable usage in default cases.

PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/21108

This could be the plan:

• Do not merge the PR due to we are doing a nasty hack installing/polluting the worker adding repos/installing packages without salting it.
• Wait for SR https://build.opensuse.org/request/show/1245614 to be merged.
• Send PR to add the package as described here: https://suse.slack.com/archives/C02CANHLANP/p1739421639505079?thread_ts=1733729839.444069&cid=C02CANHLANP
• Once deploy, merge the PR and verify correc use of the package.
• File new ticket for covering other architectures.

Added Confluence information: https://confluence.suse.com/display/qasle/How-To%3A+Generate+JSON+profiles+using+JSONNET+tool

PR with new jsonnet package: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/21234