### Start Container Steps

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20220725-pod-recovery-efficiency-proposal.md

Details the procedure for starting a container within a pod. This involves pulling the container image, creating the container, starting it, and executing any post-start hooks.

```text
Step 1: pull the image.
Step 2: create the container.
Step 3: start the container.
Step 4: execute the post start hook.
```

--------------------------------

### Run Pod Sandbox Steps

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20220725-pod-recovery-efficiency-proposal.md

Describes the detailed steps involved in creating a pod sandbox by the container runtime. This process includes image pulling, container creation, checkpointing, starting the sandbox, and network setup.

```text
Step 1: Pull the image for the sandbox.
Step 2: Create the sandbox container.
Step 3: Create Sandbox Checkpoint.
Step 4: Start the sandbox container.
Step 5: Setup networking for the sandbox.
```

--------------------------------

### Kubelet Start Invocation Chain

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20220725-pod-recovery-efficiency-proposal.md

This is a call graph illustrating the sequence of function calls from the Kubelet's main entry point to the initialization of its core components and the start of the YurtHub static pod. It helps in understanding the flow and identifying potential bottlenecks.

```go
main                                                                             // cmd/kubelet/kubelet.go
 |--NewKubeletCommand                                                            // cmd/kubelet/app/server.go
   |--Run                                                                        // cmd/kubelet/app/server.go
      |--initForOS                                                               // cmd/kubelet/app/server.go
      |--run                                                                     // cmd/kubelet/app/server.go
        |--initConfigz                                                           // cmd/kubelet/app/server.go
        |--BuildAuth
        |--NodeAllocatableRoot
        |--cadvisor.NewImageFsInfoProvider
        |--NewContainerManager
        |--ApplyOOMScoreAdj
        |--PreInitRuntimeService
        |--RunKubelet                                                            // cmd/kubelet/app/server.go
        | |--k = createAndInitKubelet                                            // cmd/kubelet/app/server.go
        | |  |--NewMainKubelet
        | |  |  |--watch k8s Service
        | |  |  |--watch k8s Node
        | |  |  |--klet := &Kubelet{}
        | |  |  |--init klet fields
        | |  | 
        | |  |--k.BirthCry()
        | |  |--k.StartGarbageCollection()
        | | 
        | |--startKubelet(k)                                                     // cmd/kubelet/app/server.go
        |    |--go k.Run()                                                       // -> pkg/kubelet/kubelet.go
        |    |  |--go cloudResourceSyncManager.Run()
        |    |  |--initializeModules
        |    |  |--go volumeManager.Run()
        |    |  |--go nodeLeaseController.Run()
        |    |  |--initNetworkUtil() // setup iptables
        |    |  |--go Until(PerformPodKillingWork, 1*time.Second, neverStop)
        |    |  |--statusManager.Start()
        |    |  |--runtimeClassManager.Start
        |    |  |--pleg.Start()
        |    |  |--syncLoop(updates, kl)                                         // pkg/kubelet/kubelet.go
        |    | 
        |    |--k.ListenAndServe
        |
        |--go http.ListenAndServe(healthz)

```

--------------------------------

### Example Cross-Edge Routing Rules

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20211123-enhancement-of-cluster-networking.md

Demonstrates the routing rules and table configuration for cross-nodepool communication using a custom 'cross_edge_table'. This setup prioritizes specific traffic to a dedicated routing table.

```bash
ip rule
0:	from all lookup local
# Set up route policy for pod CIDR of nodepoolB to use cross_edge_table.
32764:	from all to 10.244.2.0/24 lookup cross_edge_table
32765:	from all to 10.244.3.0/24 lookup cross_edge_table
32766:	from all lookup main
32767:	from all lookup default
ip r list table cross_edge_table
# 10.0.20.13 is the private IP of the local gateway node.
# We need to set a smaller MTU for IPsec traffic, the concrete number is yet to be determined.
default via 10.0.20.13 dev eth0 mtu 1400
```

--------------------------------

### Kubeadm Discovery Configuration

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20221108-yurtadm-join-refactoring.md

Example configuration for node discovery, including cluster details and certificate authority data.

