Basic structure:
-
workflows/sgc/*.py
— client side -
helpers/sgc/*.py
— server side, plus some code used both client and server
Where reasonable it uses the Orca core, but some of that core is Rhino centric and not appropriate for the SGC.
Client
Workflows - SGCWorkflow
SGC workflows inherit from SGCWorkflow
(workflows/sgc/sgc_workflow.py
) which does NOT inherit from OrcaWorkflow
(that has a large amount of Rhino specific stuff in it that explodes if Rhino is not present).
SGC workflows are still tagged with the @workflow
annotation.
Workflows are all imported in workflows/sgc/init.py
A workflow consists of one or more SGCCommand
implementations strung together, plus defines the arguments required for that workflow and any checks that must be carried out between command executions.
Each workflow should also have a corresponding SGCValidator
which must be added to the sgc_validators
list (from sgc_validators.py
) in a way that doesn’t depend on the workflow class being instantiated (Orca only instantiates the workflow requested by the user).
The validator is used to determine the set of workflows that are valid after completion of any given workflow.
See workflows/sgc/sgc_install.py
(SGCInstallWorkflow
) for a simple workflow that may always be executed.
See workflows/sgc/sgc_complete_revert.py
(SGCCompleteRevertWorkflow
) for a simple workflow that may only be executed if the cluster is in a particular state.
Commands - SGCCommand
Represents a single command, such as 'Execute start-upgrade in the CLI', or 'Stop one or more SGC nodes'.
Multiple commands can be strung together in a single workflow to create more complex behaviour, such as 'perform all the commands necessary to online upgrade the SGC cluster'.
A command can be used in multiple workflows.
See the various implementations in workflows/sgc/sgc_commands.py
for examples.
SGCUniverseView
The SGCUniverseView
represents the merged set of SGCClusterView
objects from across all hosts.
For example, host vm1
and vm2
both return an SGCHostView
with one SGCClusterView
for cluster test
.
The SGCClusterView
for vm1
only contains the nodes existing on vm1
and the SGCClusterView
for vm2
only contains the nodes existing on vm2
.
The SGCUniverseView
derived from these two SGCHostView
objects will contain one SGCClusterView
containing the nodes from both vm1
and vm2
.
Where multiple different clusters exist the SGCUniverseView
will create a single unified SGCClusterView
for each of the differently named clusters.
SGCUniverseView
is returned by the sgc_workflow.sgc_get_full_cluster_status()
(all clusters) and sgc_workflow.sgc_get_single_cluster_status()
(cluster specified in --cluster
parameter) methods.
Server
helpers/sgc/*.py
contain a bundle of objects and methods that are primarily used on the server side (i.e. the SGC nodes).
These include:
-
sgc_backup.py
— stuff relating to backing up SGC nodes -
sgc_common.py
— NoSgcFound exception -
sgc_config.py
— stuff that defines important configuration files, used to backup SGCs and also to prepare replacement SGCs for upgrade and revert -
sgc_hazelcast_xml.py
— basichazelcast.xml
processing to setbackup-count
sensibly in new SGC installations -
sgc_node.py
— stuff related to interacting with a live SGC node; config file locations, node state, CLI access -
sgc_package.py
— stuff related to ocss7 installation packages; package validation, version extraction and installation. Used by both client and server code. -
sgc_views.py
— views of SGC clusters, nodes and instances, used both from client and server