Auto-sync: wiki-ingest 3 sources (2026-04-16)
This commit is contained in:
@@ -11,7 +11,7 @@ tags:
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 15_ Working with Renovatebot.mp4"
|
||||
audio-source: ""
|
||||
status: summarized
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 15 Working with Renovatebot
|
||||
@@ -20,7 +20,7 @@ status: summarized
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
**Status:** ✅ 已完成（Gemini 摘要）
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -1,17 +1,17 @@
|
||||
---
|
||||
title: "CTP Topic 3 Deploy and maintain infrastructure"
|
||||
title: CTP Topic 3 Deploy and maintain infrastructure
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/06_CI_CD_GitOps"
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- IaC
|
||||
- Deployment
|
||||
- CI/CD
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 3_ Deploy and maintain infrastructure.mp4"
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 3_ Deploy and maintain infrastructure.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 3 Deploy and maintain infrastructure
|
||||
@@ -26,7 +26,20 @@ status: raw
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
> ## Deploying and Maintaining Infrastructure
|
||||
|
||||
The session focuses on deploying and maintaining infrastructure, clarifying Terraform, Terragrunt, modules, and service catalogs within the landing zone context. It emphasizes the structure of Git repositories and how Terraform and Terragrunt files interact.
|
||||
|
||||
When a landing zone is provisioned, product teams are grouped, each having a landing zone and workload accounts. A product team, such as DevTools, deploys infrastructure to meet specific requirements across accounts like Artifactory and Active Directory. This involves multiple Git repositories, including the core landing zone repository, Terraform service catalog, and a product team service catalog.
|
||||
|
||||
A service module consists of a main.tf file that references other repositories, grouping modules to fulfill a business requirement, such as an active directory or DNS service. *When deploying infrastructure, Terragrunt HCL files are used to reference these services, targeting specific versions rather than the master branch.* These files may include dependencies to reference values across services, favoring dependencies over reading state files.
|
||||
|
||||
When referencing modules within the current codebase, a relative path can be used, but the preferred approach is to have a dedicated service catalog with a modules directory. This allows for independent release cycles and better maintainability. Modules can be used within one account, reused within a product team (in the product team service catalog), or used across product teams (in the Terraform service catalog).
|
||||
|
||||
*A service is a business requirement, while a regular module is a technical requirement.* A service deploys a set of multiple modules, abstracting them. The higher up the chain, the less configuration options are available, similar to an object-oriented approach.
|
||||
|
||||
Terragrunt fetches all references before running, using a Terragrunt cache directory to store cloned repositories. Terragrunt can be run at the directory level, considering dependencies, but applying without verification is discouraged. Jenkins jobs can be enhanced for debugging, and documentation should be comprehensive, referencing Gruntwork as a model. Versioning modules should follow major, minor, and patch conventions.
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: CTP Topic 3 Deploy and maintain infrastructure
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- IaC
|
||||
- Deployment
|
||||
- CI/CD
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 3_ Deploy and maintain infrastructure.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 3 Deploy and maintain infrastructure
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 3_ Deploy and maintain infrastructure.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
@@ -1,8 +1,8 @@
|
||||
---
|
||||
title: "CTP Topic 32 Using Atlantis CICD for infrastructure deployments"
|
||||
title: CTP Topic 32 Using Atlantis CICD for infrastructure deployments
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/06_CI_CD_GitOps"
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- Atlantis
|
||||
- CI/CD
|
||||
@@ -10,9 +10,9 @@ tags:
|
||||
- Terraform
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 32_ Using Atlantis CICD for infrastructure deployments.mp4"
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 32_ Using Atlantis CICD for infrastructure deployments.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 32 Using Atlantis CICD for infrastructure deployments
|
||||
@@ -27,7 +27,16 @@ status: raw
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
> ## Atlantis CICD: Replacing Jenkins for Infrastructure Deployments
|
||||
|
||||
The presentation introduces Atlantis, a new automation tool designed for teams to collaborate on Terraform code, aiming to replace Jenkins for infrastructure deployments. Atlantis addresses the speed and complexity issues of the current pipeline. *The current pipeline is practically very slow* due to significant initialization time, multiple code cloning, sequential testing, and ECS deployer provisioning. The existing pipeline's complexity stems from continuous tweaking to integrate more features and cover edge cases, leading to fragility and drift.
|
||||
|
||||
Atlantis is standalone, self-hosted, free, and open source, with an active community. It offers a better collaboration model, simplified networking, and cost savings by removing the need for numerous VPC endpoints. Atlantis applies changes before merging, ensuring code in sync with infrastructure. The workflow is simplified, allowing direct communication with Atlantis from GitHub via comments on pull requests, eliminating the need for separate accounts and integrations.
|
||||
|
||||
Atlantis is hosted on a single EC2 instance in each landing zone's shared account, notified by GitHub Enterprise using webhooks. It uses service accounts to interact with GitHub, post comments, do merges, and close PRs. Cross-account access is managed through deployed key roles in each account, utilized for both simple and cross-account module deployments. User management is controlled on GitHub, and build logs are stored in comments for auditing. Atlantis enforces apply requirements, such as mergeability and peer approval, before applying changes. Auto-merge is enabled for automatic merging upon successful application. Parallel builds are supported, running plan and apply commands concurrently for multiple modules.
|
||||
|
||||
Atlantis locking prevents conflicts by locking the directory of each module when a plan is run, until the pull request is merged, closed, or the plan is discarded. *When a plan is run, the directory of each module is locked until the pull request that is that has this folder locked is merged or closed, or the plan is manually discarded.* Modules and data file dependencies can be declared to trigger plans when dependencies change. Documentation, troubleshooting guides, and a list of migrated repositories are available to assist users.
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: CTP Topic 32 Using Atlantis CICD for infrastructure deployments
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- Atlantis
|
||||
- CI/CD
|
||||
- IaC
|
||||
- Terraform
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 32_ Using Atlantis CICD for infrastructure deployments.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 32 Using Atlantis CICD for infrastructure deployments
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 32_ Using Atlantis CICD for infrastructure deployments.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
@@ -1,17 +1,17 @@
|
||||
---
|
||||
title: "CTP Topic 33 An introduction to GitOps"
|
||||
title: CTP Topic 33 An introduction to GitOps
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/06_CI_CD_GitOps"
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- GitOps
|
||||
- CI/CD
|
||||
- Git
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 33_ An introduction to GitOps.mp4"
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 33_ An introduction to GitOps.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 33 An introduction to GitOps
|
||||
@@ -26,7 +26,28 @@ status: raw
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
> Victor Etkin presents an introduction to GitOps, explaining how it complements DevOps. GitOps applies software development principles to deployment processes, potentially resolving challenges like failed deployments and configuration inconsistencies.
|
||||
|
||||
Key benefits of GitOps:
|
||||
* Increased developer productivity using familiar tools.
|
||||
* Minimized failed deployments with easy rollback capabilities.
|
||||
* Faster feature releases.
|
||||
* Real-time auditing and improved security through Git's features.
|
||||
|
||||
GitOps uses Git workflows, CD pipelines, and infrastructure as code. Observability is crucial for ensuring the desired and actual states align. GitOps is often used with Kubernetes but can be applied elsewhere.
|
||||
|
||||
The four principles of GitOps: declarative configuration, version control, CD process separation, and incremental infrastructure implementation. Git serves as the primary tool, storing deployment infrastructure and application configurations. A GitOps controller reconciles the Git state with the actual system state. *The only tool a developer needs to know is Git.*
|
||||
|
||||
The goal is full automation, with code changes deployed safely in minutes. CI and CD should be decoupled. A basic GitOps workflow for Kubernetes involves developers committing code, creating container images, storing deployment configurations in Git, monitoring changes via a GitOps agent, and rolling out images to environments.
|
||||
|
||||
CI focuses on building and analyzing code, while CD focuses on deploying binaries. Separating CI and CD enhances security. CD tools can run inside container platforms like Kubernetes for added security.
|
||||
|
||||
GitOps enables on-demand incremental deployment, benefiting microservices architectures. CD processes require an IDEMPOTENT platform like Kubernetes. *An IDEMPOTENT operation is one that can be applied multiple times without changing the result beyond the initial application.*
|
||||
|
||||
CD processes can be implemented using push or pull models. The pull model, which monitors both Git and the target system, is recommended for GitOps. Human intervention is still needed for issues like resource failures. GitOps simplifies operations, allowing developers to focus on more valuable activities.
|
||||
|
||||
GitOps is a logical evolution of DevOps, simplifying adoption and enhancing portability. Git commit logs become audit trails, streamlining compliance.
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: CTP Topic 33 An introduction to GitOps
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- GitOps
|
||||
- CI/CD
|
||||
- Git
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 33_ An introduction to GitOps.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 33 An introduction to GitOps
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 33_ An introduction to GitOps.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
@@ -1,17 +1,17 @@
|
||||
---
|
||||
title: "CTP Topic 56 Automated infrastructure testing"
|
||||
title: CTP Topic 56 Automated infrastructure testing
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/06_CI_CD_GitOps"
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- Testing
|
||||
- IaC
|
||||
- Automation
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 56_ Automated infrastructure testing.mp4"
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 56_ Automated infrastructure testing.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# CTP Topic 56 Automated infrastructure testing
|
||||
@@ -26,7 +26,22 @@ status: raw
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
> ## Automated Infrastructure Testing
|
||||
|
||||
Mark Francis discusses automated infrastructure testing, emphasizing its value and practical application for engineers. The session aims to provide actionable insights for immediate use.
|
||||
|
||||
Key points covered:
|
||||
|
||||
* Integration tests are crucial for validating deployed infrastructure functionality, going beyond syntax checks to ensure the actual deployment matches expectations.
|
||||
* *I think the bottom quote, just I think let's leave the repetitive things for the computers to do and use our brains for the complex human things.*
|
||||
* TerraTest, a Golang library, automates the apply-test-destroy cycle, streamlining testing processes.
|
||||
* Test-driven development (TDD) involves writing tests before implementing features, ensuring focused development and building a comprehensive test suite.
|
||||
* A new workflow is proposed, integrating test writing as a primary step and removing manual validation, aiming for automated validation suites and increased confidence in deployments.
|
||||
|
||||
The presentation introduces TerraTest and its role in automating infrastructure testing. It highlights a repository with basic examples, demonstrating how TerraTest applies Terraform configurations, validates outputs, and destroys resources. The benefits of this approach include automating manual checks, testing complex modules, and increasing confidence in code changes.
|
||||
|
||||
The discussion also covers the challenges of infrastructure testing, such as time investment and the maturity of testing tools. However, it argues that the long-term benefits, including reduced bugs and increased confidence, outweigh the initial difficulties. The session concludes with a proposed workflow that integrates testing as a core component of infrastructure development, emphasizing the importance of treating tests as first-class citizens. *I'm just extending the value of putting stuff as code.*
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: CTP Topic 56 Automated infrastructure testing
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: DevOps & SRE/06_CI_CD_GitOps
|
||||
tags:
|
||||
- Testing
|
||||
- IaC
|
||||
- Automation
|
||||
- CTP
|
||||
date-added: 2026-04-14
|
||||
video-source: nas:///volume2/work/Public Cloud Learning Sessions/CTP _ Topic 56_ Automated infrastructure testing.mp4
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# CTP Topic 56 Automated infrastructure testing
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/CTP _ Topic 56_ Automated infrastructure testing.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
@@ -10,7 +10,7 @@ tags:
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416_160113-Meeting Recording.mp4"
|
||||
audio-source: ""
|
||||
status: raw
|
||||
status: summarized (Gemini 摘要)
|
||||
---
|
||||
|
||||
# Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416 160113-Meeting Recording
|
||||
@@ -23,28 +23,16 @@ status: raw
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
## Oli Workflow and Demand Process
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
The session covers the Oli workflow process for hyperscaler spend approval, demand management, and request fulfillment. The current mandate requires written approval from MUI or Shannon for any hyperscaler spend, regardless of the amount, for engineering lab space or commercial workload space. The Oli workflow process is being transitioned to the FinOps team under Tom Bice, who are working on integrating it into SMACs.
|
||||
|
||||
---
|
||||
The base instructions for lab requests, commercial requests, and the general OLLI form guide are available in Confluence. *If justification details are not provided, requests are subject to immediate rejection.* The workflow process includes reviews by the presenter, the requester's manager, M5, lab services director, infrastructure M5, cloud services infrastructure, cloud services, and finally, approval by Shannon or Muwe. The requester is responsible for advocating for their workflow to be approved.
|
||||
|
||||
## 关键概念
|
||||
The request form pulls employee name and manager information from the corporate AD. The VP M5 level within their reporting structure requires validation that the workflow is properly requested, legitimate, raised for the right project and resourcing, and is budgeted. The organization is selected from a dropdown. Cost center information can be found in Talent Central. The workflow is geared towards engineering, with requests for budgetary review every six months. A critical field is whether the request is a budget increase or a new lab space. The cloud provider is selected, and if it's a budget increase, the existing account name is required. The project type is selected from a dropdown list. The region requested must be on the active regions list. Justification questions are submitted in the comment section.
|
||||
|
||||
-
|
||||
The proposed workflow involves three steps: feasibility validation by FinOps, technical feasibility validation by cloud services, and budget availability validation by the FPNA team. The workflow then goes through the requester's leadership, manager, M5 VP level, and finally, the engineering chief product officers VP. The Oli system allows users to view their assignments and generate in-flight CSV reports. The reports provide information on workflow statuses, requesters, cost centers, monthly costs, and the current step in the process.
|
||||
|
||||
---
|
||||
The ITIL framework divides business processes into service strategy, design, transition, operation, and improvement phases. The approval process is the first stage of request fulfillment. A master catalog of combined cloud products is being developed. Demand management is necessary to balance requests against available capacity. The OpenText way of fulfilling cloud requests is a request submission process.
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
The end-to-end process includes the approval stage, demand management, and definition work. Business units can submit requests directly into Octane or through a Qixi interface. The goal is to simplify the process for business units to identify and request services from the catalog. The master catalog of products and services will be embedded within SMACS. The Enterprise Iton project for the standard OT SMACS tenant is on hold. The ADM and ITOM Demand Planning Meetings capture what is needed, how many are required, and the release they are required in. The goal is for business units to self-select what they need 80% of the time. *Machines should do what machines can do, enabling an automated fulfillment process.*
|
||||
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
title: "Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416 160113-Meeting Recording"
|
||||
type: cloud-learning
|
||||
source-type: video
|
||||
category: "DevOps & SRE/06_CI_CD_GitOps"
|
||||
tags:
|
||||
- Workflow
|
||||
- Demand-Process
|
||||
- Agile
|
||||
date-added: 2026-04-14
|
||||
video-source: "nas:///volume2/work/Public Cloud Learning Sessions/Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416_160113-Meeting Recording.mp4"
|
||||
audio-source: ""
|
||||
status: raw
|
||||
---
|
||||
|
||||
# Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416 160113-Meeting Recording
|
||||
|
||||
**Source:** NAS `/volume2/work/Public Cloud Learning Sessions/Public Cloud Learning Sessions- Ollie Workflow and The Demand Process - 20240416_160113-Meeting Recording.mp4`
|
||||
|
||||
**Type:** VIDEO | **Category:** 06_CI_CD_GitOps
|
||||
|
||||
**Status:** 🟡 Awaiting Whisper transcription → Summary
|
||||
|
||||
---
|
||||
|
||||
## 摘要
|
||||
|
||||
> 待转录后由 LLM 生成
|
||||
|
||||
---
|
||||
|
||||
## 关键概念
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 行动项
|
||||
|
||||
-
|
||||
|
||||
---
|
||||
|
||||
## 相关视频
|
||||
|
||||
> 配对视频笔记链接（生成后填入）
|
||||
|
||||
---
|
||||
|
||||
*最后更新: 2026-04-14*
|
||||
Reference in New Issue
Block a user