Docs: Add generic guide #443
Conversation
docs/user-guide/cinder.md
Outdated
| 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>`
docs/user-guide/cinder.md
Outdated
|
|
||
| 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.
There was a problem hiding this comment.
Under cinder we have enabled and uniquePodNames` which have a global effect. I'm referring to those, but it's true that calling both global may be confusing.
I'll try to rephrase it.
| 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.
There was a problem hiding this comment.
I don't mention anything about glance, since I consider that is a glance documentation matter.
We can always add it in the future if glance doesn't.
|
|
||
| ### 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?
There was a problem hiding this comment.
I have added it now as an attention block right about this section.
| 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.
There was a problem hiding this comment.
Yes, that is correct. I have added an attention block for it.
| 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?
There was a problem hiding this comment.
I'd rather leave that to glance or for a follow up PR.
docs/user-guide/commonalities.md
Outdated
| 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.
There was a problem hiding this comment.
Changed to "type of extra volume"
docs/user-guide/commonalities.md
Outdated
|
|
||
| ``` | ||
| - 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
There was a problem hiding this comment.
I was using projected because then it's easier for people looking at this deploying multiple Ceph clusters just using this as a reference.
I'll change it and leave the multiple Ceph clusters documentation for a follow up.
docs/user-guide/commonalities.md
Outdated
| extraVolType: Ceph | ||
| volumes: | ||
| - name: ceph | ||
| projected: |
There was a problem hiding this comment.
Again, I suggest using a secret rather than projected volume type.
docs/user-guide/commonalities.md
Outdated
| - 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 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, ASBishop 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 |
openshift-merge-bot
bot
merged commit 009e8c0
into
openstack-k8s-operators:main
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.