when manta gets the details of a CFS configuration, if fetches the ref details. If the ref is an annotated tag, then it will show the tag SHA which is different than the commit SHA it points to. This is default git behavior since annotated tags are an object themselves. However the manta get configuration output is confusing because the tag SHA is different than the commit id.
Operational side this should not have major implications since CFS session do a git checkout <SHA> to switch branches and if <SHA> is an annotated tag, then git will resolve it to the commit it points to automatically.
Probably.

Manta needs to provide more feedback to the user in regards decisions make when processing SAT file.
For example:

• show the CFS configuration created
• Specify which parts of the SAT file are going to be processed

Manta get configuration command is not reporting branches for all CFS layers.

the auth token is stored in a single file.
this means user needs to authenticate again every time the site is changed
make manta able to manage multiple auth token for each site independently.
this will help when migrating
each token should exists in a different file or single file with a struct inside?

example:

~/.cache/manta//http

A new feature was recently added to manta to template SAT file with values defined in a session var file.
An upgrade to this would be to give the option to overwrite the values files by passing the vars values through the cli

example:
manta apply cluster -f my_sat_file_template.yaml -V my_values.yaml --var "config.name="

The command above would overwrite the version value in my_values.yaml to v1.0.3. Then expand the my_sat_file_template.yaml

Having:

# cat my_values.yaml
---
hsm:
  group_name: "zinal_cta"
config:
  name: "test-config"
  version: "v1.0.2"
image:
  version: "v1.0.6"
bos_st:
  name: "deploy-cluster-action"
  version: "v1.0"

And var config.name=new-value

The values in my_values.yaml should update to:

hsm:
  group_name: zinal_cta
config:
  name: new-value
  version: v1.0.0
image:
  version: v1.0.5
bos_st:
  name: deploy-cluster-action
  version: v1.0

Currently, HSM hardware inventory management works around the idea of target and parent HSM groups. The algorithm is flexible enough so any HSM group can be used as a parent, however, code is currently harcoded to "nodes_free".
Improve functionality above by adding parent HSM group as a value in configuration file:

• When working with hardware inventory, check parent HSM group belongs to the HSM group list user has access to
• Add new command manta config set parent-hsm to se new parent HSM group?

Currently, we use git.cscs.ch to push the ansible script configuring the clusters, each one of these repos will sync against CSM gitea through a gitlab pipeline.
This process works pretty well, however, there is a delay and external users don't have access to gitea, therefore is impossible for them to realize when their changes have been synchronized.
This issues is to create a new subcomand manta validate repo <path to local repo> which will compare the git history in a local repo with the git history of gitea.
This will give the user the possibility to know when is a good moment to submit a CFS session

At the moment manta provide a summary at the node level when asking for the hardware inventory related to a cluster:
eg

+---------------+-----------+---------------------------------+------------------------------------+
| Node          | 32768 MiB | AMD EPYC 7742 64-Core Processor | SS11 200Gb 2P NIC Mezz REV02 (HSN) |
+==================================================================================================+
| x1003c1s7b0n0 |  ✅ (16)  |              ✅ (2)             |               ✅ (1)               |
|---------------+-----------+---------------------------------+------------------------------------|
| x1003c1s7b0n1 |  ✅ (16)  |              ✅ (2)             |               ✅ (1)               |
|---------------+-----------+---------------------------------+------------------------------------|
| x1003c1s7b1n0 |  ✅ (16)  |              ✅ (2)             |               ✅ (1)               |
|---------------+-----------+---------------------------------+------------------------------------|
| x1003c1s7b1n1 |  ✅ (16)  |              ✅ (2)             |               ✅ (1)               |
+---------------+-----------+---------------------------------+------------------------------------+

It would be better if we provide a summary with the counters of each hardware component type within the cluster.
Then provide a parameters to break down per node as the example above

manta relies on CSM to validate SAT file, this is confusing for users if they are not familiar with how CSM works, specially if using jinja2 SAT files since the user will mostly interact with the values file.

