From b86f1005a2d9850ea369be95523fe744e0665e57 Mon Sep 17 00:00:00 2001 From: chao zheng Date: Wed, 10 Mar 2021 17:33:45 -0800 Subject: [PATCH] add glossary --- docs/proposals/00_openyurt-glossary.md | 24 +-- .../20210310-edge-device-management.md | 169 ------------------ 2 files changed, 8 insertions(+), 185 deletions(-) delete mode 100644 docs/proposals/20210310-edge-device-management.md diff --git a/docs/proposals/00_openyurt-glossary.md b/docs/proposals/00_openyurt-glossary.md index 37225008685..4f2d684de50 100644 --- a/docs/proposals/00_openyurt-glossary.md +++ b/docs/proposals/00_openyurt-glossary.md @@ -9,14 +9,14 @@ This document lists terms for the OpenYurt implementation. ### CloudNode -The node that are located on the cloud. The control-plane and other cluster management components are usually running on the CloudNode. +The node that runs on the cloud. The control-plane and other cluster management components are usually running on the CloudNode. # E --- ### EdgeNode -The node that are accessible to the edge device. The EdgeNode are usually located in sub-optimal network environment and may be disconnected to the cloud node at any time. +The node that is accessible to the edge device. The EdgeNodes are usually located in a sub-optimal network environment. They may be disconnected from the cloud node at any time. ### End User @@ -27,22 +27,14 @@ Represents a user of the OpenYurt cluster. ### NodePool -A CRD that represents a pool of edge nodes in the same network region. - -### NodePool Controller - -The controller of the NodePool CRD, which reconciles the actual status with the desired state of the NodePool. +The CRD represents a pool of edge nodes in the same network region. # U --- ### UnitedDeployment -TODO - -### UnitedDeployment Controller - -TODO +The CRD defines the way of deploying homogeneous workloads with different versions/configurations by NodePools. # Y --- @@ -57,16 +49,16 @@ The local cache running on each EdgeNode, which periodically synchronizes the cl ### YurtTunnel -The network tunnel that helps CloudNodes to send http requests to EdgeNodes located in an isolated network. +The network tunnel helps CloudNodes to send HTTP requests to EdgeNodes located in an isolated network. ### YurtTunnel Server -The server of the YurtTunnel that run on each CloudNode and redirect http requests to corresponding agents. +The server of the YurtTunnel runs on each CloudNode and redirects HTTP requests to corresponding agents. ### YurtTunnel Agent -The agent of the YurtTunnel that run on each EdgeNode, receive requests from the YurtTunnel Server and send requests to destination hosts. +The agent of the YurtTunnel that runs on each EdgeNode receives requests from the YurtTunnel Server and sends requests to destination hosts. ### YurtAppManager -The controller manager that includes the NodePool Controller and the UnitedDeployment Controller. +The controller manager includes the NodePool Controller and the UnitedDeployment Controller. diff --git a/docs/proposals/20210310-edge-device-management.md b/docs/proposals/20210310-edge-device-management.md deleted file mode 100644 index c90b2d3bc3e..00000000000 --- a/docs/proposals/20210310-edge-device-management.md +++ /dev/null @@ -1,169 +0,0 @@ ---- -title: Edge Device Management -authors: - - "@charleszheng44" -reviewers: - - "@yixingjia" - - "@Fei-Guo" - - "@rambohe-ch" - - "@kadisi" - - "@huangyuqi" - - "@Walnux" -creation-date: 2021-03-10 -last-updated: 2021-03-10 -status: provisional ---- - -# Edge Device Management using EdgeX Foundry - -## Table of Contents - -A table of contents is helpful for quickly jumping to sections of a proposal and for highlighting -any additional information provided beyond the standard proposal template. -[Tools for generating](https://github.com/ekalinin/github-markdown-toc) a table of contents from markdown are available. - -- [Title](#title) - - [Table of Contents](#table-of-contents) - - [Glossary](#glossary) - - [Summary](#summary) - - [Motivation](#motivation) - - [Goals](#goals) - - [Non-Goals/Future Work](#non-goalsfuture-work) - - [Proposal](#proposal) - - [User Stories](#user-stories) - - [Story 1](#story-1) - - [Story 2](#story-2) - - [Requirements (Optional)](#requirements-optional) - - [Functional Requirements](#functional-requirements) - - [FR1](#fr1) - - [FR2](#fr2) - - [Non-Functional Requirements](#non-functional-requirements) - - [NFR1](#nfr1) - - [NFR2](#nfr2) - - [Implementation Details/Notes/Constraints](#implementation-detailsnotesconstraints) - - [Risks and Mitigations](#risks-and-mitigations) - - [Alternatives](#alternatives) - - [Upgrade Strategy](#upgrade-strategy) - - [Additional Details](#additional-details) - - [Test Plan [optional]](#test-plan-optional) - - [Implementation History](#implementation-history) - -## Glossary - -Refer to the [Cluster API Book Glossary](https://cluster-api.sigs.k8s.io/reference/glossary.html). - -If this proposal adds new terms, or defines some, make the changes to the book's glossary when in PR stage. - -## Summary - -The `Summary` section is incredibly important for producing high quality user-focused documentation such as release notes or a development roadmap. -It should be possible to collect this information before implementation begins in order to avoid requiring implementors to split their attention between writing release notes and implementing the feature itself. - -A good summary is probably at least a paragraph in length. - -## Motivation - -This section is for explicitly listing the motivation, goals and non-goals of this proposal. - -- Describe why the change is important and the benefits to users. -- The motivation section can optionally provide links to [experience reports](https://github.com/golang/go/wiki/ExperienceReports) -to demonstrate the interest in a proposal within the wider Kubernetes community. - -### Goals - -- List the specific high-level goals of the proposal. -- How will we know that this has succeeded? - -### Non-Goals/Future Work - -- What high-levels are out of scope for this proposal? -- Listing non-goals helps to focus discussion and make progress. - -## Proposal - -This is where we get down to the nitty gritty of what the proposal actually is. - -- What is the plan for implementing this feature? -- What data model changes, additions, or removals are required? -- Provide a scenario, or example. -- Use diagrams to communicate concepts, flows of execution, and states. - -[PlantUML](http://plantuml.com) is the preferred tool to generate diagrams, -place your `.plantuml` files under `images/` and run `make diagrams` from the docs folder. - -### User Stories - -- Detail the things that people will be able to do if this proposal is implemented. -- Include as much detail as possible so that people can understand the "how" of the system. -- The goal here is to make this feel real for users without getting bogged down. - -#### Story 1 - -#### Story 2 - -### Requirements (Optional) - -Some authors may wish to use requirements in addition to user stories. -Technical requirements should be derived from user stories, and provide a trace from -use case to design, implementation and test case. Requirements can be prioritised -using the MoSCoW (MUST, SHOULD, COULD, WON'T) criteria. - -The difference between goals and requirements is that between an executive summary -and the body of a document. Each requirement should be in support of a goal, -but narrowly scoped in a way that is verifiable or ideally - testable. - -#### Functional Requirements - -Functional requirements are the properties that this design should include. - -##### FR1 - -##### FR2 - -#### Non-Functional Requirements - -Non-functional requirements are user expectations of the solution. Include -considerations for performance, reliability and security. - -##### NFR1 - -##### NFR2 - -### Implementation Details/Notes/Constraints - -- What are some important details that didn't come across above. -- What are the caveats to the implementation? -- Go in to as much detail as necessary here. -- Talk about core concepts and how they releate. - -### Risks and Mitigations - -- What are the risks of this proposal and how do we mitigate? Think broadly. -- How will UX be reviewed and by whom? -- How will security be reviewed and by whom? -- Consider including folks that also work outside the SIG or subproject. - -## Alternatives - -The `Alternatives` section is used to highlight and record other possible approaches to delivering the value proposed by a proposal. - -## Upgrade Strategy - -If applicable, how will the component be upgraded? Make sure this is in the test plan. - -Consider the following in developing an upgrade strategy for this enhancement: -- What changes (in invocations, configurations, API use, etc.) is an existing cluster required to make on upgrade in order to keep previous behavior? -- What changes (in invocations, configurations, API use, etc.) is an existing cluster required to make on upgrade in order to make use of the enhancement? - -## Additional Details - -### Test Plan [optional] - -## Implementation History - -- [ ] MM/DD/YYYY: Proposed idea in an issue or [community meeting] -- [ ] MM/DD/YYYY: Compile a Google Doc following the CAEP template (link here) -- [ ] MM/DD/YYYY: First round of feedback from community -- [ ] MM/DD/YYYY: Present proposal at a [community meeting] -- [ ] MM/DD/YYYY: Open proposal PR -