[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15258815#comment-15258815
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9368:
--------------------------------------------

Github user rafaelweingartner commented on the pull request:

    https://github.com/apache/cloudstack/pull/1518#issuecomment-214868283
  
    @nvazquez , what about extracting that “private Integer nfsVersion” to a 
common superclass to all of those command class? I have created a hierarchy to 
help you.  The classes with an * are the ones that you did not touch directly, 
they are there just to build the hierarchy. I found a little odd that the 
“ListTemplateCommand” received those values too, are they being used there?
    
    Maybe you cannot write a single super class to attend all of those cases, 
but you could easily write on to be the super class for (CopyVolumeCommand, 
SecStorageSetupCommand, GetStorageStatsCommand, SnapshotCommand, 
BackupSnapshotCommand , CreatePrivateTemplateFromSnapshotCommand,  
CreatePrivateTemplateFromVolumeCommand, CreateVolumeFromSnapshotCommand)
    
    Here is the hierachy:
    - TemplateOrVolumePostUploadCommand
    - Command*
        -- StorageCommand*
                --- ListTemplateCommand
        -- SsCommand*
                --- AbstractDownloadCommand*
                        ---- PrimaryStorageDownloadCommand
        -- CopyVolumeCommand
        -- SecStorageSetupCommand
        -- GetStorageStatsCommand
    -- SnapshotCommand
    --- BackupSnapshotCommand 
    --- CreatePrivateTemplateFromSnapshotCommand
    --- CreatePrivateTemplateFromVolumeCommand
    --- CreateVolumeFromSnapshotCommand
    
    I missing the test cases for 
“checkStorageProcessorAndHandlerNfsVersionAttribute”, 
“examineStorageSubSystemCommandNfsVersion”, 
“setCurrentNfsVersionInProcessorAndHandler” , “getStorageNfsVersionFromNfsTO”  
and “reconfigureNfsVersion” methods. They are very good coded, clean, short, 
well documented. To improve them further the writing of test cases is very 
welcome.



> Fix for Support configurable NFS version for Secondary Storage mounts
> ---------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-9368
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9368
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the 
> default.) 
>          Components: VMware
>    Affects Versions: 4.9.0
>            Reporter: Nicolas Vazquez
>             Fix For: 4.9.0
>
>
> This issue address a problem introduced in 
> [CLOUDSTACK-9252|https://issues.apache.org/jira/browse/CLOUDSTACK-9252] in 
> which NFS version couldn't be changed after hosts resources were configured 
> on startup (for hosts using `VmwareResource`), and as host parameters didn't 
> include `nfs.version` key, it was set `null`.
> h4. Proposed solution
> In this proposed solution `nfsVersion` would be passed in `NfsTO` through 
> `CopyCommand` to `VmwareResource`, who will check if NFS version is still 
> configured or not. If not, it will use the one sent in the command and will 
> set it to its storage processor and storage handler. After those setups, it 
> will proceed executing command.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to