Class DeploymentPlan

java.lang.Object
com.eqixiac.equinix.design.optimizer.wizard.model.DeploymentPlan
public class DeploymentPlan extends Object
A complete deployment plan generated by the Deployment Wizard. Contains all planned Cloud Routers, provider connections, backbone links, routing protocols, and aggregated pricing. Supports review via toMarkdown(), dry-run validation via dryRun(), and full execution via execute().

  • Constructor Summary

    Constructors
    Constructor
    Description
    DeploymentPlan()
     

  • Method Summary

    Modifier and Type
    Method
    Description
    DeploymentPlan
    dryRun()
    Re-runs the layered plan-time validation and returns a new plan with the refreshed status.
    DeploymentOutcome
    execute()
    Executes the deployment plan with no extra customer inputs — for a backbone-only plan, or a plan whose provider connections already carry their own authorization keys.
    DeploymentOutcome
    execute(ExecutionInputs inputs)
    Executes the deployment plan, creating all resources in the correct order: Cloud Routers, then provider connections, then backbone links, then routing protocols.
    List<ProvisioningError>
    rollback(DeploymentOutcome outcome)
    Best-effort teardown of the resources provisioned by a prior execute(): deletes the connections (and backbone links), then the Cloud Routers, in reverse dependency order.
    String
    toMarkdown()
    Generates a full markdown-formatted deployment plan report with bandwidth and pricing tables.
    String
    toSummary()
    Generates a concise plain-text summary of the deployment plan.
    int
    totalResourceCount()
    Total number of resources that will be created by this plan.
    PlanValueAssessment
    valueRealization()
    Begins a value-realization assessment of this plan: declare your per-provider monthly egress volumes and get back the egress savings the plan's private interconnects unlock, netted against the plan's actual interconnect cost.

    Methods inherited from class Object

    clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

  • Constructor Details

    • DeploymentPlan

      public DeploymentPlan()

  • Method Details

    • totalResourceCount

      public int totalResourceCount()
      Total number of resources that will be created by this plan.

    • toSummary

      public String toSummary()
      Generates a concise plain-text summary of the deployment plan.

    • toMarkdown

      public String toMarkdown()
      Generates a full markdown-formatted deployment plan report with bandwidth and pricing tables.

    • valueRealization

      public PlanValueAssessment valueRealization()
      Begins a value-realization assessment of this plan: declare your per-provider monthly egress volumes and get back the egress savings the plan's private interconnects unlock, netted against the plan's actual interconnect cost. 
      PlanValueRealization vr = plan.valueRealization()
    .egress(CloudProviderType.AWS, 50, DataUnit.TERABYTE)
    .assess();
System.out.println(vr.toMarkdown());
      Returns:
      a PlanValueAssessment builder for declaring egress volumes

    • dryRun

      public DeploymentPlan dryRun()
      Re-runs the layered plan-time validation and returns a new plan with the refreshed status.

      This is the same validation the wizard runs when it builds the plan: Layer 1 structural + catalog checks, Layer 2 live Cloud Router dry-run (POST /routers?dryRun=true), and Layer 3 connection endpoint dispatch — a connection whose A-side Cloud Router does not exist yet is recorded as deferred (its live endpoint dry-run runs at provisioning, and needs your authorization keys) rather than sent a doomed endpoint-less dry-run, while a connection with a pre-existing endpoint is dry-run for real. Nothing is provisioned: the router dry-run creates nothing, and to-be-created connections are never posted here.

      A live step that cannot be attempted — an offline / bare-stub run, or a live dry-run that the API answers with a non-rejection failure (403 not entitled, 429 throttled, 5xx, or a transport/timeout error) — is recorded as a skipped validation with a reason, never folded into the errors that invalidate the plan. Only a genuine rejection of a well-formed request (a 4xx validation rejection) is an error.

      Returns:
      a new DeploymentPlan with refreshed validity, deferred validations, skipped validations, and the required customer inputs

    • execute

      public DeploymentOutcome execute()
      Executes the deployment plan with no extra customer inputs — for a backbone-only plan, or a plan whose provider connections already carry their own authorization keys. Equivalent to execute(ExecutionInputs.none()): a provider connection that still needs a cloud authorization key fails fast (nothing is provisioned) naming the key to gather.
      Returns:
      the execution outcome with all provisioned resources and any errors
      See Also:

    • execute

      public DeploymentOutcome execute(ExecutionInputs inputs)
      Executes the deployment plan, creating all resources in the correct order: Cloud Routers, then provider connections, then backbone links, then routing protocols.

      Execution-time connection pre-flight (Layer 3a). A provider connection's live endpoint dry-run cannot run at plan time because its A-side Cloud Router does not exist yet; it runs here, at the only point it is possible. For each connection, once its A-side FCR is provisioned and its real uuid is known, a full connection body — real A-side uuid, Z-side service profile + seller region + the customer's authorization key, DOT1Q VLAN — is dry-run against the live API; only if the dry-run passes is the connection created for real. A dry-run rejection of a well-formed request (a 4xx validation rejection, e.g. HTTP 400/409) aborts the run and rolls back everything already provisioned (LIFO), so a broken plan never leaves billable Cloud Routers stranded.

      Pre-flight infeasibility never silently aborts. When the pre-flight dry-run cannot be attempted — an infeasibility rather than a rejection: 401/403 (not entitled), 429 (throttled), 5xx (server-side), or a transport/timeout error, classified by PlanValidator.classifyLiveFailure(Throwable) — the run does not abort. It records a recoverable warning that the pre-flight could not run and proceeds to the real create, which surfaces any genuine error itself. Only a true rejection aborts and rolls back. The fail-fast on a missing cloud authorization key (below) is unchanged.

      Required customer inputs. The cloud authorization keys — which a brand-new customer gathers from each cloud console — are supplied via inputs (keyed by connection name), or carried on the plan itself for a lens-3b plan. Before anything is provisioned, execution fails fast if any provider connection that needs a key is missing one, naming the connection and the exact key (ConnectionInputRequirement).

      Operational errors (a Cloud Router that does not reach PROVISIONED within the timeout, a missing upstream dependency) are captured in the outcome rather than thrown, allowing a partial deployment to be inspected and rolled back by the caller.

      An invalid plan never executes. A plan whose validation found hard errors (isValid() == false) is refused up front with an IllegalStateException listing every recorded error — executing it would provision billable resources and then fail downstream on the very defects validation already named. Fix the errors and re-plan (or dryRun() again) before executing.

      Parameters:
      inputs - the per-connection authorization keys, VLAN tags and Azure peering types the customer supplies; null is treated as ExecutionInputs.none()
      Returns:
      the execution outcome with all provisioned resources and any errors
      Throws:
      IllegalStateException - if the plan is not valid — the message lists the validation errors to fix before re-planning

    • rollback

      public List<ProvisioningError> rollback(DeploymentOutcome outcome)
      Best-effort teardown of the resources provisioned by a prior execute(): deletes the connections (and backbone links), then the Cloud Routers, in reverse dependency order. Routing protocols are removed with their parent connection. Use this to clean up a partially-failed deployment rather than leaving orphaned, billable resources behind.
      Parameters:
      outcome - the outcome returned by execute()
      Returns:
      the deletions that failed (empty when the rollback was clean)