unable to run workload against HP public cloud #278
Comments
|
The exception means COSBench couldn’t get correct storage url, could you paste the json output for a successful keystone authentication? -yaguang Using 0.4.2.c2, I'm trying to define and run a workload against the HP public cloud implementation of swift. So far all my attempts to modify the config are failing, and frankly there isn't enough information in the logs to help pinpoint further. What I can see. The workload-log.txt include a stack trace as follows: ================================================== stage: s1-init ================================================== ---------------------------------- mission: MA40AD97CB3, driver: cosbench_driver.263528a8-1e90-11e5-aabf-fa163e055b81 ---------------------------------- 2015-06-29 18:56:34,959 [INFO] [Log4jLogManager] - will append log to file /home/cosbench/0.4.2.c2/log/mission/MA40AD97CB3.log 2015-06-29 18:56:35,461 [INFO] [NoneStorage] - performing PUT at /mycontainers1 2015-06-29 18:56:35,470 [ERROR] [AbstractOperator] - worker 1 fail to perform operation mycontainers1 com.intel.cosbench.api.storage.StorageException: java.lang.IllegalStateException: Target host must not be null, or set in parameters. Caused by: java.lang.IllegalStateException: Target host must not be null, or set in parameters. ================================================== stage: s2-prepare ================================================== ================================================== stage: s3-normal ================================================== ================================================== stage: s4-cleanup ================================================== ================================================== stage: s5-dispose ================================================== The relevant piece of the workload configuration is here: I can hazard a guess that the driver is unable to parse the service catalog returned by HP Helion OpenStack (http://docs.hpcloud.com/publiccloud/api/v2identity/#authenticate) either due to multiple regions or multiple swift endpoints in a given region, something along those lines. If anyone happens to know the proper keystone config for HP cloud, I would appreciate a note back. Alternately, if there is some way to get more descriptive logging that would be a step forward too. — |
|
Here it is. Note, I did a global search and replace of my username, tenant name, tenant id, the token id, and so on. But the structure is unchanged. I saw below that the swift service is named "Object Storage" with type "object-store" so I tried both of those strings in the in the workload definition, but that doesn't solve my problem. |
|
The service name should be “Object Storage”, and also, as you defined two regions for the service, <auth type="keystone" config="username=demo;password=mid;tenant_name=demo;auth_url=http://10.7.190.84:5000/v2.0;service=swift service;region="region-b.geo-1” /> -yaguang From: gonewest818 [mailto:[email protected]] Here it is. Note, I did a global search and replace of my username, tenant name, tenant id, the token id, and so on. But the structure is unchanged. I saw below that the swift service is named "Object Storage" with type "object-store" so I tried both of those strings in the in the workload definition, but that doesn't solve my problem. % curl -X POST https://region-a.geo-1.identity.hpcloudsvc.com:35357/v2.0/tokens -d @cred2.json -H "Content-Type: application/json" {"access": { "token": { }, "user": { }, "serviceCatalog": [ ] }} — |
|
Thanks, I will give that a try. Incidentally, I am going to be doing tests against 4 other vendor implementations. Another question, is there a way to get more debugging detail on these failures? For example you asked me for the json output from a successful authentication, and I had to do that y hand with curl. It seems to me I should be able turn up the verbosity of logging enough to see what communication exists between the drivers and the service. I already have logging level set to DEBUG but there's nothing useful there. |
|
Setting "region=region-a.geo-1" did work for this particular vendor. Thanks for clarifying. |
|
COSBench consists of two parts, one is controller, another is driver, which has one configuration file, called controller.conf or driver.conf. you can set the log_level parameter as following: ;; this is from driver.conf -yaguang From: gonewest818 [mailto:[email protected]] Thanks, I will give that at try. Incidentally, I am going to be doing tests against 4 other vendor implementations. Another question, is there a way to get more debugging detail on these failures? For example you asked me for the json output from a successful authentication, and I had to do that y hand with curl. It seems to me I should be able turn up the verbosity of logging enough to see what communication exists between the drivers and the service. I already have logging level set to DEBUG but there's nothing useful there. — |
|
yes, but even with log_level=DEBUG there was nothing logged that helped me with this issue. As a suggestion, can the logging be more informative? For example for debugging you could log the elements of the json returned from keystone, and log a message to the user that the parameters in the tag aren’t sufficient to select a single endpoint.
|
Using 0.4.2.c2, I'm trying to define and run a workload against the HP public cloud implementation of swift. So far all my attempts to modify the config are failing, and frankly there isn't enough information in the logs to help pinpoint further.
What I can see. The workload-log.txt include a stack trace as follows:
The relevant piece of the workload configuration is here:
I can hazard a guess that the driver is unable to parse the service catalog returned by HP Helion OpenStack (http://docs.hpcloud.com/publiccloud/api/v2identity/#authenticate) either due to multiple regions or multiple swift endpoints in a given region, something along those lines.
If anyone happens to know the proper keystone config for HP cloud, I would appreciate a note back. Alternately, if there is some way to get more descriptive logging that would be a step forward too.
The text was updated successfully, but these errors were encountered: