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 — basic hazelcast.xml processing to set backup-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

Previous page Next page