```yaml
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM2VENDQWRHZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQ0FYRFRJeU1UQXlOekUxTURBeU1sb1lEekl4TWpJeE1EQXpNVFV3TURJeVdqQVZNUk13RVFZRApWUVFERXdwcmRXSmxjbTVsZEdWek1JSUJJakFOQmdrcWhraUc5dzBCQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBCnlFWlpSQUhmdWRIL05nZElKaXJnNW1IcllzT093UHdhWDR6dFJaRG4zdFB4ZTYxY0hBdkhGT0h3M0xqKzFRSmMKWWE4OGZ1NFF6cUh2TnBGeTlZeTE3YVo3c1JuQUhTemcvSkVvcjlxQlVJakN0WlUxMTN5dlRMSDZRZnZBTWl4eQpoTkdIMWRMWnV5SnY5OUUweklMUUNrWGN5SzF6a1ZFeWZKcmZaS2lTalYwQndteWl1QjUwcktmc0pZc21rS2ZICnp0SEtzWmFPaElwcmd3NG02SmttSUZKQjBFTlBhaktKNjRLWng3bXUzOVIySlJNc3A0WXpieWJTQnNacnNGcUIKbnZhTHRlVk9QcHVyK1hYUkptUUFvbkc3Zkl5QU9GY21PTovekNHbzhpb04xd2NFVU1paWhFaVN6UzVUM2wwQgpwUUdOV0JGVUFyMmZ0NTRaV2syUnd3SURBUUFCbzBJd1FEQU9CZ05WSFE4QkFmOEVCQU1DQXFRd0R3WURWUjBUCkFRSC9CQVV3QXdFQi96QWRCZ05WSFE0RUZnUVU2Z0RhTUZEaURQaU90eGcxSktxSk1YZkRXV1l3RFFZSktvWkkKaHZjTkFRRUxCUUFEZ2dFQkFHNzAvU3hRTlFZTjJKUC9paUllN2kxdXAyT1VZUXlXYjlqMVF6dnlkNHdRTElMTQpvUzZHZVplblBYRlRnemVFZE5uaUsxcEV6b0JJMUNOa0N4S01QVUx3RWJzRlVDb1M3T2JVTWNoQkw2MG0xOC9GCnFGRG04QVFqRUdXTllOeHVuRXlFVUpUQXBibStndTdCYlIvZzR2Uk5UTWZ3NzFiSzlGci9iUmdBMHZEVEdhK0QKU29RekxKZms2UTRKQW41MHFGRDlCdVViV3ExSkY4eWxqc1BiMnlqWlVqSkhaWmd6cTRJL2FaYjZ5TjJ2MTAxTQpiSHRRR2crUDZFb05rWWZDR25zRGZNYnJhYnZpK3VyTUNNcmZzLzhCQnlUU3c3SjB6UEdkbTQ5b1l1SXE1YnVqCjdJVmR1eE9JempnU2hqSm91bjdpWWpFQXRnR3U3REgzYVd4Qm9tZz0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
    server: https://apiserver.cluster.local:6443
name: ""
contexts: null
current-context: ""
kind: Config
preferences: {}
users: null
```

--------------------------------

### Configure Yurt-Manager with Yurtnodeconversion Controller

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20260303-label-driven-yurthub.md

This command demonstrates how to start the yurt-manager with the yurtnodeconversion controller enabled and specifies the YurtHub version.

```bash
yurt-manager \
  --controllers=*,yurtnodeconversion \
  --yurthub-version=v1.6.1
```

--------------------------------

### Pod Structure Example in Go

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20210301-enhancement_of_YurtHub_caching_ability.md

Illustrates the Go struct definition for a Kubernetes Pod, which is a type managed by SerializerManager.

```go
type Pod struct {
   metav1.TypeMeta `json:",inline"`
   metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"
   Spec PodSpec `json:"spec,omitempty" protobuf:"bytes,2,opt,name=spec"
   Status PodStatus `json:"status,omitempty" protobuf:"bytes,3,opt,name=status"
}
```

--------------------------------

### Edge NodePool Example

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20231121-high-availability-of-edge-services.md

An example of an Edge NodePool configuration specifying IP address ranges for load balancing.

```yaml
apiVersion: apps.openyurt.io/v1beta1
kind: NodePool
metadata:
  name: beijing
spec:
  type: Edge
  addresses:
    - 2002:2:2::1-2002:2:2::100
    - 172.20.0.100-172.20.0.200
```

--------------------------------

### Example kubectl patch command

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20230706-yurtappoverrider.md

This command demonstrates how to use kubectl to patch a deployment, specifically replacing the container image. It utilizes JSON patch operations.

```shell
kubectl patch deployment xxx --type='json' --patch='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"tomcat"}]'
```

--------------------------------

