OSDOCS-16945#CQA work Stor1 -- dynamic provisioning#106217
Conversation
|
/retest |
b5ca045 to
449dfb2
Compare
|
@lpettyjo: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
skopacz1
left a comment
There was a problem hiding this comment.
Looks good! I left some comments and suggestions, but once they're addressed this is ok to merge.
Feel free to ask me for another look if you feel like you've made significant changes from this feedback, but you can also just merge it if you want
| and allows administrators to provision a cluster with persistent storage. | ||
| The framework also gives users a way to request those resources without | ||
| having any knowledge of the underlying infrastructure. | ||
| `StorageClass` objects can also serve as a management mechanism for controlling different levels of storage and access to the storage. Cluster Administrators (`cluster-admin`)or Storage Administrators (`storage-admin`) define and create the `StorageClass` objects that users can request without needing any detailed knowledge about the underlying storage volume sources. |
There was a problem hiding this comment.
Missing space here:
| `StorageClass` objects can also serve as a management mechanism for controlling different levels of storage and access to the storage. Cluster Administrators (`cluster-admin`)or Storage Administrators (`storage-admin`) define and create the `StorageClass` objects that users can request without needing any detailed knowledge about the underlying storage volume sources. | |
| `StorageClass` objects can also serve as a management mechanism for controlling different levels of storage and access to the storage. Cluster Administrators (`cluster-admin`) or Storage Administrators (`storage-admin`) define and create the `StorageClass` objects that users can request without needing any detailed knowledge about the underlying storage volume sources. |
| ---- | ||
| storageclass.kubernetes.io/is-default-class: "true" | ||
| ---- | ||
| This enables any persistent volume claim (PVC) that does not specify a specific storage class to automatically be provisioned by the default storage class. While your cluster can have more than one storage class, only one can be the default storage class. |
There was a problem hiding this comment.
One thing I recently learned is that when we move our content to DITA, any prereqs will be placed in between the short description and any other intro content that precedes the .Procedure title. Here's a link for more info.
Not saying this needs to be addressed now, and the link specifically says not to move the prereqs yourself, but it might be worth considering whether intro content like this would stand on its own once a prereqs list was put between it and the short description.
|
|
||
| For example: | ||
| .Prerequisites | ||
| * Logged in to a running {product-title} cluster with administrator privileges. |
There was a problem hiding this comment.
Suggesting a use of a pronoun for user focus here:
| * Logged in to a running {product-title} cluster with administrator privileges. | |
| * You are logged in to a running {product-title} cluster with administrator privileges. |
|
|
||
| For example: | ||
|
|
||
| . (Optional) Create a storage class description in the `metadata.annotations.kubernetes.io/description` field as in the following example: |
There was a problem hiding this comment.
Per the ISG there's a slightly different way to indicate optional steps:
| . (Optional) Create a storage class description in the `metadata.annotations.kubernetes.io/description` field as in the following example: | |
| . Optional: Create a storage class description in the `metadata.annotations.kubernetes.io/description` field as in the following example: |
| generic implementations for dynamic provisioning that use the cluster's | ||
| configured provider's API to create new storage resources: | ||
| [role="_abstract"] | ||
| {product-title} provides the following provisioner plugins, which have generic implementations for dynamic provisioning using the cluster's configured provider's API to create new storage resources. |
There was a problem hiding this comment.
I think using "the following" is technically self referential to the doc, which we're supposed to avoid in short descriptions. It's probably fine to keep as is, but maybe it can be removed and perhaps even another sentence outside the short description could be added to introduce the table. Up to you:
| {product-title} provides the following provisioner plugins, which have generic implementations for dynamic provisioning using the cluster's configured provider's API to create new storage resources. | |
| {product-title} provides several provisioner plugins, which have generic implementations for dynamic provisioning using the cluster's configured provider's API to create new storage resources. |
There was a problem hiding this comment.
Actually I see now that some distros have only one plugin in the table, so if you do choose to remove "the following", it would be better not to use "several" in its place
| standard (default) ebs.csi.aws.com | ||
| ---- | ||
| + | ||
| The `standard` storage class is now the default. No newline at end of file |
There was a problem hiding this comment.
Slight suggestion to make the example phrasing more consistent throughout the procedure:
| The `standard` storage class is now the default. | |
| In this example the `standard` storage class is now the default. |
| `StorageClass` objects are currently a globally scoped object and must be | ||
| created by `cluster-admin` or `storage-admin` users. | ||
| [role="_abstract"] | ||
| `StorageClass` objects are globally scoped objects and can only be created by `cluster-admin` or `storage-admin` users. |
There was a problem hiding this comment.
Similar comment about the placement of "only":
| `StorageClass` objects are globally scoped objects and can only be created by `cluster-admin` or `storage-admin` users. | |
| `StorageClass` objects are globally scoped objects and can be created only by `cluster-admin` or `storage-admin` users. |
| The following is a GCE PD example storage class object definition. | ||
|
|
||
| .Example GCE PD storage class YAML file |
There was a problem hiding this comment.
In addition to other suggestions about adding a different sentence as the short description, I would use consistent abbreviations here as used in the heading (and spell it out in the first use in the body anyways):
| The following is a GCE PD example storage class object definition. | |
| .Example GCE PD storage class YAML file | |
| The following is a example GCE PersistentDisk (gcePD) storage class object definition. | |
| .Example gcePD storage class YAML file |
|
|
||
| * `metadata.name`: The name of the storage class. | ||
|
|
||
| * Optional: `metadata.annotations`: Annotations for the storage class. |
There was a problem hiding this comment.
Same suggestion as earlier about moving the Optional phrasing to the text:
| * Optional: `metadata.annotations`: Annotations for the storage class. | |
| * `metadata.annotations`: Optional. Annotations for the storage class. |
|
|
||
| include::modules/dynamic-provisioning-aws-definition.adoc[leveloffset=+2] | ||
|
|
||
| [id="dynamic-provisioning-add-resources"_{context}"] |
There was a problem hiding this comment.
For module level additional resources sections, there is no id used but there is nonetheless still a role tag:
| [id="dynamic-provisioning-add-resources"_{context}"] | |
| [role="_additional-resources"] |
Version(s): 4.16+
Issue: https://issues.redhat.com/browse/OSDOCS-16945
Link to docs preview: All topics under https://106217--ocpdocs-pr.netlify.app/openshift-enterprise/latest/storage/dynamic-provisioning
QE review:
Additional information: