Talk:Meza/Common Meza Test Environment (CMTE) REL1 43

Do we really want to start off with a DVD?

In step 1.1.2 "Download the DVD", it says:

Download the DVD iso, not the minimal iso because we want to create a graphical workstation target with all the server software of the LAMP stack.

Is this really good advice? Is it required? I think we would be able to use the minimal.iso. I myself added the "not the minimal iso" wording after I started off with a minimal iso influenced by later instructions (1.4.6) that tell you to 'select "Server" (no other options)' - which normally means a 'headless' or non-graphical OS - and that is exactly the type of environment I use for my Meza on Digital Ocean. But, I had to download the DVD and switch to a full graphical desktop OS because later instructions are based on a GUI (e.g. 1.5.5 User creation, 1.5.9 Disable screen blanking).

We could suggest the 'workstation image' if we really want to encourage a full desktop experience on the Controller. The workstation image would be a quicker download.

Still, for really all testing and development of Meza, we simply need a Rocky Linux host. It does not need to be a graphical workstation, or even a VM. It could be a Docker machine or Amazon Machine Image (AMI), or a headless Rocky Linux "Droplet" (VM) at Digital Ocean. Testing and development can be done via tools on a proper workstation using e.g. VSCode's ability to interface with local and remote containers, hosts, virtual machines and SSH.

The more software and tools we specify in a Development and Test environment beyond what is absolutely necessary creates a larger maintenance burden.

For reference, at https://rockylinux.org/download they offer these categories:

• Default Images
  • DVD
  • Boot
  • Minimal
• Cloud Images
  • Generic (QCOW2)
  • AWS AMI
  • Google Cloud
  • Microsoft Azure
• Docker (OCI) Images
  • Full
  • Minimal
• Desktop/Workstation Live Images
  • GNOME
  • GNOME (Lite)
  • KDE
• Windows Subsystem for Linux (WSL) Images

For further reference, just assume we wanted to use a minimal iso (best idea), but wanted to provide instruction / assistance on how to convert a minimal 'headless server' into a full "Server with GUI". There is literally a set method to do that on DNF systems like Rocky Linux. But you can see the array of choices and overhead of providing such a platform:

dnf group info "Server with GUI"

Environment Group: Server with GUI 
 Description: An integrated, easy-to-manage server with a graphical interface. 
 Mandatory Groups: 
   Container Management 
   GNOME 
   Hardware Monitoring Utilities 
   Headless Management 
   Internet Browser 
   Server product core 
   base-x 
   core 
   fonts 
   guest-desktop-agents 
   hardware-support 
   input-methods 
   multimedia 
   networkmanager-submodules 
   print-client 
   standard 
 Optional Groups: 
   Basic Web Server 
   DNS Name Server 
   Debugging Tools 
   FTP Server 
   File and Storage Server 
   Guest Agents 
   Infiniband Support 
   Mail Server 
   Network File System Client 
   Network Servers 
   Performance Tools 
   Remote Desktop Clients 
   Remote Management for Linux 
   Virtualization Client 
   Virtualization Hypervisor 
   Virtualization Tools 
   Windows File Server
 

Greg Rundlett (talk) 20:23, 31 July 2025 (UTC)

getmeza.sh should have a clear job description

getmeza.sh necessarily has to fetch the project source code. It currently also ensures that many requirements are met since Meza will not operate without Python and Ansible (and other stuff).

getmeza.sh should provision the full CMTE like a true 'installer' IOW, We could improve on what the script currently does, practically removing the entire CMTE procedure. What aspects and responsibilities of the CMTE procedure could not fit in getmeza.sh?

Or getmeza.sh could be more of a 'kickstart' script that bootstraps any environment to be able to run Ansible; and then we could have a "setup Meza controller" playbook to fully provision the environment. Ansible playbooks are probably better than doing this using pure shell scripts. This approach would probably lend itself to more easily factoring different types of installs and roles (e.g. Cloud, Docker, Vagrant and controller, minion, db etc.)

In fact getmeza.sh already takes responsibility to condition and configure the system such that it can be used straight away. So I'm probably just arguing that we avoid and remove difficult/duplicate instructions in the CMTE procedure such as

• 1.6.6.2 "Install dependencies for Kernel and perform update"
• 1.5.5 "Create a user called "Userx"
• 3.1.13 "Verify that you have the right repos enabled"

Another benefit of removing responsibility for system software and configuration from the CMTE setup is that it won't be at odds with the getmeza.sh script and/or playbooks and roles within Meza. Today the CMTE procedure says (1.6.6.1) to "Enable the EPEL (Extra Packages for Enterprise Linux) repo". But EPEL is also managed programatically in getmeza.sh AND base role AND test container Greg Rundlett (talk) 01:29, 1 August 2025 (UTC)