### Example Main Routing Table

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20211123-enhancement-of-cluster-networking.md

Illustrates a typical main routing table on a node in an OpenYurt cluster using flannel. This shows existing routes for local pods and CNI-managed networks.

```bash
default via 10.0.20.1 dev eth0
10.0.20.0/22 dev eth0 proto kernel scope link src 10.0.20.13
10.244.1.0/24 dev cni0 proto kernel scope link src 10.244.1.1
10.244.0.0/24 via 10.244.0.0 dev flannel.1 onlink
10.244.2.0/24 via 10.244.2.0 dev flannel.1 onlink
10.244.3.0/24 via 10.244.3.0 dev flannel.1 onlink
169.254.0.0/16 dev eth0 scope link metric 1002
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
```

--------------------------------

### Install Yurt-Manager using Helm

Source: https://github.com/openyurtio/openyurt/blob/master/cmd/yurt-manager/README.md

Installs or upgrades the yurt-manager using Helm. Ensure you specify the correct image registry and tag using the --set flag.

```shell
# cd $GOPATH/src/github.com/openyurtio/openyurt
# helm uninstall openyurt
# helm install openyurt ./openyurt --set yurtManager.image.registry=edgetest-registry.cn-zhangjiakou.cr.aliyuncs.com --set yurtManager.image.tag=v1.2.0-52ef527
```

--------------------------------

### YurtAppOverrider for Customizing hostPath

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20230706-yurtappoverrider.md

Applies different hostPath configurations for volumes in different regions. This example shows how to add or replace volume configurations for Beijing and Hangzhou.

```yaml
apiVersion: apps.openyurt.io/v1alpha1
kind: YurtAppOverrider
metadata:
  namespace: default
  name: demo1
subject:
  apiVersion: apps.openyurt.io/v1alpha1
  kind: YurtAppSet
  nameSpace: default
  name: yurtappset-demo
entries:
- pools:
    beijing
  items:
  - image:
      containerName: nginx
      imageClaim: nginx:1.14.2
- pools:
    hangzhou
  patches:
  - operation: add
    path: /spec/template/spec/volumes/- 
    value:
      name: test-volume
      hostPath:
        path: /var/lib/docker
        type: Directory
  - operation: replace
    path: /spec/template/spec/containers/0/volumeMounts/- 
    value:
      name: shared-dir
      mountPath: /var/lib/docker
- pools:
    beijing
  patches:
  - operation: add
    path: /spec/template/spec/volumes/- 
    value:
      name: test-volume
      hostPath:
        path: /data/logs
        type: Directory
  - operation: replace
    path: /spec/template/spec/containers/0/volumeMounts/- 
    value:
      name: shared-dir
      mountPath: /data/logs
```

--------------------------------

### Traffic Calculation Example

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20241211-reuse-nodepool-list-watch-requests.md

Illustrates the potential network traffic generated during a DaemonSet upgrade in a cluster with 1000 nodes, assuming a specific EndpointSlice size. This calculation highlights the problem addressed by the proposal.

```plaintext
1000 (updates) * 1000 (nodes) * 50KB (size per update) = 50GB
```

--------------------------------

### Install Yurt-Manager via Helm

Source: https://context7.com/openyurtio/openyurt/llms.txt

Deploy Yurt-Manager using Helm, specifying namespace, image details, replica count, and controller configurations. Controllers can be selectively enabled or disabled.

```bash
# Install yurt-manager via Helm
helm install yurt-manager charts/yurt-manager \
  --namespace kube-system \
  --set image.registry=openyurt \
  --set image.tag=v1.7.0 \
  --set replicaCount=1 \
  --set controllers="-nodelifecycle,*"   # Disable nodelifecycle, enable all others
  # --set controllers="nodepool,yurtappset,gateway"  # Enable only specific controllers
```

--------------------------------

### YurtAppOverrider for Gray Release

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20230706-yurtappoverrider.md

Specifies configurations for a gray release in a specific region, such as Hangzhou. This example demonstrates how to update the image for a 'demo' container.

```yaml
apiVersion: apps.openyurt.io/v1alpha1
kind: YurtAppOverrider
metadata:
  namespace: default
  name: demo1
subject:
  apiVersion: apps.openyurt.io/v1alpha1
  kind: YurtAppSet
  nameSpace: default
  name: yurtappset-demo
entries:
- pools:
    hangzhou
  items:
  - image:
      containerName: demo
      imageClaim: xxx:latest
```

--------------------------------

