You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »


README

  • This TOC page has been created with Ahmed El Sawaf Karine Sevilla Petar Torre Saad Sheikh Tomas Fredberg Walter Kozlowski and Pankaj Goyal as editors/owners
    • Editors/owners can't in-line comments
  • To make it easier to mange content, I suggest that individuals take ownership of a topic (e.g., "9.5.1.1. hardware configuration CI/CD")
  • Click on the "Create ..." (blue button on the Confluence Ribbon above), the following pop-up window opens
  • Select "Blank Page" and click on "Create" (bottom right)
  • A new Confluence "Add Page"  opens
  •  
  • Enter the section title  (e.g., "9.5.1.1. hardware configuration CI/CD") as the Page Title
  • Add content as needed
  • To save and exit, click on "Publish" (bottom left)
    • If you exit prior to publishing the new page and content will be lost
  • As the creator of the page you can come and update content while others can comment in-line or at the bottom
  • POst publishing the page, copy the page URL and add it to the zection in this ToC page

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

9.5 Automation

9.5.1 Infrastructure LCM Automation ( including Platform Software and CI/CD)  

End-2-End understanding of what type of automation ought to be done on what layers and includes

9.5.1.1. hardware configuration CI/CD

9.5.1.2. networking automation

9.5.1.3. software development CI/CD

9.5.1.4. software deployment CI/CD (operator environment)

9.5.1.5. Identify "Closed Loop Automation" as a Gap in Ch10

9.5.2  Workload onboarding automation (including CI/CD). Owner: Walter Kozlowski

9.5.2.1. workload onboarding automation - the scope for RM is to describe support only but leave the details to RA/RI;

The Cloud Infrastructure workload onboarding process describes activities needed for the integration of tenants' workloads into the Cloud Infrastructure environment. Typically, this business process consists of the following key phases:

  1.  Tenant Engagement and Workload Evaluation:
    1.  In this phase the request from the tenant to host a workload on the Cloud Infrastructure platform is assessed and a decision made on whether to proceed with the hosting request.
    2. This phase may also involve the tenant accessing a pre-staging environment to perform their own evaluation and/or pre-staging activities in preparation for later onboarding phases.
  2. Workload Packaging:
    1.  The main outcome of this phase is to produce the workload deployable image and  the deployment manifests  (like TOSCA blueprints or HEAT templates or Helm charts) that will define the Cloud Infrastructure service attributes for the workload. 
    2. The workload packaging can be performed by the tenant, through self-service capabilities or by the Cloud Infrastructure Operations team.
  3. Workload Validation and Certification:
    1. In this phase the workload is deployed and tested to validate it against the service design and other Operator specific acceptance criteria, as required.
    2. Workload validation and certification should be automated using CI/CD toolsets / pipelines and Test as a Service (TaaS) capabilities.
  4. Publish Workload:
    1. After the workload is certified the final onboarding process phase is for it to be published to the Cloud Infrastructure  production catalogue from where it can be instantiated on the Cloud Infrastructure platform by the tenant.

All phases described above can be automated using technology specific toolsets and procedures.  Hence, details of such automation are left for the technology specific Reference Architecture and Reference Implementation specifications.


9.5.2.2. RM will state the requirements including for CI/CD for ensuring software security scans, image integrity checks, OS version checks, etc. prior to deployment -

  • the tenant processes for application LCM (such as updates) are out of scope
RefDescriptionComments/Notes
cicd.wf.00nThe CICD pipeline must support deployment on any cloud.

CICD pipelines automate CICD practices into repeatable workflows for integrating code and configurations into builds, testing builds including validation against design and operator specific criteria, and delivery of the product onto a runtime environment.

Example of an open-source cloud native CICD framework is the Tekton project (https://tekton.dev/)


The CI pipeline must ingest vendor (or developer) provided workload images and deployment manifests into the Cloud repository.Example of an open-source cloud native Cloud Repository is the CNCF Harbor product (https://goharbor.io/).

The CI pipeline must support build and packaging of workload images and deployment manifests from source code and configuration files.

The CI pipeline must scan images and manifests to validate for compliance with security requirements.  Examples of such security requirements include only ingesting images, source code, configuration files, etc. only form trusted sources.

The CI pipeline must scan images and manifests to validate for compliance with design and coding best practices.

The CI pipeline must promote validated images and manifests to be deployable.

The CICD pipelines must use event-driven task automation

The CI/CD pipelines should avoid scheduling tasks

The CD pipeline must verify and validate the tenant request

The CD pipeline must request the creation of the necessary cloud infrastructure resources

The CD pipeline must be able to deploy into Development, Test and Production environments

The CD pipeline must be able to automatically promote workloads from Development to Test and Production environments









9.5.3 Tenant creation automation

9.5.3.1. requirements for enterprise processes prior to tenant creation on the platform

9.5.3.2. tenant networking automation





  • No labels