CanastaWiki / Canasta-CLI

The Canasta command line interface, written in Go
MIT License
5 stars 14 forks source link

Add farm management support #88

Closed chl178 closed 1 year ago

chl178 commented 1 year ago

Related Issue: #57

Background:

Our previous discussions have highlighted the need to provide more flexibility and efficiency in managing wiki farms in Canasta, which is a Docker-based MediaWiki distribution. The initial implementation included the ability to run multiple wikis (or a wiki farm) within a single container, which was a significant stride towards our project's goal. However, for even more user-friendly and effective management of wiki farms, the enhancement of Canasta's CLI became evident.

Summary

This PR introduces two new commands to the CLI for managing wiki farms: add and remove. Furthermore, we've updated the create command to directly create a wiki farm in a Canasta instance using a wikis.yaml file.

Importantly, our design philosophy in adding wiki farm support ensures the continuity of the original functionality. If you choose not to use the wiki farm related features, all other command operations will work as before. This makes the adoption of wiki farm features completely optional, allowing you to continue using the CLI in the way you're familiar with if desired.

Table of Contents

Enhancements

create

Description: Creates a Canasta installation. Enhanced to support wiki farm setup with the -f flag.

Usage: sudo go run canasta.go create [flags]

YAML Format for Wiki Farm: To create a wiki farm, you need to provide a YAML file with the following format:

wikis:
  - id: [WIKI_ID] # Example: "wiki1"
    url: [WIKI_URL] # Example: "mywiki1.example.com"
    name: [WIKI_SITENAME] # Example: "mywiki1"

sudo go run canasta.go create -f [yamlfile] # Example: "wikis.yaml

extension

Description: Manage Canasta extensions. Enhanced to target a specific wiki within the farm using the -w flag.

Subcommands:

Usage: sudo go run canasta.go extension [subcommand] [flags] Flags:

New Commands

add

Description: Adds a new wiki to a Canasta instance.

Usage: sudo go run canasta.go add [flags] Flags:

remove

Description: Removes a wiki from a Canasta instance.

Usage: sudo go run canasta.go remove [flags] Flags:

Docker-Compose Structure

Our current docker compose structure is as follows:

config/
    CommonSettings.php
    Caddyfile
    CanastaFooterIcon.php
    composer.local.json
    default.vcl
        wikis.yaml
    settings/
                *.php
    wiki1/
        Settings.php
            *.php
    wiki2/
            Settings.php
            *.php
images/
        wiki1/
    wiki2/

Each wiki's settings file is contained within a directory of their name under the config directory. These settings include a CommonSettings.php file. Eache wiki's images are stored in their corresponding file under images/[WIKIID].

In the new version, we consider all Canasta instances as wiki farms, even if there is only one wiki in that instance.Therefore, manual imports of settings and images must be placed in the corresponding wiki ID's folder.

Version Migration

To make it more convenient for users to migrate to the new version, the new Canasta CLI will automatically detect when used, and then create configuration files such as YAML, images folder, etc. If the number of wikis in the farm is more than 1, then the LocalSettings.php will be renamed to CommonSettings.php.

Next Steps:

we will initiate server tests to evaluate the practicality and performance of these updates. Your support and collaboration in this testing phase will be crucial to ensure that our modifications not only align with technical specifications but also cater to real-world usage scenarios.

olsonjaredm commented 1 year ago

I like using add/remove for the commands (I can't come up with any better terms).

As far as PHP file structure I'd say default to CommonSettings.php for the upper level with the expectation that for single-wiki 'farms' this file is a stub and ignored by admins. Then each of the subfolders for individual wikis contain their own LocalSettings.php. I also like the idea of it concatenating all PHP files in the folders so admins can rename them what they like.