### Example PlatformAdmin CR with Multiple NodePools

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20240819-build-iot-system-configuration-isolation-on-nodepool.md

This is a sample PlatformAdmin Custom Resource (CR) demonstrating how to specify multiple nodepools ('hangzhou' and 'beijing') for a single PlatformAdmin instance.

```yaml
apiVersion: iot.openyurt.io/v1beta1
kind: PlatformAdmin
metadata:
    name: edgex-sample
spec:
    version: minnesota
    nodePools:
    - hangzhou
    - beijing
EOF
```

--------------------------------

### Manage Static Pods with yurtadm

Source: https://context7.com/openyurtio/openyurt/llms.txt

Commands for installing or uninstalling static pods, typically performed after an OpenYurt upgrade. Specify the directory containing the manifest files.

```bash
# Install/upgrade static pods (e.g., after an OpenYurt upgrade)
yurtadm staticpods install --manifest-dir /etc/kubernetes/manifests
yurtadm staticpods uninstall --manifest-dir /etc/kubernetes/manifests
```

--------------------------------

### Get or Create Service Account

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20240517-separate-yurtmanager-clients.md

Use this function to retrieve an existing ServiceAccount or create a new one if it doesn't exist. It also handles the creation of the namespace if it's not found, tolerating potential errors during namespace creation.

```go
func getOrCreateServiceAccount(cli client.Client, namespace, name string) (*v1.ServiceAccount, error) {
	sa := &v1.ServiceAccount{
		ObjectMeta: metav1.ObjectMeta{
			Name:      name,
			Namespace: namespace,
		},
	}
	err := cli.Get(context.TODO(), client.ObjectKey{Namespace: namespace, Name: name}, sa)
	if err == nil {
		return sa, nil
	}
	if !apierrors.IsNotFound(err) {
		return nil, err
	}

	// Create the namespace if we can't verify it exists.
	// Tolerate errors, since we don't know whether this component has namespace creation permissions.
	ns := &v1.Namespace{
		ObjectMeta: metav1.ObjectMeta{
			Name: namespace,
		},
	}
	if err := cli.Get(context.TODO(), client.ObjectKey{}, ns); apierrors.IsNotFound(err) {
		if err = cli.Create(context.TODO(), ns); err != nil && !apierrors.IsAlreadyExists(err) {
			klog.Warningf("create non-exist namespace %s failed:%v", namespace, err)
		}
	}

	// Create the service account
	err = cli.Create(context.TODO(), sa)
	if apierrors.IsAlreadyExists(err) {
		// If we're racing to init and someone else already created it, re-fetch
		err = cli.Get(context.TODO(), client.ObjectKey{Namespace: namespace, Name: name}, sa)
		return sa, err
	}
	return sa, err
}
```

--------------------------------

### EdgeX Hanoi Metadata Component Configuration

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20221109-edgex-auto-collector.md

Example of a metadata component configuration within the edgex-compose setup for the Hanoi release. It details container settings, dependencies, environment variables, and volume mounts.

```yaml
metadata:
    container_name: edgex-core-metadata
    depends_on:
    - consul
    - database
    - notifications
    - security-bootstrap-database
    - vault-worker
    environment:
      CLIENTS_COMMAND_HOST: edgex-core-command
      CLIENTS_COREDATA_HOST: edgex-core-data
      CLIENTS_DATA_HOST: edgex-core-data
      CLIENTS_METADATA_HOST: edgex-core-metadata
      CLIENTS_NOTIFICATIONS_HOST: edgex-support-notifications
      CLIENTS_RULESENGINE_HOST: edgex-kuiper
      CLIENTS_SCHEDULER_HOST: edgex-support-scheduler
      CLIENTS_VIRTUALDEVICE_HOST: edgex-device-virtual
      DATABASES_PRIMARY_HOST: edgex-redis
      EDGEX_SECURITY_SECRET_STORE: "true"
      NOTIFICATIONS_SENDER: edgex-core-metadata
      REGISTRY_HOST: edgex-core-consul
      SECRETSTORE_HOST: edgex-vault
      SECRETSTORE_ROOTCACERTPATH: /tmp/edgex/secrets/ca/ca.pem
      SECRETSTORE_SERVERNAME: edgex-vault
      SECRETSTORE_TOKENFILE: /tmp/edgex/secrets/edgex-core-metadata/secrets-token.json
      SERVICE_HOST: edgex-core-metadata
    hostname: edgex-core-metadata
    image: edgexfoundry/docker-core-metadata-go:1.3.1
    networks:
      edgex-network: {}
    ports:
    - 127.0.0.1:48081:48081/tcp
    read_only: true
    volumes:
    - /tmp/edgex/secrets/ca:/tmp/edgex/secrets/ca:ro,z
    - /tmp/edgex/secrets/edgex-core-metadata:/tmp/edgex/secrets/edgex-core-metadata:ro,z

```

