Overview of DFA Functionality

Delegated Financial Authority (DFA) enables you to self-manage your Managed VMware spend in CloudCreator. You can control any extra charges that could be incurred when users establish or modify virtual machines.

 

Topics


DFA Levels

The DFA levels are defined as follows:

  • Each virtual cloud has its own set of DFA levels.
  • Each CloudCreator user has a single DFA level assigned to them.
  • Each DFA level has a $$ value.

 

To add, assign and modify DFA levels, see Add DFA Levels and Assign Users.

 

Caution: DFA levels are set to a $$ amount per change instance. There is no limit to the number of changes a user can authorise, only a limit on the value of each individual DFA Request.

How DFA Operates

DFA operates as follows:

  • Each creation or modification of a Managed VMware virtual machine, is contained within a DFA Request (DFA.R).
  • Each resource can have a maximum of only one DFA.R in an unapproved or approved state at a time.
  • A DFA.R captures both the ‘From’ and ‘To’ states of the resource being created or modified.
  • A resource creation has no ‘From’ state, and resource deletion has no ‘To’ state.
  • CloudCreator can calculate the ‘per month’ value of both the ‘From’ and ‘To’ state of the resource. The value of the DFA.R is the difference between these two values.

 

Important:

-
Users need a DFA level greater than, or equal to the value of the DFA.R, before they can approve it.

- Changes to resources cannot be performed until the DFA.R has been approved in CloudCreator.

Operating Without DFA Control

If your organisation prefers to operate without the DFA controls, you can assign all users to the DFA level of Unlimited. This means that all changes will be auto-approved and no approval steps will be enforced upon the users of a CloudCreator.

 

See Add DFA Levels and Assign Users.

 


The Progress of a DFA Request

Each DFA Request (DFA.R) will progress from the state of 'Unapproved' through to one of the following final states:

  • Applied
  • Declined
  • Cancelled
  • Stale

 

The diagram below shows the possible paths that a DFA.R can progress through. See DFA Request States below to find out more about each stage.

 

The two most significant states in the flow are:

  • Approved or Declined. These states are controlled by the DFA Level and DFA.R value.
  • Applied. This state occurs when the changes in the DFA.R have been made. It is only possible when a request has been 'approved'. The ability to apply a DFA.R is controlled by the role(s) an individual user has. In the case of VMware, the user needs to have a VM Admin or equivalent role.

 

 


DFA Request States

The following table describes the possible DFA Request (DFA.R) states.

 

DFA.R State Description
Unapproved

The VM the DFA.R describes can't be modified. A resource can only have one DFA.R in progress at a time. This reduces the likelihood of a VM being modified while a DFA.R is already in operation.

 

If a VMware user needs to modify a VM which already has a DFA.R in place, they can view all the details. They cannot create a new DFA.R but can contact the originator to resolve the issue of two concurrent changes being attempted.

Cancelled

A DFA.R can be cancelled in the following situations:

  • Before or after it is approved but not after it has been applied. For example, if an emergency activity has to be performed against the VM, it can be cancelled.
  • By any user who has VM modification rights (anyone with a VMware role within CloudCreator). In the context of VMware resources, while modifications of the resource are disabled, users can still power the VM on or off.

 

When a cancellation occurs, an email notification is sent to the originator if the DFA.R, unless it is the user who performed the cancellation. The DFA.R information is retained so the originator can track what happened to the DFA.R, and recreate it if needed.

Approved and Applying

When a DFA.R has been approved, the VM it relates to can be modified.

 

‘Applying a DFA.R’ is the task of making the change to the VM managed by the DFA.R. As the term ‘action’ is already used in relation to VMs, the term ‘apply’ is used instead.

 

The application of a DFA.R is performed by the originator (or another user with a Managed VMware role or sufficient rights). They are assumed to be competent to decide whether a VM restart is OK, and should be part of the change that needs to be applied, ie: they have the technical knowledge to make that decision.

Applied The VM modification managed by the DFA.R has been completed.
Stale

Occurs when a change occurs to a VM outside of the control of CloudCreator.

 

Example:

  • When changes are made to resources by CCL staff outside of CloudCreator (and therefore outside of the DFA controls within CloudCreator).
  • When approved changes are not applied immediately. For example, when a DFA.R for a VMware VM modification is stopped due to a VM reboot approval being required. In the meantime, if another change occurs that affects the state of the VM, this will result in the DFA.R becoming stale.

 

A stale DFA.R is expected to be an exceptional circumstance. In CloudCreator, the following events occur:

 

  1. The originator of the DFA.R is notified of the change to the VM that has made the DFA.R stale.
  2. The DFA.R is removed from the list of approved DFA.R's, as it is no longer able to be applied.
  3. The DFA.R remains on the list of DFA.Rs so users can view what happened to it.
  4. The DFA.R is clearly noted as stale. The user can choose to query the current state of the resource to understand the change that made the DFA.R stale.

 


 

 

 

 

 

 

 

 

 

 

The page cannot be found

The page you are looking for might have been removed, had its name changed, or is temporarily unavailable. Please make sure you spelled the page name correctly or use the search box.