Actualize documentation

Signed-off-by: Andrea Mazzotti <[email protected]>

doc/AUTH.md

@@ -35,7 +35,7 @@ eyJhbGciOiJFZERTQSIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJFbGVtZW50YWxSZWdpc3RyYXRpb25SZWN
 The token is in JWT format. You can inspect it using the web app at [jwt.io](https://jwt.io).  
 By default registration tokens do not and should not expire.  
 The registration tokens are normally shared with hosts during the provisioning phase and are used by the `elemental-agent` to register a new ElementalHost.  
-Note that during the registration phase (`elemental-agent --register`), the `elemental-agent` will exchange its registration token for a fresh one, when fetching the remote ElementalRegistration to update (and override) the agent config file.  
+Note that during the registration phase (`elemental-agent register`), the `elemental-agent` will exchange its registration token for a fresh one, when fetching the remote ElementalRegistration to update (and override) the agent config file.  
 For this reason issuing tokens with an expiration date will eventually impact the ability of the hosts to reset and re-register.  
 
 You can generate a valid `elemental-agent` config file from any registration, using the conveniency `print_agent_config.sh` script from this repo (depends on `kubectl` and `yq`):
@@ -164,7 +164,7 @@ This is also documented in in the [OpenAPI specs](../elemental-openapi.yaml).
 Similarly to the registration tokens, host tokens are also in JWT format.  
 The `elemental-agent` will always generate a new private signing key in a `private.key` file within its work directory.  
 If no file exists, a new one is created, otherwise it's simply loaded.  
-This gives the possibility of pre-creating a signing key before running `elemental-agent --register`.  
+This gives the possibility of pre-creating a signing key before running `elemental-agent register`.  
 The key must be an EdDSA key in PEM format.  
 
 When registering a new `ElementalHost`, the agent will pass the public key that should be used to validate its signature and also a signed JWT so that the controller can validate the request.  

doc/ELEMENTAL_AGENT.md

@@ -96,11 +96,11 @@ agent:
   hostname:
     useExisting: false
     prefix: ""
-  # Post Install behavior (when running --install)
+  # Post Install behavior (when running install)
   postInstall:
     powerOff: false
     reboot: false
-  # Post Reset behavior (when running --reset)
+  # Post Reset behavior (when running reset)
   postReset:
     powerOff: false
     reboot: false

doc/HOST_PHASES.md

@@ -22,18 +22,18 @@ If an `ElementalHost` with the same name and public key already exists, the `ele
 Normally the `Registering` phase is very short living and transitory.  
 Upon successful registration, the `elemental-agent` will automatically execute the `Finalizing Registration` phase.  
 
-This phase is ran using the `elemental-agent --register` argument.  
+This phase is ran using the `elemental-agent register` command.  
 
 ### Finalizing Registration
 
-The `Finalizing Registration` immediately follows the `Registration` phase when `elemental-agent --register` is used.  
+The `Finalizing Registration` immediately follows the `Registration` phase when `elemental-agent register` is used.  
 
 During this phase the `elemental-agent` will take the following steps:  
 
 1. Install the registered hostname. (OSPlugin dependent)
 
 1. Fetch the remote `ElementalRegistration` and use it to install a new agent config file. (OSPlugin dependent)  
-**Note:** During this phase the current agent config path is used to determine the install location. This is important if you are using a custom path (ex. `elemental-agent --config /my/custom/config.yaml`) and you will need to change it later. Migration of this file is going to be needed and depending on how the `OSPlugin` installs files (for ex. in an immutable system), the migration strategy may differ.  
+**Note:** During this phase the current agent config path is used to determine the install location. This is important if you are using a custom path (ex. `elemental-agent run --config /my/custom/config.yaml`) and you will need to change it later. Migration of this file is going to be needed and depending on how the `OSPlugin` installs files (for ex. in an immutable system), the migration strategy may differ.  
 
 1. Install the generated private key used for the host registration. (OSPlugin dependent)
 The private key is used by the `elemental-agent` for authentication and is going to be installed in the agent `workDir` (from the `ElementalRegistration` derived config) under the `private.key` filename.  
@@ -46,8 +46,8 @@ Finally it installs the system.
 Both steps are heavily `OSPlugin` dependent.  
 The `ElementalRegistration.spec.elemental.install` is a schemaless field that can be used to pass arbitrary data to the `OSPlugin`, when executing this phase.  
 
-This phase is ran using the `elemental-agent --install` argument.  
-Note that if `elemental-agent --register --install` is used, this phase will happen automatically after the registration has been finalized.  
+This phase is ran using the `elemental-agent install` command.  
+Note that if `elemental-agent register --install` is used instead, this phase will happen automatically after the registration has been finalized.  
 
 ### Bootstrapping
 
@@ -82,11 +82,11 @@ During this phase, the `elemental-agent` will inform the `OSPlugin` that reset h
 Implementation details are plugin dependent, this is the occasion for the plugin to stop services and do anything needed to prepare the system for a reset.  
 
 The `elemental-agent` will exit once reset has been triggered.  
-It is expected to run `elemental-agent --reset` after, to actually perform the reset of the host.  
+It is expected to run `elemental-agent reset` after, to actually perform the reset of the host.  
 
 ### Resetting
 
-The `Resetting` phase happens when `elemental-agent --reset` is ran.  
+The `Resetting` phase happens when `elemental-agent reset` is ran.  
 
 The `elemental-agent` will first delete the remote `ElementalHost`.  
 This will add a `deletionTimestamp` to the remote resource, however a finalizer will prevent deletion until reset is deemed successful.  
@@ -96,4 +96,4 @@ After deleting the remote `ElementalHost`, the `elemental-agent` will fetch the
 If the `OSPlugin` resets the host successfully, the remote `ElementalHost` is updated one last time to highlight reset has been completed. This will allow the deletion of the `ElementalHost`.  
 
 It is expected to re-start the lifecycle of the host at this point if desired.  
-This means running `elemental-agent --register --install` to perform a new registration and a fresh installation of the system.  
+This means running `elemental-agent register --install` to perform a new registration and a fresh installation of the system.  

doc/PLUGIN_DUMMY.md

@@ -8,15 +8,15 @@ The `elemental-agent` goes through several [phases](../../doc/HOST_PHASES.md), n
 
 ### 1. Finalizing Registration
 
-When running `elemental-agent --register`, upon successful registration, the plugin will be invoked by the agent to perform the following actions:
+When running `elemental-agent register`, upon successful registration, the plugin will be invoked by the agent to perform the following actions:
 
 - Set the chosen hostname on the host. This step relies on: `hostnamectl set-hostname`
 - Install the agent config in the work directory: `/var/lib/elemental/agent/config.yaml`
 - Install the agent private key in the work directory: `/var/lib/elemental/agent/private.key`
 
 ### 2. Installing
 
-When running `elemental-agent --install`, this plugin will dump the remote `ElementalRegistration` `spec.config.elemental.install` config into an `install.yaml` file in the agent work directory.  
+When running `elemental-agent install`, this plugin will dump the remote `ElementalRegistration` `spec.config.elemental.install` config into an `install.yaml` file in the agent work directory.  
 No further action is taken by the plugin, once the file is created the system will be considered **installed** and ready to be bootstrapped.  
 An administrator can implement logic around this expected file, for example leveraging [Systemd's Path Units](https://www.freedesktop.org/software/systemd/man/latest/systemd.path.html).  
 
@@ -35,12 +35,12 @@ Upon reboot, the bootstrap config is expected to create the `/run/cluster-api/bo
 When the `elemental-agent` receives a reset trigger, the plugin will create a `needs.reset` file in the agent work directory.  
 No further action is taken by the plugin.
 
-When the `needs.reset` file is created, some logic should take place to prepare the machine for reset, delete the `needs.reset` file and start the agent with the `--reset` argument to mark the host as reset.  
+When the `needs.reset` file is created, some logic should take place to prepare the machine for reset, delete the `needs.reset` file and start the agent with the `reset` command to mark the host as reset.  
 In this stage some host services may also be stopped or uninstalled, for example `k3s`.  
 
 ### 5. Resetting
 
-Similarly to the installation, a `reset.yaml` in the agent work directory will be created when the agent is called with the `--reset` argument.  
+Similarly to the installation, a `reset.yaml` in the agent work directory will be created when the agent is called with the `reset` command.  
 This is a simple dump of the `ElementalRegistration` `spec.config.elemental.reset` configuration.
 
 The reset will fail if the `needs.reset` file exists. This highlight that the host was not prepared for reset first.  

doc/PLUGIN_ELEMENTAL.md

@@ -23,7 +23,7 @@ Status:
 
 ### 1. Finalizing Registration
 
-When running `elemental-agent --register`, upon successful registration, the plugin will be invoked by the agent to perform the following actions:
+When running `elemental-agent register`, upon successful registration, the plugin will be invoked by the agent to perform the following actions:
 
 - Set the chosen hostname on the host.  
 - Install the agent config in the work directory: `/oem/elemental/agent/config.yaml`
@@ -33,12 +33,12 @@ For each action, the elemental plugin will create an `elemental-toolkit` cloud-i
 
 ### 2. Installing
 
-When running `elemental-agent --install`, assuming registration was performed successfully, the plugin will be invoked to:
+When running `elemental-agent install`, assuming registration was performed successfully, the plugin will be invoked to:
 
 - Apply the `cloudConfig` from the remote `ElementalRegistration`.
 - Invoke `elemental install` using the remote `ElementalRegistration` `spec.config.elemental.install` config.
 
-In a default elemental installation, the `--register` and `--install` phases are executed together by the `elemental-agent-install` service from the `Elemental recovery` partition.  
+In a default elemental installation, the `register` and `install` phases are executed together by the `elemental-agent-install` service from the `Elemental recovery` partition.  
 To debug installation issues you can run: `journalctl -xeu elemental-agent-install` on the host.  
 
 Note that when installing, the plugin will only invoke `elemental install` from a live system.  
@@ -79,8 +79,8 @@ When the `elemental-agent` receives a reset trigger, for example because the CAP
             - if: '[ -f /run/elemental/recovery_mode ]'
             name: Runs elemental reset and re-register the system
             commands:
-                - elemental-agent --debug --reset --config /oem/elemental/agent/config.yaml
-                - elemental-agent --debug --register --install --config /oem/elemental/agent/config.yaml
+                - elemental-agent reset  --debug --config /oem/elemental/agent/config.yaml
+                - elemental-agent register --debug  --install --config /oem/elemental/agent/config.yaml
                 - reboot -f
     ```
 
@@ -90,10 +90,10 @@ When the `elemental-agent` receives a reset trigger, for example because the CAP
 ### 5. Resetting
 
 In a typical Elemental installation, the reset phase is executed from the above mentioned `Elemental Reset` plan.  
-When running `elemental-agent --reset`, the plugin will make a copy of the agent config in `/tmp/elemental-agent-config.yaml` and then invoke `elemental reset` using the remote `ElementalRegistration` `spec.config.elemental.reset` config.  
+When running `elemental-agent reset`, the plugin will make a copy of the agent config in `/tmp/elemental-agent-config.yaml` and then invoke `elemental reset` using the remote `ElementalRegistration` `spec.config.elemental.reset` config.  
 If no errors occur, the previously copied agent config is moved back to `/oem/elemental/agent/config.yaml`.  
 
 Similarly to the bootstrap phase, if any issues arise, you can manually execute and debug the reset plan by running: `elemental --debug run-stage network`  
 
-Upon successful reset, the plan should run `elemental-agent --register --install` to register a new `ElementalHost` and mark it as installed.  
+Upon successful reset, the plan should run `elemental-agent register --install` to register a new `ElementalHost` and mark it as installed.  
 Finally, the host will reboot to the active partition and be ready for CAPI provisioning.