--------------------------------

### Kubelet Sync Pod Steps

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20220725-pod-recovery-efficiency-proposal.md

Outlines the sequential steps performed by the Kubelet's syncPod method during pod synchronization. These steps cover pod status generation, admission, cgroup creation, and container runtime interaction.

```text
Step 1: Record pod worker start latency if being created
Step 2: Create v1.PodStatus object
Step 3: Generate PodStatus
Step 4: Executing the admission handlers and make pods having privalage
Step 5: Create cgroups of the pod
Step 6: Make data dictionaries of the pod
Step 7: Wait for the volume attached
Step 8: Fetch the ImagePullSecrets
Step 9: Call the container runtime kl.containerRuntime.SyncPod(pod, podStatus, pullSecrets, kl.backOff)
```

--------------------------------

### Get All Pods on Edge Node

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20220718-workload-update-model.md

Retrieves a list of all pods currently running on an edge node.

```APIDOC
## GET /pods

### Description
Retrieves a list of all pods on an edge node.

### Method
GET

### Endpoint
/pods
```

--------------------------------

### Build and Push Yurt-Manager Image

Source: https://context7.com/openyurtio/openyurt/llms.txt

Build and push the Yurt-Manager Docker image to a specified registry. Replace `myregistry.example.com/openyurt` with your actual image repository.

```bash
# Build and push yurt-manager image:
make docker-push-yurt-manager IMAGE_REPO=myregistry.example.com/openyurt
```

--------------------------------

### Get All Pods on Edge Node

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20220718-workload-update-model.md

Use this endpoint to retrieve a list of all pods running on an edge node.

```http
GET /pods HTTP/1.1
```

--------------------------------

### AddDevice - Add device and publish system event

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20230825-use-message-bus-instead-of-REST-to-communicate-with-EdgeX.md

Adds a device to the database and publishes an add system event to the message bus asynchronously. The event is published with the device service name in the topic path.

```go
func AddDevice(d models.Device, ctx context.Context, dic *di.Container) (id string, edgeXerr errors.EdgeX) {
	...
	// 添加device
	addedDevice, err := dbClient.AddDevice(d)
	...

	deviceDTO := dtos.FromDeviceModelToDTO(addedDevice)
    // 开一个协程，发布这个add的系统事件
	go publishSystemEvent(common.DeviceSystemEventType, common.SystemEventActionAdd, d.ServiceName, deviceDTO, ctx, dic)

	return addedDevice.Id, nil
}
```

--------------------------------

### Container Runtime Sync Pod Steps

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20220725-pod-recovery-efficiency-proposal.md

Details the process undertaken by the container runtime manager when synchronizing a pod. This includes computing changes, managing existing containers, and creating/starting new sandboxes and containers.

```text
Step 1: Compute sandbox and container changes.
Step 2: Kill the pod if the sandbox has changed.
Step 3: kill any running containers in this pod which are not to keep.
Step 4: Create a sandbox for the pod if necessary.
Step 5: start ephemeral containers
Step 6: start the init container.
Step 7: start containers in podContainerChanges.ContainersToStart.
```

--------------------------------

### DefaultRESTMapper Implementation

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20210301-enhancement_of_YurtHub_caching_ability.md

An example implementation of RESTMapper, used to determine the GVK of a resource based on GVR information. It helps in selecting the appropriate serializer.

```go
type DefaultRESTMapper struct {
	defaultGroupVersions []schema.GroupVersion

	resourceToKind       map[schema.GroupVersionResource]schema.GroupVersionKind
	kindToPluralResource map[schema.GroupVersionKind]schema.GroupVersionResource
	kindToScope          map[schema.GroupVersionKind]RESTScope
	singularToPlural     map[schema.GroupVersionResource]schema.GroupVersionResource
	pluralToSingular     map[schema.GroupVersionResource]schema.GroupVersionResource
}
```

--------------------------------

### LoadBalancer Service with YurtLB Annotation

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20231121-high-availability-of-edge-services.md

Example of a Kubernetes Service of type LoadBalancer configured to use YurtLB for VIP assignment via nodepool labels.

```yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: default
  annotations:
    service.openyurt.io/nodepool-labelselector: key1=val1,key2=val2
spec:
  type: LoadBalancer
  loadBalancerClass: service.openyurt.io/vip
...

status:
  loadBalancer:
      ingress:
      - hostname: hangzhou
        ip: 172.18.0.20
      - hostname: shanghai
        ip: 172.18.0.30
```

--------------------------------

### Define KeyBuildInfo Struct for Key Generation

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20220627-yurthub-cache-refactoring.md

Provides a structure to hold information necessary for generating cache keys, including component, namespace, name, resources, group, and version.

```go
type KeyBuildInfo struct {
	Component string
	Namespace string
	Name      string
	Resources string
	Group     string
	Version   string
}
```

--------------------------------

### YurtAppDaemon Deployment and StatefulSet Templates

Source: https://github.com/openyurtio/openyurt/blob/master/docs/enhancements/20210729-yurtappdaemon.md

Defines the Go structs for DeploymentTemplateSpec and StatefulSetTemplateSpec, used within YurtAppDaemon to specify application deployment configurations.

```go
type StatefulSetTemplateSpec struct {
	metav1.ObjectMeta `json:"metadata,omitempty"`
	Spec              appsv1.StatefulSetSpec `json:"spec"`
}

type DeploymentTemplateSpec struct {
	metav1.ObjectMeta `json:"metadata,omitempty"`
	Spec              appsv1.DeploymentSpec `json:"spec"`
}
```

--------------------------------

### Parameters for yurtctl init command

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20210607-adding-subcommands-server-join-reset-for-yurtctl.md

Defines constants for various flags used with the `yurtctl init` command, specifying configurations for API server, network settings, and OpenYurt conversion.

```go
const (
	// APIServerAdvertiseAddress flag sets the IP address the API Server will advertise it's listening on. Specify '0.0.0.0' to use the address of the default network interface.
	APIServerAdvertiseAddress = "apiserver-advertise-address"

	// APIServerBindPort flag sets the port for the API Server to bind to.
	APIServerBindPort = "apiserver-bind-port"

	// IgnorePreflightErrors sets the path a list of checks whose errors will be shown as warnings. Example: 'IsPrivilegedUser,Swap'. Value 'all' ignores errors from all checks.
	IgnorePreflightErrors = "ignore-preflight-errors"

	// ImageRepository sets the container registry to pull control plane images from.
	ImageRepository = "image-repository"

	// KubernetesVersion flag sets the Kubernetes version for the control plane.
	KubernetesVersion = "kubernetes-version"

	// NetworkingServiceSubnet flag sets the range of IP address for service VIPs.
	NetworkingServiceSubnet = "service-cidr"

	// NetworkingPodSubnet flag sets the range of IP addresses for the pod network. If set, the control plane will automatically allocate CIDRs for every node.
	NetworkingPodSubnet = "pod-network-cidr"

	// IsConvertOpenYurtCluster flag, if set, will convert standalone cluster to openyurt cluster.
	IsConvertOpenYurtCluster = "is-convert-openyurt"
)
```

--------------------------------

### Create a Device Associated with a DeviceProfile

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20210310-edge-device-management.md

This YAML defines a `Device` resource named `testsensor` that is associated with the `color-sensor` `DeviceProfile`. It specifies the desired value for the `lightcolor` property, enabling declarative control over the device's state.

```yaml
apiVersion: device.openyurt.io/v1alpha1
kind: Device
metadata:
  name: testsensor
spec:
  ...
  profile: color-sensor
  deviceProperties:
    lightcolor:
      name: lightcolor
      desiredValue: green

```

--------------------------------

### Define ObjectHandler Interface for Key-Value Resources

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20220627-yurthub-cache-refactoring.md

Defines handlers for manipulating resource objects in a key-value format. Includes operations for create, delete, get, list, and update.

