Work Order Mode¶
Execution Models¶
With the addition of WorkOrders, there are two additional execution models to consider when building and planning infrastructure management.
The initial model revolved around provisioning and building up a machine. This is the traditional execution of DRP with extensions into Cloud infrastructure and logical components like clusters. Switch and storage provisioning through contexts fall into this model as well.
When used with clusters and resource brokers, Machine as Service can allow for operating and maintaining specific services.
When used with contexts and triggers, the system can be used to operate a CI/CD pipeline like system.
All execution models can exist at the same time with a single DRP environment.
Machine as Service¶
Once a Machine, Cluster, or ResourceBroker has been provisioned, that system can be placed in WorkOrderMode. This will cause the system not run workflows anymore and switch the WorkOrder execution mode, only WorkOrders will be processed. The goal is to operate those systems as service with Blueprints acting as defined actions to take through WorkOrders.
For example, a machine that represents a switch might use WorkOrderMode to handle port configuration changes as needed based upon other system's needs. A cluster that represents a Kubernetes Cluster might use WorkOrderMode to manage applications and other cluster management functions after initial provisioning. Blueprints could be created with tasks and initial parameters needed to take those actions. WorkOrders would be created against these system that other WorkOrders or Workflows could use to handle configuration/state changes.
In this case, the Machine / Cluster / ResourceBroker objects continue to represent an element in the data center that is being managed.
Orchestrated Tasks¶
When a Trigger is has QueueMode set to true, the Trigger
operates as a deferred WorkOrder queue where the Filter field is the
queue definition. This allows these triggers to operate like a pool of
runners waiting to do jobs as they arrive. This is subtly different
than the Machine as Server model. The runners, grouped by the filter,
are not specifically requested, but operate more anonymously.
CI/CD Pipelines¶
With the introduction of Triggers and WorkOrders, the DRP environment can now act as a general action execution environment. This model matches a more worker / action model instead of a managed system environment.
In this execution model, a set of worker are started with tags. These worker could be Machines, Clusters, or ResourceBrokers that are backed by physical, virtual, or containers. These specified workers run WorkOrders generated by Triggers to manage the whole set of systems. This is NOT necessarily used to manage infrastructure elements directly.
Some examples:
- A Blueprint could be written to handle repackaging content based upon a trigger from gitlab to rebuild and redeploy system components.
- A Blueprint could be written to do heartbeat validation of a machine upon a cron-based trigger to monitor components.