Consolidate Open Issues and Establish a Road Map

[freephile]

There are old open issues all over the place. They need to be consolidated, and secondly they need to be prioritized into a Road Map. The consolidation part implies that there are certain tags to identify what the issue pertains to so that issues can be grouped and sorted logically:

Product Management Aspect

Bug, Feature, Organization / Administration, Financial / Sponsor, Documentation, Planning, Big Picture / Alternatives, Security, Integration.

Project Management Aspect

Issues classified by type: 'minor', 'issue', 'story' or 'epic' so that individual issues can be assembled into stories and worked. Or that stories can be broken down into issues. A default 'issue' should be clear and concise enough to describe work that can be done in less than half a day (3 hours). If not, then it is too big or too vague - so it becomes a story that must be refined into distinct issues that compose all the work for the story. If the work is so big that there are multiple stories; and it is cross-functional; then it should probably be an epic.

Architecture / Component Aspect

Web server, proxy, PHP, Python, JavaScript, Git, Ansible, Elasticsearch, Database

User Aspect

UI, UX, Developer, Systems Administration, DevOps, Quality, Testing

The Queues

• Meza doesn't support the config I need enterprisemediawiki/meza#1051 lists Wanted Features such as security
• https://github.com/nasa/meza/issues/ is the list of 'current' issues
• https://github.com/freephile/meza/issues/ list of issues from the development perspective

[freephile]

As of September 2025 a ton of progress has been made as far as upgrading the project to run on the latest Long-Term Support (LTS) version of MediaWiki REL1_43 and the corresponding newest release of Semantic MediaWiki SMW 6.x

Important

See releases/tag/43.33.2 for a detailed and comprehensive look.

[freephile]

Here are some notes from a recent deploy

PLAY RECAP *********************************************************************
localhost                  : ok=502  changed=76   unreachable=0    failed=0    skipped=310  rescued=0    ignored=1   

There are 827 tasks performed in the latest deploy. That's a lot to wait for, and review. That's why it needs to be made more structured and targeted with better tags and conditionals.

See the tasks in an outline with
sudo meza deploy monolith -vvv -e group_wheel=wheel -e ansible_user=meza-ansible --list-tasks

Test an upgrade using your DB and file uploads

You can do a destructive (meaning the current database(s) and file uploads for all wikis will be overwritten) deploy using the --overwrite option with sudo meza deploy monolith -vvv -e group_wheel=wheel -e ansible_user=meza-ansible --overwrite

This is particularly helpful when you want to test a blank 'demo' system using real data and images from your backup, staging, or prod environment. Just mount the "backups" and "uploads" into your Vagrant guest VM and --overwrite.

Hosts file is now in YAML format instead of .ini

The hosts file is produced by running the getmeza.sh script. However,
sudo bash /opt/meza/src/scripts/getmeza.sh will not regenerate the hosts file. It detects the file's existence and skips generation - assuming that you don't want to accidentally overwrite your inventory.
With a missing hosts file, you will get all kinds of errors - but you can't just delete the existing file to get a new one generated. Hosts file generation and example could be made more robust and explicit.

Manually deleting the lock file

When something goes wrong, you may need to manually delete the lock file because Meza didn't clean up after itself. rm /opt/data-meza/env-monolith-deploy.lock

Updating Composer gives an error about using root

TASK [composer : Update composer itself]
STDERR:
Composer plugins have been disabled for safety in this non-interactive session.
Set COMPOSER_ALLOW_SUPERUSER=1 if you want to allow plugins to run as root/super user.
You are already using the latest available Composer version 2.8.11 (stable channel).

This is one example of why we shouldn't use 'sudo' with Meza commands. (needs link to ticket)

Mongo Why?

What does MongoDB do? Why is it in the Apache-PHP role? I guess it is involved in profiling - which should be a completely separate role.

So many facts

"ansible_facts": appears 191 times. In some cases such as /opt/meza/src/roles/set-vars/tasks/main.yml:22
TASK [set-vars : Set OS-family specific variables]
Group wheel is set properly        "group_wheel": "wheel",
Buy why is this repeated in the deploy log 14 times? and why is group_wheel not set when it is first needed so that we need to pass it as an extra-var?

Set vars needs a persistence file.

Set-vars is wasting time doing nothing. There is no file to set and persist the variables into (if that's what is supposed to be happening here).
/opt/meza/src/roles/set-vars/tasks/main.yml:68
TASK [set-vars : Set meza environment-specific public variables for env=monolith]
"Could not find or access '/opt/conf-meza/public/env/monolith.yml' on the Ansible Controller.\nIf you are using a module and expect the file to exist on the remote, see the remote_src option"

[freephile]

The roadmap is taking shape here under 'projects'.

Projects in GitHub allow you to define a workboard, prioritize, assign items, schedule them etc.

So while we can discuss areas to focus on in discussions, we can map the issues into one or more work boards in projects.

[freephile]

The variable group_wheel is undefined on line 47 in site.yml because it is not set or included anywhere in your Ansible inventory, group_vars, host_vars, or extra vars at the time the playbook runs.

In Ansible, variables like group_wheel must be defined in one of the following places for them to be available:

In your inventory file (as a host or group variable)
In a group_vars/ or host_vars/ file
As a vars: block in the playbook or role
Passed via --extra-vars on the command line
If group_wheel is not defined in any of these, Ansible will raise an error when it tries to use it.

Previously, the notion of 'wheel' was hard-coded, limiting any possibility to make Meza compatible with Debian and derivatives. So, it was abstracted into a variable. Now it is apparent that the order of execution (playbook 'set-vars' must be a pre-task for all other playbooks), and the persistence of variables like 'group_wheel' needs to be addressed.