```go
// objectHandler contains functions for manipulating resource objects in the format of key-value
// in the storage.
// Note:
// The description for each function in this interface only contains
// the interface-related error, which means other errors are also possibly returned,
// such as errors when reading/opening files.
type objectHandler interface {
	// Create will create content of key in the store.
	// The key must indicate a specific resource.
	// If key is empty, ErrKeyIsEmpty will be returned.
	// If this key has already existed in this store, ErrKeyExists will be returned.
	Create(key Key, content []byte) error

	// Delete will delete the content of key in the store.
	// The key must indicate a specific resource.
	// If key is empty, ErrKeyIsEmpty will be returned.
	Delete(key Key) error

	// Get will get the content of key from the store.
	// The key must indicate a specific resource.
	// If key is empty, ErrKeyIsEmpty will be returned.
	// If this key does not exist in this store, ErrStorageNotFound will be returned.
	Get(key Key) ([]byte, error)

	// List will retrieve all contents whose keys have the prefix of rootKey.
	// If key is empty, ErrKeyIsEmpty will be returned.
	// If the key does not exist in the store, ErrStorageNotFound will be returned.
	// If the key exists in the store but no other keys has it as prefix, an empty slice
	// of content will be returned.
	List(key Key) ([][]byte, error)

	// Update will try to update key in store with passed-in contents. Only when
	// the rv of passed-in contents is fresher than what is in the store, the Update will happen.
	// The content of key after Update is completed will be returned.
	// The key must indicate a specific resource.
	// If key is empty, ErrKeyIsEmpty will be returned.
	// If the key does not exist in the store, ErrStorageNotFound will be returned.
	// If force is not set and the rv is staler than what is in the store, ErrUpdateConflict will be returned.
	Update(key Key, contents []byte, rv uint64) ([]byte, error)

	// KeyFunc will generate the key used by this store.
	// info contains necessary info to generate the key for the object. How to use this info
	// to generate the key depends on the implementation of storage.
	KeyFunc(info KeyBuildInfo) (Key, error)
}
```

--------------------------------

### Workload Definition

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20240102-upgrade-yurtappset-to-v1beta1.md

Defines the workload to be deployed, including a template for the workload and optional tweaks for specific nodepools.

```go
type Workload struct {
 WorkloadTemplate WorkloadTemplate `json:"workloadTemplate"`
 WorkloadTweaks []WorkloadTweak `json:"workloadTweaks,omitempty"`
}
```

--------------------------------

### YurtAppOverrider for Specifying Registry

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20230706-yurtappoverrider.md

Configures a specific container registry for image pulls, which is useful for resolving edge network unreachability issues. This example targets the 'demo' container in Hangzhou.

```yaml
apiVersion: apps.openyurt.io/v1alpha1
kind: YurtAppOverrider
metadata:
  namespace: default
  name: demo1
subject:
  apiVersion: apps.openyurt.io/v1alpha1
  kind: YurtAppSet
  nameSpace: default
  name: yurtappset-demo
entries:
- pools:
    hangzhou
  items:
  - image:
      containerName: demo
      imageClaim: <registry_ip>:<registry_port>/<image_name>:<image_tag>
```

--------------------------------

### Repair EdgeX Environment Variables (YAML)

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20221109-edgex-auto-collector.md

Before and after examples of repairing environment variables for EdgeX components. This process ensures that port configurations are unified by adding PORT variables for each HOST variable.

```yaml
CLIENTS_CORE_COMMAND_HOST: edgex-core-command
CLIENTS_CORE_DATA_HOST: edgex-core-data
CLIENTS_CORE_METADATA_HOST: edgex-core-metadata
CLIENTS_SUPPORT_NOTIFICATIONS_HOST: edgex-support-notifications
CLIENTS_SUPPORT_SCHEDULER_HOST: edgex-support-scheduler
```

```yaml
CLIENTS_CORE_COMMAND_HOST: edgex-core-command
CLIENTS_CORE_COMMAND_PORT: "2000"
CLIENTS_CORE_DATA_HOST: edgex-core-data
CLIENTS_CORE_DATA_PORT: "2000"
CLIENTS_CORE_METADATA_HOST: edgex-core-metadata
CLIENTS_CORE_METADATA_PORT: "2000"
CLIENTS_SUPPORT_NOTIFICATIONS_HOST: edgex-support-notifications
CLIENTS_SUPPORT_NOTIFICATIONS_PORT: "2000"
CLIENTS_SUPPORT_SCHEDULER_HOST: edgex-support-scheduler
CLIENTS_SUPPORT_SCHEDULER_PORT: "2000"
```

--------------------------------

### Initialize and Run Pulsimeter Controller

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20230825-use-message-bus-instead-of-REST-to-communicate-with-EdgeX.md

Initializes a new Pulsimeter controller and adds its runnable component to the manager. Exits if initialization or runnable creation fails.

