22.44. solidfire - Solidfire

The following documentation is for Solidfire (solidfire) content package at version v4.12.0-alpha00.2+g0fa92b5e1c9d284e6106ee414a89812cda8a43bf.

22.44.1. Object Specific Documentation

22.44.1.1. params

The content package provides the following params.

22.44.1.1.1. solidfire/address

This parameter holds our best guess as to what the address we should use to talk to the Solidfire API over. The solidfire-wait-for-api task does most of the grunt work in attempting to keep this param up to date., although the solidfire-configure-network task will also set it if needed.

22.44.1.1.2. solidfire/clear-network-config

By default, we have the Solidfire RTFI process continue to use the network configuration it started with. If this param is set to true, then at the end of the RTFI process the box will revert to using DHCP on the Bond1G interface.

This flag is only intended to be used when you are going to move the Solidfire box to a different network.

22.44.1.1.3. solidfire/configure/management

This param is used to set the static network config on the Bond1G interface for a Solidfire node before the RTFI process kicks off. You should only fill out this parameter if you do not want the Solidfire appliance to revert to DHCP at the end of the install. This param has the following fields:

  • address: the IPv4 address to set

  • netmask: the netmask in dotted quad format.

  • gateway: the default gateway to use.

  • dns-nameservers: The nameservers to use. This is a comma-seperated list.

  • virtualNetworkTag: the VLAN to communicate over.

22.44.1.1.4. solidfire/elementos-image-source

The location of the ElementOS install tree that should be used to RTFI the Solidfire box with. If the value of the param does not start with https:// or http://, it is assumed that the image lives on the static file server of the running dr-provision server. The contents of the tree should be the results of extracting an ElementOS ISO with bsdtar.

We handle it this way instead of using the BootEnv mechanism because Solidfire cannot be installed in the same way as a traditional operating system.

22.44.1.1.5. solidfire/monitor-wait

This parameter controls how many minutes the solidfire-monitor-rtfi task should go without being able to refresh the status of the RTFI process before giving up and signalling that the RTFI has apparently failed and needs manual intervention.

22.44.1.2. profiles

The content package provides the following profiles.

22.44.1.2.1. bootstrap-solidfire

Bootstrap Digital Rebar server for advanced operation

  • Solidfire

    • Downloads context containers

This is designed to be extended or replaced with a site specific bootstrap that uses the base tasks but performs additional bootstrapping.

22.44.1.3. stages

The content package provides the following stages.

22.44.1.3.1. solidfire-install

This stage tests to make sure that the node is in fact a Solidfire node, tests to make sure the solidfire context is useable, reboots into the already installed Solidfire operating environment, kicks off the RTFI, and waits for it to finish.

22.44.1.4. tasks

The content package provides the following tasks.

22.44.1.4.1. solidfire-configure-network

Configure the requested static network configration on a Solidfire appliance using the per-node NetworkConfig APIs. It takes care to work around some interesting quirks in how those APIs work, and should be run before starting the RTFI process.

22.44.1.4.2. solidfire-hack-up-network-json

This task should not be used in production – it is used to reset the machine configuration in a carefully controlled development environment when the other option is to call Solidfire support.

22.44.1.4.3. solidfire-monitor-rtfi

Monitor the progress of the Solidfire RTFI process, taking into account that intermittent reboots and loss of network connectivity are expected as the reinstall process proceeds. If the process exits with any state besides FinishSuccess or FinishFailure, you will probably need to contact Solidfire support for failure analysis and next steps. It is not unusual for this process to take tens of minutes to a few hours, depending on what all needs to be updated.

Please note that this task will not time out as long as it can get timely updates on the status of the RTFI process. It will only time out after more than solidfire/monitor-wait minutes have passed without being able to talk to the solidfire API on the system going through RTFI.

22.44.1.4.4. solidfire-nodeinfo

This task is mainly used for development and informational purposes, it is not part of any of the default states or workflows.

22.44.1.4.5. solidfire-test-eligibility

There are a few of tests that we must perform to see if a node can be managed by the Solidfire content bundle:

  1. The node must be a Solidfire node.

  2. The docker-context plugin must be present and operational.

  3. The image for the solidfire context must be present.

This task must be run from within Sledgehammer.