This ticket is to work on manta SAT file validation to improve the error messages when submitting an incorrect SAT file.

Currently manta only manage a single token for all sites, this is a problem because the auth token gets rewritten every time the user changes site. This means if a user is working on more than one site at the same time, manta will have to ask user for authentication.

This ticket is to make manta manage a token per site like:

Auth token for site1 --> ~/.cache/manta/auth_site1
Auth token for site2 --> ~/.cache/manta/auth_site2

Note: we need to adapt this to env variables
Note: make sure PSI understands this

Despite of manta doing a fairly good job in keeping CSM entities correlation, it is still hard to find information for lvl 2 and 3 support to find data related, this could be improved by tagging the CSM entities.
Make sure whenever a new CFS configuration, CFS session, BOS sessiontemplate is created, to tag those entities so they can be reachable.
Tags should be used to rename DATE in sat files following users' convention. If tag is missing, then put timestamp, this is easier since manta won't let you create 2 different CFS configurations with the same name

When trying to install manta thru homebrew on MacOS another software is installed:

❯ brew info manta
==> manta: 1.1.4
https://getmanta.app/
Not installed
From: https://github.com/Homebrew/homebrew-cask/blob/HEAD/Casks/m/manta.rb
==> Name
Manta
==> Description
Invoicing desktop app with customizable templates
==> Artifacts
Manta.app (App)
==> Analytics
install: 6 (30 days), 13 (90 days), 55 (365 days)

This is what homebrew has in the manta.rb file:

cask "manta" do
  version "1.1.4"
  sha256 "f980f8d0c233e923a2352fd10521c1a04d059bc15140504bb7d2cfe235838776"

  url "https://github.com/hql287/Manta/releases/download/v#{version}/Manta-#{version}-mac.zip",
      verified: "github.com/hql287/Manta/"
  name "Manta"
  desc "Invoicing desktop app with customizable templates"
  homepage "https://getmanta.app/"

  app "Manta.app"
end

Is Homebrew supported on MacOS?

Data deletion works around CFS configurations and HSM groups, for this we need to correlate CFS configurations with BOS sessiontemplate and CFS sessions. There is a bug in manta where BOS sessiontemplate where not filtered properly for the CFS configurations marked for deletion

error message:

thread 'main' panicked at /home/msopena/.cargo/registry/src/index.crates.io-6f17d22bba15001f/clap_builder-4.5.1/src/parser/error.rs:32:9:
Mismatch between definition and access of `ansible-verbosity`. Could not downcast to TypeId { t: 7428646492878894209665195255548636123 }, need to downcast to TypeId { t: 42966343538335219590177265727833432740 }

show_config function breaks on admin users because the list if restricted HSM groups the user has access to is empty

At the moment hardware component operations in manta only calculates the new HSM groups members but it does not update them.
This change will commit the new HSM group members into CSM

openssl fails to build the package due to bug in a dependency with cc crate. A bug report has been created sfackler/rust-openssl#2184 and hopefully the fix will come soon.

Mean while apple artifacts have been disabled form the CI pipeline

SAT file to deploy clusters is currently a static file and we would like to add support so we could use a jinja2 template features.
An example would be something like:

manta apply cluster -f <SAT file> --session-vars <session vars file>

With SAT file being:

# (C) Copyright 2022-2023 Hewlett Packard Enterprise Development LP
---
schema_version: 1.0.2
configurations:
- name: "{{default.note}}-compute-config-{{default.suffix}}"
  layers:
# The gpu_customize_driver_playbook.yml playbook will install GPU driver and
# SDK/toolkit software into the compute boot image if GPU content is available
# in the expected Nexus repo targets. If GPU content has not been uploaded to
# Nexus this play will be skipped automatically. If GPU content is available in
# Nexus but a non-gpu image is wanted this layer can be commented out.
#BEGIN_GPU_SUPPORT
  - name: uss-gpu-customize-driver-playbook-{{uss.working_branch}}
    playbook: gpu_customize_driver_playbook.yml
    product:
      name: uss
      version: "{{uss.version}}"
      branch: "{{uss.working_branch}}"
    special_parameters:
      ims_require_dkms: true
