config.yaml 5.1 KB

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182
  1. # The intended namespace where the validation test will be run. This is should be where the
  2. # Rook-Ceph cluster will be installed.
  3. namespace: "{{ .Namespace }}"
  4. # These fields should be set to the name of the Network Attachment Definition (NAD) which will be
  5. # used for the Ceph cluster's public or cluster network, respectively. This should be a namespaced
  6. # name in the form <namespace>/<name> if the NAD is defined in a different namespace from the
  7. # CephCluster namespace. One or both of the fields may be set.
  8. publicNetwork: "{{ .PublicNetwork }}"
  9. clusterNetwork: "{{ .ClusterNetwork }}"
  10. # This is the time to wait for resources to change to the expected state. For example, for the test
  11. # web server to start, for test clients to become ready, or for test resources to be deleted. At
  12. # longest, this may need to reflect the time it takes for client pods to get address assignments and
  13. # then for each client to determine that its network connection is stable.
  14. # This should be at least 1 minute. 2 minutes or more is recommended.
  15. resourceTimeout: "{{ .ResourceTimeout }}"
  16. # This is the time window in which validation clients are all expected to become "Ready" together.
  17. # Validation clients are all started at approximately the same time, and they should all stabilize
  18. # at approximately the same time. Once the first validation client becomes "Ready," the tool checks
  19. # that all of the remaining clients become "Ready" before this threshold duration elapses.
  20. # In networks that have connectivity issues, limited bandwidth, or high latency, clients will contend
  21. # for network traffic with each other, causing some clients to randomly fail and become "Ready" later
  22. # than others. These randomly-failing clients are considered "flaky." Adjust this value to reflect
  23. # expectations for the underlying network. For fast and reliable networks, this can be set to a smaller
  24. # value. For networks that are intended to be slow, this can be set to a larger value. Additionally, for
  25. # very large Kubernetes clusters, it may take longer for all clients to start, and it therefore may take
  26. # longer for all clients to become "Ready"; in that case, this value can be set slightly higher.
  27. flakyThreshold: "{{ .FlakyThreshold }}"
  28. # The Nginx image which will be used for the web server and clients.
  29. nginxImage: "{{ .NginxImage }}"
  30. # Specify validation test config for groups of nodes. A Ceph cluster may span more than one type of
  31. # node, but usually not more than 3. Node types defined here should not overlap with each other.
  32. # Common examples of different node types are below:
  33. # - General, converged nodes that are used for both Ceph daemons and user applications
  34. # - Dedicated storage nodes for hosting Ceph storage daemons
  35. # - Non-storage nodes running workloads other than Ceph (running only Ceph CSI plugin daemons)
  36. # - Dedicated nodes for hosting Ceph arbiter mons
  37. # - Dedicated nodes for hosting only Ceph core (RADOS) components: mons, mgrs, OSDs
  38. # - Dedicated nodes for hosting non-core storage components: MDS, RGW, CSI provisioner, etc.
  39. nodeTypes:
  40. {{- range $type, $config := .NodeTypes }}
  41. {{ $type }}: # Unique name for this node type (lower-case alphanumeric characters and dashes only)
  42. # This should reflect the maximum number of OSDs that may run on any given node of this type
  43. # during a worst-case failure scenario. This may be a static number expected by the
  44. # StorageClassDeviceSets planned for the CephCluster. For portable OSDs, this may be larger to
  45. # account for OSDs being rescheduled during node failures.
  46. osdsPerNode: {{ $config.OSDsPerNode }}
  47. # This should reflect the maximum number of Ceph and CSI daemons that may run on any given node
  48. # during a worst-case failure scenario. CSI requires 2 Multus addresses per plugin daemon.
  49. #
  50. # In the converged case, a Rook cluster with a single instance of all resource types might run
  51. # these daemons on a single node during worst-case failure:
  52. # 1 mon, 1 mgr, 1 MDS, 1 NFS server, 1 RGW, 1 rbdmirror, 1 cephfsmirror, plus
  53. # 1 CSI provisioner and 2 CSI plugins for all 3 CSI types (RBD, CephFS, NFS) -- 16 daemons
  54. #
  55. # A node that is running only client workloads would run only the CSI plugin daemons per node:
  56. # 2 CSI plugins for all 3 CSI type (RBD, CephFS, NFS) -- 6 daemons
  57. otherDaemonsPerNode: {{ $config.OtherDaemonsPerNode }}
  58. # Placement options for informing the validation tool how to identify this type of node.
  59. # Affinities are not supported because their behavior is too relaxed for ensuring a specific
  60. # number of daemons per node.
  61. placement:
  62. # Kubernetes Pod spec node selector for assigning validation Pods to this node type.
  63. # See https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector
  64. nodeSelector:
  65. {{- range $k, $v := $config.Placement.NodeSelector }}
  66. {{ $k }}: {{ $v }}
  67. {{- end }}
  68. # Kubernetes tolerations for assigning validation Pods to this node type.
  69. # See https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/
  70. tolerations:
  71. {{- range $idx, $toleration := $config.Placement.Tolerations }}
  72. - {{ $toleration.ToJSON }}
  73. {{- end }}
  74. {{ end }}