Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • For R3, Cloud-Agnostic Workload Deployment Policy (Intent) can be stored in the form of configuration file(s) in the OOM K8S Persistent Volumes to simplify implementation. 
    • Can be directly mapped to specific realization (e.g. OpenStack Flavor, Azure Instance Type) to simplify implementation. 
    • For R4 and beyond, this policy (optionally with specific realization options) will be passed from SO → MC. This is captured in the R4 and beyond workflow (Edge Scoping - Casablanca Stretch Goal/Beyond Casablanca).
  • This policy is exactly the same as the policies with "deployment-intent" in the Cloud Selection Policy for Homing described in Section 2.
  • An exemplary policy is depicted below.

...

  • Deployment-Intent 
    • 1. "Infrastructure Resource Isolation for VNF" – { "qosProperty": { {"Burstable QoS": "TRUE", "Burstable QoS Oversubscription Percentage": "25"} } }
      • Casablanca Plan
        • Only certain pre-defined over-subscription values are allowed to reflect practical deployment and simplify implementation 
      • Dublin & Beyond Potential Plan
        • Creating instance types on demand for private clouds - to study
    • 2. Cloud-agnostic Workload Deployment Policy (Intent) is not passed in the OOF → SO API & SO → MC API
      • Casablanca Plan
        • Cloud-Agnostic Workload Deployment Policy (Intent) can be stored in the form of Multi-Cloud configuration file(s) in OOM K8S Persistent Volumes directly mapped to specific realization (e.g. OpenStack Flavor, Azure Instance Type) to simplify implementation.  
      • Dublin & Beyond Potential Plan
  • Policy-based capacity check & cloud-selection
    • 3. Tenant Information is not passed in the OOF → MC API
      • Casablanca Plan
        • The tenant information is derived from a simple mapping function per <cloud owner, cloud region>
          • A simple mapping would be a tenant per <cloud owner, cloud region> as part of Multi-VIM plugin configuration.
          • Need to make sure that this scheme is synchronous with the SO → MC API path
      • Dublin & Beyond Potential Plan
        • Pass Tenant Information per <cloud owner, cloud region> in the OOF → MC API
    • 4. Capacity Check for Public Clouds is not supported
      • Casablanca Plan
        • Public Clouds always pass the capacity check
      • Dublin & Beyond Potential Plan
        • Quota in Public Clouds - to study
    • 5. VM Instance type/VM Feature Group dollar-cost-based cloud selection 

      • Casablanca Plan

        • VM Instance type/VM Feature Group dollar-cost-based cloud selection is not mandatory for all Multi-Cloud Plugins

        • If a Multi-Cloud Plugin does not support cost based on "dollarCostEvaluationVM-Type" and/or "dollarCostEvaluationVM-FeatureGroup"

          • The workload deployment cost is computed as a fixed cost per plugin
      • Dublin & Beyond Potential Plan

        • Deep dive further on dollar-cost-based cloud selection models/implementation for public/private clouds

      6.  The workload instance type model (Note 1 below) is not passed from OOF → MC. Rationale below.

        • clouds 
      • Currently, the VNFC model supports only compute/memory/local storage. A comprehensive VNFC model needs to include HW generation (Intel Broadwell/Haswell, ARM etc.), HPA details (SR-IOV etc.) and more.  

      • Casablanca Plan

        • Since the VNFC model standardization is in progress, VNFC mapping to VM Instance Type (OpenStack Flavor, Azure M4 etc.) happens in the Multi-Cloud plugin through configuration. 

        • Note 1: An exception to the rule is a simple capacity check based on VM compute/memory/local storage which can be supported by the current instance type model.
      • Dublin & Beyond Potential Plan
        • Align with the modeling work and make progress

Cloud Resource Partitioning for Differentiated QoS (Combined with Previous)

...