#END_GPU_SUPPORT
  - name: shs-{{default.network_type}}_install-{{slingshot_host_software.working_branch}}
    playbook: shs_{{default.network_type}}_install.yml
    product:
      name: slingshot-host-software
      version: "{{slingshot_host_software.version}}"
      branch: "{{slingshot_host_software.working_branch}}"
    special_parameters:
      ims_require_dkms: true
  - name: cscs-interfaces
    playbook: cscs-interfaces.yml
    git: 
      url: https://api-gw-service-nmn.local/vcs/cray/cscs-config-management.git
      branch: cscs-23.07.0
  - name: cos-compute-{{uss.working_branch}}
    playbook: cos-compute.yml
    product:
      name: uss
      version: "{{uss.version}}"
      branch: "{{uss.working_branch}}"
    special_parameters:
      ims_require_dkms: true
# The gpu_customize_net_playbook.yml playbook installs GPU network-dependent
# software and any additional GPU packages needed. The playbook will run by
# default if GPU content is available in Nexus, and will be skipped if not. If
# a non-gpu compute-only image is required this layer can be commented out.
#BEGIN_GPU_SUPPORT
  - name: uss-gpu-customize-net-playbook-{{uss.working_branch}}
    playbook: gpu_customize_net_playbook.yml
    product:
      name: uss
      version: "{{uss.version}}"
      branch: "{{uss.working_branch}}"
    special_parameters:
      ims_require_dkms: true
#END_GPU_SUPPORT
  - name: csm-packages-{{csm.version}}
    playbook: csm_packages.yml
    product:
      name: csm
      version: "{{csm.version}}"
  - name: csm-diags-compute-{{csm_diags.version}}
    playbook: csm-diags-compute.yml
    product:
      name: csm-diags
      version: "{{csm_diags.version}}"
  - name: sma-ldms-compute-{{sma.version}}
    playbook: sma-ldms-compute.yml
    product:
      name: sma
      version: "{{sma.version}}"
#  - name: cpe-pe_deploy-{{cpe.working_branch}}
#    playbook: pe_deploy.yml
#    product:
#      name: cpe
#      version: "{{cpe.version}}"
#      branch: "cscs-23.07.0"
##BEGIN_SLURM_SUPPORT
#  - name: slurm-site-{{slurm.working_branch}}
#    playbook: site.yml
#    product:
#      name: slurm
#      version: "{{slurm.version}}"
#      branch: "{{slurm.working_branch}}"
##END_SLURM_SUPPORT
  - name: cscs
    playbook: site.yml
    git:
      url: https://api-gw-service-nmn.local/vcs/cray/cscs-config-management.git
      branch: cscs-23.07.0
  - name: nomad
    playbook: site-client.yml
    git:
      url: https://api-gw-service-nmn.local/vcs/cray/nomad_orchestrator.git
      branch: main
  - name: cos-compute-last-{{uss.working_branch}}
    playbook: cos-compute-last.yml
    product:
      name: uss
      version: "{{uss.version}}"
      branch: "{{uss.working_branch}}"
    special_parameters:
      ims_require_dkms: true

images:
# Uncomment the lines below if ARM images are needed.
#BEGIN_AARCH64_SUPPORT
- name: "{{default.note}}-compute-{{default.suffix}}"
  ref_name: compute_image.aarch64
  base:
    ims: 
      name: "gracehopper-uss-1.0.0-58-csm-1.5.aarch64-1"
      type: image
  configuration: "{{default.note}}-compute-config-{{default.suffix}}"
  configuration_group_names:
  - Compute
  - prealps
  - santis
#END_AARCH64_SUPPORT

