The way to talk to swift endpoint, by using haproxy to redirect url request contains "/v1.0" to swift endpoint, so it assumes, the endpoint of swift is the same as cloudstack mgt server. Correct me, if I am wrong, I just try to figure how it works. But what if the swift endpoint is different from CloudStack mgt server? Take Aws console as an example, the aws console is console.aws.amazon.com, but the S3 endpoint is s3-console-us-standard.console.aws.amazon.com.
From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of Will Stevens Sent: Thursday, March 13, 2014 5:52 PM To: Edison Su Cc: dev@cloudstack.apache.org; David Nalley <da...@gnsa.us> (da...@gnsa.us) Subject: Re: [REVIEW] OpenStack Swift as Object Storage Service What are you referring to as the 'v1.0 url hack'? Bypassing the cloudstack management server is an intentional design decision to improve performance. The introduction of a load balancer in front of the two distinct services to maintain separation of their traffic is a good thing. I will review the UI tutorial you sent... I will check how much work it is to replace PLupload with the jQuery File Upload plugin. Cheers, Will On Thu, Mar 13, 2014 at 8:24 PM, Edison Su <edison...@citrix.com<mailto:edison...@citrix.com>> wrote: One comment on the "/v1.0" url hack, seems changing mgt server is unavoidable, would it be easier to add a new api in cloudstack, which can get the endpoint of swift server and the auth? And the UI change should be put under ui plugin: https://cwiki.apache.org/confluence/display/CLOUDSTACK/UI+Plugin+Tutorial, and also, as David mentioned, plupload is not compatible with Apache license, maybe something like: https://github.com/blueimp/jQuery-File-Upload, is better to be used.
