external: add Openshift Virt Storage Class when crd is present#3703
external: add Openshift Virt Storage Class when crd is present#3703ShravaniVangur wants to merge 1 commit intored-hat-storage:mainfrom
Conversation
|
/cc @parth-gr |
| return err | ||
| } | ||
| if crd.UID != "" { | ||
| scc = StorageClassConfiguration{ |
There was a problem hiding this comment.
This should be done inside the else if d.Name == cephRbdStorageClassName {
either create virt sc or create the rbd normal sc
There was a problem hiding this comment.
This would be an additional RBD storage class and should not replace the existing one right?
There was a problem hiding this comment.
I think it should be the only storageclass not a additionla one, check with @eran
3c636ae to
481fb61
Compare
|
@ShravaniVangur @parth-gr I had one question here, the virt storageclass that we create should be created on top of the default radosnamespace or the custom radosnamespace? |
Should be created directly on top of the pool, |
481fb61 to
daf463b
Compare
| instance.Namespace, | ||
| "", | ||
| "", | ||
| instance.Spec.ManagedResources.CephBlockPools.DefaultVirtualizationStorageClass, |
There was a problem hiding this comment.
What happens if we already have a default virtualization SC for internal mode? dont we need to error out?
There was a problem hiding this comment.
Users are responsible for ensuring that the default field is marked on only one StorageCluster CR. The system does not perform validation to detect conflicts across multiple StorageCluster CRs.
daf463b to
dafa795
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Madhu-1, ShravaniVangur The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
@parth-gr are we supporting two rados namespace in external mode? it is currently one right. we dont support multiple Radosnamespace in the same ODF cluster. |
Yes currently we support one per ocp cluster |
Creates the virtualization storage class when the kubevirt crd is present. Signed-off-by: ShravaniVangur <shravanivangur@gmail.com>
dafa795 to
9db195c
Compare
|
New changes are detected. LGTM label has been removed. |
| // create virtualization storageclass if VirtualMachineCRD is present | ||
| var scc StorageClassConfiguration | ||
| crd := &metav1.PartialObjectMetadata{} | ||
| crd.SetGroupVersionKind(extv1.SchemeGroupVersion.WithKind("CustomResourceDefinition")) |
There was a problem hiding this comment.
is getting a crd is sufficient? or we should loook for a cr?
There was a problem hiding this comment.
The StorageClasses are created based on the availability of a CRD. So the check should be sufficient.
parth-gr
left a comment
There was a problem hiding this comment.
Overall looks good to me,
Can you do a one round of testing,
Maybe you can just simulate the virt env by creating the crd
directly on top of the pool -> That means the non-default rns right? This means that a single ocp cluster can have one storage class on a Rados namespace and another one on a non-default RNS (virt storageclass) |
No only for the non-virt class, currently |
| if crd.UID != "" { | ||
| scc = StorageClassConfiguration{ | ||
| storageClass: util.NewDefaultVirtRbdStorageClass( | ||
| instance.Namespace, |
There was a problem hiding this comment.
@ShravaniVangur @parth-gr I think this is not right, this means that there can be a storageclass with clientProfile as raodsnamespace
and another storageclass virt one with clientProfile as openshift-storage-external.
What we should do is
- If there is a radosnamespace in externalResources, then we create all rbd classes on top of that radosnamespace client profile.
- If there is no radosnamespace, then we should create the classes on top of the default client profile.
This should also apply to the topology based storageclass for external mode.
cc: @Madhu-1 @travisn
There was a problem hiding this comment.
Yes i discussed with @rewantsoni on this one, looks like we do have bug in the extrernal mode where when topology based provisioning is used its not using the rados namespace , its using detault one.
we have a hacky code that is modifying the clusterID to match the radosnamespace. we should apply for this one as well and we need to fix the topology based SC
Creates the virtualization storage class when the kubevirt crd is present.Adds the default label based on
instance.Spec.ManagedResources.CephBlockPools.DefaultVirtualizationStorageClass.Resolves: RHSTOR-8594