session_templates:
# Uncomment the lines below if ARM session templates are needed.
#BEGIN_AARCH64_SUPPORT
- name: "{{default.note}}-compute-template-{{default.suffix}}"
  image:
    image_ref: compute_image.aarch64
  configuration: "{{default.note}}-compute-config-{{default.suffix}}"
  bos_parameters:
    boot_sets:
      compute:
        arch: ARM
        kernel_parameters: ip=dhcp quiet ksocklnd.skip_mr_route_setup=1 cxi_core.disable_default_svc=0 spire_join_token=${SPIRE_JOIN_TOKEN}
        node_roles_groups:
        - Compute
        - prealps
        - santis
        rootfs_provider_passthrough: "dvs:api-gw-service-nmn.local:300:hsn0,nmn0:0"
- name: "{{default.note}}-compute-template-{{default.suffix}}-ramdisk"
  image:
    image_ref: compute_image.aarch64
  configuration: "{{default.note}}-compute-config-{{default.suffix}}"
  bos_parameters:
    boot_sets:
      compute:
        arch: ARM
        kernel_parameters: ip=dhcp quiet ksocklnd.skip_mr_route_setup=1 cxi_core.disable_default_svc=0 spire_join_token=${SPIRE_JOIN_TOKEN}
        node_roles_groups:
        - Compute
        - prealps
        - santis
        rootfs_provider_passthrough: "dvs:api-gw-service-nmn.local:300:hsn0,nmn0:1"
#END_AARCH64_SUPPORT

And session vars file being:

---

base_image: "gracehopper-base-cscs-uss-1.0.0-58-csm-1.5.aarch64-shs-2.1.1-64-cos-3.0-aarch64-compute-image-20"

default:
  network_type: cassini
  note: 'santis'
  suffix: 23.11.0-beta.5-9
  wlm: slurm
  working_branch: "cscs-23.07.0"

slingshot:
  version: 2.1.1-894

slingshot-host-software:
  version: 2.1.1-64-cos-3.0-aarch64
  working_branch: cscs-23.07.0

sma:
  version: 1.9.5

uan:
  version: 2.7.1
  working_branch: cscs-23.07.0

uss:
  version: 1.0.0-58-csm-1.5
  working_branch: cscs-23.07.0-no-nvhpc

At the moment CSM does not support the possibility of using git tags to assign commit ids to CFS configuration layers, this is an issue because it forces users to use commits if they want to have inmutable CFS configuration layers or mutable by using the most recent commit if CFS configuration is updated.
A proposal is to add a new git tag support for CFS configuration layers.
Upon CFS configuration creation, if tag is defined for a CFS configuration layer, then, manta/mesa will check if that layer exists in gitea, fetch its commit id and assign it to the CFS configuration layer.
If both branch and tag are defined, then, the application should crash.

Tasks:
Add tag to CFS configuration layer to mesa struct
get gitea commit id related to git tag and assign commit i to cfs configuraion layer.
repeat previous step for all CFS configuration layers
If any layer fails, then, cancel transaction, otherwise create CFs configuration

Export hardware components pattern from an hsm group when doing a backup and get hsm group definition out of a hw component pattern and create the hsm group when restoring a cluster

the command apply cluster always reboots the nodes, this is inefficient if the boot image related to the BOS sessiontemplate does not changes.

This issues is to improve the default apply cluster behavior so nodes won't get rebooted if sessiontemplate boot image is the same as the current boot image assigned to the nodes.

traditional CLIs have the option to show information as json, yaml or by default (tabular data)
potentially we could make use of the is_terminal feature to detect if user is running manta interactively or not, the former will imply to show output data in json format.

manta apply cluster asks user to confirm final SAT file values. manta apply image and manta apply configuration should do the same

We would like to create a superset of the HPE SAT file adding new features like git tags to CFS configuration layers and hardware inventory to HSM groups.
This approach will help in having a self contained cluster definition in a single file.
Some use cases:

• Build new clusters from scratch
• Migrate clusters across different sites
• simplify cluster management

eg:

