Docs: Add generic guide #443
Conversation
This patch adds documentation to explain concepts needed to understand the configuration of the Block Storage (cinder) service on OpenShift. There is general information meant for users explaining extra volumes, placement restrictions, snippets, etc., as well as cinder specific topics.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Akrog The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| These pod names are formed using a predetermined template: | ||
|
|
||
| * For volumes: `cinder-volume-\<backend\_key\>-0` | ||
| * For backups: `cinder-backup-\<replica-number\>` |
There was a problem hiding this comment.
Replace the \< with /.
* For volumes: `cinder-volume-<backend_key>-0`
* For backups: `cinder-backup-<replica-number>`
|
|
||
| Within this section there are some global configuration options that can be set | ||
| directly under the `cinder` section, but there are also some other global | ||
| configuration options in the `template` section within this `cinder` section. |
There was a problem hiding this comment.
I don't know what options you are referring to directly under the cinder section, but I suspect there are two categories of options and I wonder if we need to give them different names rather than using <global-options> for both.
| run some daemons and kernel modules, such as `iscsid` and `multipathd`. | ||
|
|
||
| These daemon and kernel modules must be available in all the OpenShift nodes | ||
| where the cinder volume and backup services could run, not only on the ones |
There was a problem hiding this comment.
Maybe also mention glance API services, when glance is using cinder for image storage. I haven't read further, so perhaps this is a nit that can be overlooked in this intro section as long as we mention g-api down in the detailed sections.
|
|
||
| ### 3.1. iSCSI | ||
|
|
||
| Connecting to iSCSI volumes from the OpenShift nodes requires the iSCSI |
There was a problem hiding this comment.
Is this a good place to get into master versus worker nodes?
| kind: MachineConfig | ||
| metadata: | ||
| labels: | ||
| machineconfiguration.openshift.io/role: worker |
There was a problem hiding this comment.
Somewhere we need to capture the fact that these machineConfig need to be installed on worker nodes, but when you have a 3-node OCP where workers == master then I recall it's necessary to specify "master" for the role.
| below](#multipathing) to see how to configure it. | ||
|
|
||
| It is of utmost importance that all OpenShift nodes that are going to run cinder | ||
| volume and cinder backups have a HBA card. |
There was a problem hiding this comment.
Again, not sure how complete we need to be here, but what about g-api?
| propagation at the deployment level will propagate to the cinder, glance, and | ||
| manila DB sync pods. | ||
|
|
||
| - \[4\] Optional field declaring the type of propagation. It’s possible values |
There was a problem hiding this comment.
I think it's the "type of extraVol" rather than "type of propagation." Regardless, the purpose of the field was never really settled, and right now it's just an optional string that can be used to label an extraMount. I don't believe there are any "possible values" enforced.
|
|
||
| ``` | ||
| - name: ceph | ||
| projected: |
There was a problem hiding this comment.
I think we should avoid using projected volumes in our samples and documentation, as it refers to an OpenShift volume that's comprised of multiple sources. All of our examples (including this one) have just a single source.
- name: ceph
secret:
secretName: ceph-conf-files
| extraVolType: Ceph | ||
| volumes: | ||
| - name: ceph | ||
| projected: |
There was a problem hiding this comment.
Again, I suggest using a secret rather than projected volume type.
| - extraVol: | ||
| - volumes: | ||
| - name: policy | ||
| projected: |
| propagation: | ||
| - CinderAPI | ||
| ``` | ||
|
|
There was a problem hiding this comment.
I think we need to cover the use of subPath, which is necessary when the mountPath is a directory with other content (not just an empty directory).
This PR adds documentation to explain concepts needed to understand the configuration of the Block Storage (cinder) service on OpenShift.
There is general information meant for users explaining extra volumes, placement restrictions, snippets, etc., as well as cinder specific topics.