[
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)
