Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Planning and Deployment of Service Templates Overview

 

The service planning functionality of Edge Services Director enables you to create service templates and deploy the same service template configuration to multiple devices. As a designer, when you create a service template, you can configure generic properties and modify it to suit your network deployment needs, thereby enabling streamlined and simplified administration of services (such as stateful firewall [SFW], carrier-grade NAT [CGNAT], application delivery controller [ADC], and traffic load balancing [TLB]) on service delivery gateways (SDGs) in your topology.

This topic contains the following sections that describe the sequence of operations performed for planning and deploying service templates:

Planning Workflow for Service Templates

The fundamental workflow of planning templates is derived from the existing devices inventory and framework:

  • The designer creates the service template by using the available inventory service components and structure model.

  • The designer can import the discovered service data while creating the service template for the existing service data values of the device.

  • While creating the service template, the designer can add or modify service parameter values and restrict the access level for each service parameter for the operator. The designer can set the following access levels for each service parameters to operator in the planning template:

    • Read-only (The configuration parameter is read-only for operator as part of provisioning.)

    • Editable (The configuration parameter is editable as part of provisioning.)

    • Mandatory (The configuration parameter is part of provisioning but operator must provide the values.)

    • Device-Specific (The configuration parameter value needs to be entered by the operator for each device during deployment.)

The designer must publish the service templates to the operator to use in the creation of deployment plans.

An operator can create the service deployment plan using the planning template so that one deployment plan can be applied on multiple devices. This method of deploy reduces the scope for human errors that can occur with the CLI interface.

Deployment Workflow for Service Templates

The following workflow is used the deployment process:

  1. An operator uses only published planning templates to create deployment plans for a single SDG dervice or multiple SDG devices.

  2. The operator modifies or adds data in the allowed service specific parameters according to the access permissions specified by the designer and associate the deployment plan with a single SDG device or multiple SDG devices.

  3. An operator publishes the deployment plans with the device association for the designer to review and approve.

  4. The administrator must approve the configuration changes for each device for each service deployment plan.

  5. The operator has a copy of the service planning template while creating the deployment plan. After creating a deployment plan, there is no association between the deployment plan and planning template. Changes made by the operator to the deployment template are maintained in their own copy and are not reflected in the original planning template and vice-versa.

  6. The deployment plan is assigned to multiple devices and sent for approval. After a deployment plan is associated with a device, the device contains its own copy of the deployment plan . For example, if one deployment plan was created and associated with four devices, you see four deployment plans separately on each device in the service deployment plan. The operator can edit the deployment plan for each device if needed.

The status of a deployment plan determines the kinds of tasks that a user can perform:

  • Add – Create a deployment plan; the status that immediately follows this status is the Unpublish state.

  • Update – Update a deployment plan.

  • Delete – Delete a deployment plan. Only plans that are in the Unpublish state can be deleted.

  • Publish – Publish the deployment plan. In this state, the operator waits for an approval from the designer before the plan can be deployed to a device.

  • Unpublish – Unpublish the published deployment plan to make more changes.

  • Approve – The administrator or designer approves the published deployment plan.

  • Reject – The administrator or designer rejects the published deployment plan.

A deployment plan can obtain any one of the following status:

  • Discovered – This is the default state for filter discovered and stored in the inventory.

  • Unpublished – New, updated, and deleted filters are saved in draft or Unpublished state initially.

  • Published – After all the changes are done, the filter in draft status is ready for admin or designer approval and is published.

  • Rejected – An administrator or designer can reject the published filter to disapprove updates.

  • Approved – An administrator or designer can approve the published filter to concur changes.

  • Commissioned – An administrator or designer can commission filters to push to devices.

  • Commission Failed – This state is assigned to a filter if commissioning of the filter fails.

Related Documentation