cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CLOUDSTACK-8648) "Unable to get storage implementation" when copying template from NFS to S3
Date Tue, 21 Jul 2015 11:46:04 GMT

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

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

Github user karuturi commented on the pull request:

    https://github.com/apache/cloudstack/pull/606#issuecomment-123278333
  
    while I agree with the code change based on the current implementations of getVirtualSize,
should we just pass the storage layer in the params so that any new implementation if required
can use the storage layer?
    ```
    Map<String, Object> params = new HashMap<String, Object>();
    params.put(StorageLayer.InstanceConfigKey, _storage);
    processor.configure("template processor", new HashMap<String, Object>());
    ```



> "Unable to get storage implementation" when copying template from NFS to S3
> ---------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-8648
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8648
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Secondary Storage
>    Affects Versions: Future, 4.5.2
>            Reporter: Wido den Hollander
>              Labels: qcow2, s3, secondary_storage
>             Fix For: Future
>
>
> In the SSVM this can be observed:
> 2015-07-17 12:12:56,675 WARN  [storage.resource.NfsSecondaryStorageResource] (agentRequest-Handler-11:null)
Failed to get virtual size, returning file size instead:
> javax.naming.ConfigurationException: Unable to get storage implementation
> 	at com.cloud.storage.template.QCOW2Processor.configure(QCOW2Processor.java:95)
> 	at org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.getVirtualSize(NfsSecondaryStorageResource.java:828)
> 	at org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.copyFromNfsToS3(NfsSecondaryStorageResource.java:886)
> 	at org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.copyFromNfsToImage(NfsSecondaryStorageResource.java:618)
> 	at org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:645)
> 	at org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.java:233)
> 	at com.cloud.agent.Agent.processRequest(Agent.java:503)
> 	at com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:808)
> 	at com.cloud.utils.nio.Task.run(Task.java:84)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 	at java.lang.Thread.run(Thread.java:745)
> The problem is this:
> processor.configure("template processor", new HashMap<String, Object>());
> return processor.getVirtualSize(file);
> It confitures the processor with a empty HashMap, but the check in the processor is:
> public boolean configure(String name, Map<String, Object> params) throws ConfigurationException
{
>     _storage = (StorageLayer)params.get(StorageLayer.InstanceConfigKey);
>     if (_storage == null) {
>         throw new ConfigurationException("Unable to get storage implementation");
>     }
> Since the HashMap is empty null is returned and this exception is thrown.
> No need to configure the Processor as far as I can see.



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

Mime
View raw message