Use camel case for API objects: configmaps and secrets.

Signed-off-by: yanggang <gang.yang@daocloud.io>

design/Implemented/restore-with-EnableAPIGroupVersions-feature.md

@@ -29,7 +29,7 @@ During restore, the proposal is that Velero will determine if the `APIGroupVersi
 The proposed code starts with creating three lists for each backed up resource. The three lists will be created by
   (1) reading the directory names in the backup tarball file and seeing which API group versions were backed up from the source cluster,
   (2) looking at the target cluster and determining which API group versions are supported, and
-  (3) getting config maps from the target cluster in order to get user-defined prioritization of versions.
+  (3) getting ConfigMaps from the target cluster in order to get user-defined prioritization of versions.
 
   The three lists will be used to create a map of chosen versions for each resource to restore. If there is a user-defined list of priority versions, the versions will be checked against the supported versions lists. The highest user-defined priority version that is/was supported by both target and source clusters will be the chosen version for that resource. If no user specified versions are supported by neither target nor source, the versions will be logged and the restore will continue with other prioritizations.
 

pkg/cmd/server/server.go

@@ -541,7 +541,7 @@ High priorities:
   - PVs go before PVCs because PVCs depend on them.
   - PVCs go before pods or controllers so they can be mounted as volumes.
   - Service accounts go before secrets so service account token secrets can be filled automatically.
-  - Secrets and config maps go before pods or controllers so they can be mounted
+  - Secrets and ConfigMaps go before pods or controllers so they can be mounted
     as volumes.
   - Limit ranges go before pods or controllers so pods can use them.
   - Pods go before controllers so they can be explicitly restored and potentially

pkg/util/podvolume/pod_volume.go

@@ -46,7 +46,7 @@ func GetVolumesByPod(pod *corev1api.Pod, defaultVolumesToFsBackup bool) ([]strin
 		if pv.Secret != nil {
 			continue
 		}
-		// don't backup volumes mounting config maps. Config maps will be backed up separately.
+		// don't backup volumes mounting ConfigMaps. ConfigMaps will be backed up separately.
 		if pv.ConfigMap != nil {
 			continue
 		}

pkg/util/podvolume/pod_volume_test.go

@@ -222,7 +222,7 @@ func TestGetVolumesByPod(t *testing.T) {
 			},
 		},
 		{
-			name:                     "should exclude volumes mounting config maps",
+			name:                     "should exclude volumes mounting ConfigMaps",
 			defaultVolumesToFsBackup: true,
 			pod: &corev1api.Pod{
 				ObjectMeta: metav1.ObjectMeta{

site/content/docs/main/file-system-backup.md

@@ -185,7 +185,7 @@ The following sections provide more details on the two approaches.
 
 In this approach, Velero will back up all pod volumes using FSB with the exception of:  
 
-- Volumes mounting the default service account token, Kubernetes secrets, and config maps
+- Volumes mounting the default service account token, Kubernetes Secrets, and ConfigMaps
 - Hostpath volumes
 
 It is possible to exclude volumes from being backed up using the `backup.velero.io/backup-volumes-excludes` 

site/content/docs/v1.10/file-system-backup.md

@@ -186,7 +186,7 @@ The following sections provide more details on the two approaches.
 
 In this approach, Velero will back up all pod volumes using FSB with the exception of:  
 
-- Volumes mounting the default service account token, Kubernetes secrets, and config maps
+- Volumes mounting the default service account token, Kubernetes Secrets, and ConfigMaps
 - Hostpath volumes
 
 It is possible to exclude volumes from being backed up using the `backup.velero.io/backup-volumes-excludes` 

site/content/docs/v1.11/file-system-backup.md

@@ -186,7 +186,7 @@ The following sections provide more details on the two approaches.
 
 In this approach, Velero will back up all pod volumes using FSB with the exception of:  
 
-- Volumes mounting the default service account token, Kubernetes secrets, and config maps
+- Volumes mounting the default service account token, Kubernetes Secrets, and ConfigMaps
 - Hostpath volumes
 
 It is possible to exclude volumes from being backed up using the `backup.velero.io/backup-volumes-excludes` 

site/content/docs/v1.12/file-system-backup.md

@@ -199,7 +199,7 @@ The following sections provide more details on the two approaches.
 
 In this approach, Velero will back up all pod volumes using FSB with the exception of:  
 
-- Volumes mounting the default service account token, Kubernetes secrets, and config maps
+- Volumes mounting the default service account token, Kubernetes Secrets, and ConfigMaps
 - Hostpath volumes
 
 It is possible to exclude volumes from being backed up using the `backup.velero.io/backup-volumes-excludes` 

site/content/docs/v1.7/restic.md

@@ -183,7 +183,7 @@ The following sections provide more details on the two approaches.
 
 In this approach, Velero will back up all pod volumes using restic with the exception of:
 
-- Volumes mounting the default service account token, kubernetes secrets, and config maps
+- Volumes mounting the default service account token, Kubernetes Secrets, and ConfigMaps
 - Hostpath volumes
 
 It is possible to exclude volumes from being backed up using the `backup.velero.io/backup-volumes-excludes` annotation on the pod.

site/content/docs/v1.9/restic.md

@@ -186,7 +186,7 @@ The following sections provide more details on the two approaches.
 
 In this approach, Velero will back up all pod volumes using Restic with the exception of:
 
-- Volumes mounting the default service account token, Kubernetes secrets, and config maps
+- Volumes mounting the default service account token, Kubernetes Secrets, and ConfigMaps
 - Hostpath volumes
 
 It is possible to exclude volumes from being backed up using the `backup.velero.io/backup-volumes-excludes` annotation on the pod.

site/content/posts/2020-09-16-Velero-1.5-For-And-By-Community.md

@@ -33,7 +33,7 @@ With the release of 1.5, Velero now has the ability to backup all pod volumes us
 
 1. Volumes mounting the default service account token
 1. Hostpath volumes
-1. Volumes mounting Kubernetes secrets and config maps.
+1. Volumes mounting Kubernetes Secrets and ConfigMaps.
 
 You can enable this feature on a per backup basis or as a default setting for all Velero backups. Read more about this feature on our [restic integration](https://velero.io/docs/v1.5/restic/) page on our documentation website.