hardware:
- pattern: a100:4:epyc:4
configurations:
- name: config-test-__DATE__
  layers:
  - name: test-layer
    playbook: site.yml
    git:
      url: https://api-gw-service-nmn.local/vcs/cray/test_layer.git
      branch: cscs-23.06.0

images:
- name: image-test-__DATE__
  ref_name: test_image
  base:
    ims:
      type: image
      id: 3de9f01b-1981-4248-a7b9-c9803a6bc471
  configuration: config-test-__DATE__
  configuration_group_names:
  - Compute
  - adula

session_templates:
- name: sessiontemplate-test-__DATE__
  image:
    image_ref: test_image
  configuration: config-test-__DATE__
  bos_parameters:
    boot_sets:
      compute:
        kernel_parameters: ip=dhcp quiet spire_join_token=${SPIRE_JOIN_TOKEN}
        node_groups:
        - adula

A the top, we can see a description of the hardware we want the cluster to have:

hardware:
- pattern: a100:4:epyc:4

While processing this SAT file, the end goal is to have an HSM group with x4 Nvidia a100 and x4 AMD epyc CPUS. the process of finding the hardware needed in the CSM hardware inventory is out of the scope since it is already implemented.

This tasks is to:

1. adapt the logic in manta which reads a SAT file
2. interacts with mesa in order to get the nodes with the hardware requirements needed
3. create/update the HSM accordingly

get configuration may filter too many elements

Dear Support,

I am writing to report an issue I encountered after installing Manta on Castaneda system. The Manta binary raised an error related to missing libraries, specifically, libssl.so.1.1 and libcrypto.so.1.1.

Castaneda, which is based on Ubuntu, come with libssl3 as the default SSL library. However, the snap packaging system included the core18 package, which is the runtime environment for Ubuntu 18.04. This package contains the required missing libraries.

Here's the information from the ldd command for the Manta binary:

root@castaneda:~# ldd ./manta
linux-vdso.so.1 (0x00007fff542a5000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc63921c000)
libssl.so.1.1 => not found
libcrypto.so.1.1 => not found
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc6391fc000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc6391f7000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc63910e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc639109000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc638ee1000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc639dd2000

To resolve the issue, I created the necessary symbolic links, which provided a workaround. However, I believe this is not an ideal solution. It may be worth considering updating Manta to use the newer version of libssl and libcrypto to ensure compatibility.

Here are the commands I used to create the symbolic links:

ln -s /snap/core18/2751/usr/lib/x86_64-linux-gnu/libssl.so.1.1 /usr/lib/x86_64-linux-gnu/libssl.so.1.1
ln -s /snap/core18/2751/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1

Thanks for your support and best regards
Hussein

The command get nodes <HSM group name> shows the power state, desired CFS configuration, boot image ID, CFS configuration used to build the bot image for a list of nodes that belongs to a HSM group.
This issue is to add the HSM group name for each node to the outpput.

the goal is to show the IPs of the nodes in the get nodes output

Build clean subcommand to clean CSM data.

Some examples:

• manta clean cluster --keep-last 5 --> will delete CFS configurations, CFS sessions, IMS artifacts, BOS sessiontemplates, BOS sessions, BSS... older than the last 5 clusters created. This is not straightforward because we need to correlate these data
• manta clean configuration --> will delete CFS configurations, CFS sessions, IMS artifacts, BOS sessiontemplates, BOS sessions, BSS... related to the configuration name passed.

Currently, SAT files with only CFS configurations are valid, this cause a problem since CFS configurations are not linked to any HSM group/tenant.
This issues proposes manta to fail if user requests to process a SAT file with CFS configurations only.
The validation should make sure that any CFS configuration in the SAT file is being used by a CFS session (images section) or a BOS sessiontemplate (sessiontemplate section), then it should tag the CFS configuration with the HSM groups in the CFS session or BOS sessiontemplate

This issue depends on #53

manta l <CFS session name> fails if the CFS session name does not exists