```go
	setupLog.Info("[NewPulsimeter] run the pulsimeter")
	pm, err := controllers.NewPulsimeter(mgr.GetClient(), opts)
	if err != nil {
		setupLog.Error(err, "unable to create plusimeter", "controller", "Device")
		os.Exit(1)
	}
	err = mgr.Add(pm.NewPulsimeterRunnable())
	if err != nil {
		setupLog.Error(err, "unable to create plusimeter runnable", "syncer", "Device")
		os.Exit(1)
	}
```

--------------------------------

### Define Static Pod Specification

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20221115-static-pod-upgrade-model.md

Defines the desired state for a static pod, including its name, manifest, and upgrade strategy. Use this to specify which static pod to upgrade and how.

```go
// StaticPodSpec defines the desired state of StaticPod
type StaticPodSpec struct {
	// INSERT ADDITIONAL SPEC FIELDS - desired state of cluster
	// Important: Run "make" to regenerate code after modifying this file

	// StaticPodName indicates the static pod desired to be upgraded.
    StaticPodName string `json:"staticPodName"

	// StaticPodManifest indicates the Static Pod desired to be upgraded. The corresponding
	// manifest file name is `ManifestName.yaml`.
	StaticPodManifest string `json:"staticPodManifest"`

	// An upgrade strategy to replace existing static pods with new ones.
	// +optional
	UpgradeStrategy StaticPodUpgradeStrategy `json:"upgradeStrategy"`

	// An object that describes the desired upgrade static pod.
	Template v1.PodTemplateSpec `json:"template"`
}
```

--------------------------------

### Collected Configuration by Auto Collector

Source: https://github.com/openyurtio/openyurt/blob/master/docs/proposals/20221109-edgex-auto-collector.md

Example of configuration data collected by the automatic collector, structured by version name, environment variables, and components. This format is used to store version-level and component-level configuration.

```yaml
- versionName: hanoi
  env:
    CLIENTS_COMMAND_HOST: edgex-core-command
    CLIENTS_COMMAND_PORT: "2000"
    CLIENTS_COREDATA_HOST: edgex-core-data
    CLIENTS_COREDATA_PORT: "2000"
    CLIENTS_DATA_HOST: edgex-core-data
    CLIENTS_DATA_PORT: "2000"
    CLIENTS_METADATA_HOST: edgex-core-metadata
    CLIENTS_METADATA_PORT: "2000"
    CLIENTS_NOTIFICATIONS_HOST: edgex-support-notifications
    CLIENTS_NOTIFICATIONS_PORT: "2000"
    CLIENTS_RULESENGINE_HOST: edgex-kuiper
    CLIENTS_RULESENGINE_PORT: "2000"
    CLIENTS_SCHEDULER_HOST: edgex-support-scheduler
    CLIENTS_SCHEDULER_PORT: "2000"
    CLIENTS_VIRTUALDEVICE_HOST: edgex-device-virtual
    CLIENTS_VIRTUALDEVICE_PORT: "2000"
    DATABASES_PRIMARY_HOST: edgex-redis
    DATABASES_PRIMARY_PORT: "2000"
    EDGEX_SECURITY_SECRET_STORE: "true"
    REGISTRY_HOST: edgex-core-consul
    REGISTRY_PORT: "2000"
    SECRETSTORE_HOST: edgex-vault
    SECRETSTORE_PORT: "2000"
    SECRETSTORE_ROOTCACERTPATH: /tmp/edgex/secrets/ca/ca.pem
    SECRETSTORE_SERVERNAME: edgex-vault
  components:
    - name: edgex-core-metadata
      image: edgexfoundry/docker-core-metadata-go:1.3.1
      componentEnv:
        NOTIFICATIONS_SENDER: edgex-core-metadata
        SECRETSTORE_TOKENFILE: /tmp/edgex/secrets/edgex-core-metadata/secrets-token.json
        SERVICE_HOST: edgex-core-metadata
        SERVICE_PORT: "2000"
      isSecurity: true
      volumes:
      - /tmp/edgex/secrets/ca:/tmp/edgex/secrets/ca
      - /tmp/edgex/secrets/edgex-core-metadata:/tmp/edgex/secrets/edgex-core-metadata

```

--------------------------------

### Set Up Git Remotes for OpenYurt Contribution

Source: https://github.com/openyurtio/openyurt/blob/master/CONTRIBUTING.md

Configure your local repository to track the upstream OpenYurt repository for synchronization and to prevent accidental pushes to the upstream.

```bash
git remote add upstream https://github.com/openyurtio/openyurt.git
git remote set-url --push upstream no-pushing
```