/manta log clariden-cos-config-2.3.111
thread 'main' panicked at src/cli/commands/log.rs:26:6:
called `Result::unwrap()` on an `Err` value: reqwest::Error { kind: Status(404), url: Url { scheme: "https", cannot_be_a_base: false, username: "", password: None, host: Some(Domain("api.cmn.alps.cscs.ch")), port: None, path: "/apis/cfs/v2/sessions/clariden-cos-config-2.3.111", query: None, fragment: None } }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

manta currently relies on gitea APIs to fetch commit id information, this is quite limited because we lack of features in gitea API ( can't get the commit id related to a branch or tag name). Also CFS will be integrated with external git repos meaning gitea won't be the only source from where CFS sessions can clone from.

To simplify current limitations, we want to integrate git repo operations using git2 library.

manta currently does not resolves branch names in SAT files, it instead leverages this task to the CFS service. This has work for now but recently we found a bug in CFS where it could not resolve the branch name.

Error when creating a CFS configuration:

Error: Command '['git', 'checkout', 'cfs-layer-psi']' returned non-zero exit status 128.

This error while creating a CFS configuration means, CFS service could not validate the branch name and fails.

When using SAT file, the default behavior hides this because SAT will resolve the branch name on behalf of CFS service.

# sudo sat bootprep run --help
usage: sat bootprep run [-h] [--dry-run] [--save-files] [--no-resolve-branches] [--delete-ims-jobs] [--bos-version {v1,v2}] [--recipe-version RECIPE_VERSION] [--vars-file VARS_FILE] [--vars VARS] [--skip-existing-configs | --overwrite-configs]
                        [--skip-existing-images | --overwrite-images] [--skip-existing-templates | --overwrite-templates] [--output-dir OUTPUT_DIR] [--public-key-file-path PUBLIC_KEY_FILE_PATH | --public-key-id PUBLIC_KEY_ID]
                        input_file

Create images, configurations and session templates.

positional arguments:
  input_file            Path to the input YAML file that defines the configurations, images, and session templates to create.

optional arguments:
  -h, --help            show this help message and exit
  --dry-run, -d         Do a dry-run. Do not actually create CFS configurations, build images, customize images, or create BOS session templates, but walk through all the other steps.
  --save-files, -s      Save files that could be passed to the CFS and BOS to create CFS configurations and BOS session templates, respectively.
  --no-resolve-branches

As shown above, you can instruct SAT command to leverage the resolving branch behavior to CFS by using argument --no-resolve-branches

Manta should do the same as SAT and resolve git branches automatically, this will make the command slower but safer to run.

Important: keep the branch name in the request json payload so we can retrieve this information in the future when inspecting the CFS configuration layer details.

One of Manta's goals is to make CFS configurations as first citizens, for this we need to make user we can identify each CFS configuration for each HSM group/tenant.

CFS configurations don't contain HSM information, this makes difficult to find out which CFS configuration belongs to which tenant. Currently, CSCS is embedding the HSM name into the CFS configuration name, this is far from optimal.
This issue proposes to add HSM groups as tags to the CFS configurations.

Imagine a user starts using manta and they don't know which site is manta configured with. The next step would be to run manta config show or inspect the configuration file manually (more troublesome). If manta does not have access to keycloak API, then it won't show an error, but the user still does not know to which site is manta pointing to, this is inefficient and manta should instead show the information it has access to even if network is down.

Manta can manage multiple auth tokens depending on the site the user has worked with.
In order to improve the auth token cleaning process, we will provide the user with a list of local auth token to delete

Please chose the site token to delete from the list below::
> alpsm_auth
  alps_auth

We currently have 3 different type of commands to manage SAT files:

• apply configuration
• apply image
• apply cluster

This is confusing to the users, since version 1.23.0 manta is quite compatible with how HPE manages SAT files (eg support to Cray products, IMS images, etc)

This issue it to get rid of the sub commands above and replace them with a single command called manta apply sat-file

Add a new section to SAT file called site:

example

site: alps
configurations:
  name: test-config
...

If the site section is defined, then manta should look into the configuration file to look for the right url to talk to CSM

Currently, manta CI fails creating apply artifacts because the cc crate which is a dependency for openssl breaks the build tasks.
openssl and cc are aware of this and they are working on the issue.

sfackler/rust-openssl#2184

At the moment the parent public CA cert file name for manta to trust CSM is dynamically calculated. This is troublesome for the configuration/setup of manta.
Create a new entry in manta config file specifying the path and filename where the CSM public root CA cert is

Recently we added a new functionality in manta where SAT files could have a git tag value in each CFS configuration layer.
This issues is to request a git tag lookup functionality when running manta get configuration -n <CFS configuration name> command, as a result, manta will lookup the git tag from the CFS configuration layer commit id and show it on screen with the rest of information

currently, we store k8s and gitea authentication details in a hashicorp-vault instance which can only be accessed through VPN, this make difficult for manta to be portable.
A solution would be creating an user certificate CSM k8s can accept and create individual users in gitea

Create manta docs using GitHub pages and a static site generator
https://pages.github.com/
We could use módica https://squidfunk.github.io/mkdocs-material/ as a static site generator since this the one used by stackinator

Manta fails in creating CFS configuration layer from SAT file when deserializing commit id value.

From:

  - name: psi
    playbook: layer0.yml
    git:
      url: https://api-gw-service-nmn.local/vcs/cray/vcluster-psidev-ansible.git
      commit: b81d7873da105c1775865588f4b8ab77842de60d

To:

| fora-cos-config-manuel-test-5    | 2024-02-15T19:46:29Z | COMMIT: ec773be15f72aed7c4a2161540200dec14d907f3 NAME: ss11               |
|                                  |                      | COMMIT: 06dcdc36181a05552ceae98da67bb16604dee34a NAME: cos                |
|                                  |                      | COMMIT: 64ab09c1adb0a431c479f8521c528dc9c116a869 NAME: csm                |
|                                  |                      | COMMIT: 3a0d13133a66a9ea4a6763a9202264a2250a113c NAME: cscs               |
|                                  |                      | COMMIT: Not defined NAME: psi                                             |

Add support for the following structs in SAT files:

configurations (cray-product-catalog in https://github.com/Cray-HPE/cray-product-catalog):

https://cray-hpe.github.io/docs-sat/en-26/usage/sat_bootprep/#define-cfs-configurations

        product:
          name: cos
          version: 2.4.122
          branch: cscs-23.06.0

images:

see https://cray-hpe.github.io/docs-sat/en-26/usage/sat_bootprep/#define-ims-images

  base:
    image_ref: base_cos_image

and

  base:
    product:
      name: cos
      type: recipe
      version: "2.4.139"

also support old SAT file version

- name: image-cos-__DATE__
  ims:
    is_recipe: false
    id: 22294fa6-f869-4acf-bcf4-0d27df5e824b
  configuration: cos-config-__DATE__
  configuration_group_names:
  - Compute

currently, manta delegates base image id validation to CFS when creating a CFS session to build an image. This work and the return message is understandable for a CSM sys admin:

#### Container 'ansible' logs

Inventory generation failed. Exiting

However this message how no significant meaning to a user not familiar with CSM and the interaction with the system going through manta + SAT file.

Therefore, it would be beneficial to be proactive and make this validation at the manta side and show a more meaningful message like base image ID not found. Please chose a different ID.

New SAT file schema don't follow the session_template like below anymore:

session_templates:
- name: zinal-client-{{ version }}
  image: zinal-image-20231204014122
  configuration: zinal-client-{{ version }}
  bos_parameters:
    boot_sets:
      compute:
        kernel_parameters: ip=dhcp quiet spire_join_token=${SPIRE_JOIN_TOKEN}
        node_groups:
        - zinal_tds

Because manta tries to be backward compatible, we will add support to this