Open Stack

I think in both cases you should be giving your jclouds the auth url of:

http://swift.domain.com <http://swift.domain.com/v1.0/v1.0>/auth/

or maybe

https://swift2.anotherdomain.com/<https://swift2.anotherdomain.com/v1.0/v1.0>
auth/v1.0








On Fri, Jan 24, 2014 at 10:13 AM, Shrinand Javadekar <
shrinand at maginatics.com> wrote:

> These are two different clusters with their own individual auth systems.
> In fact, one is internal to where I work and another is at a customer site.
> These should both be using swauth and that let me to believe that both
> should have the same behavior.
>
> I am using the jclouds java library. I am looking at the jclouds code to
> find out if there's some problem with the extra "v1.0". My hunch was that I
> should not use the "v1.0" in the endpoint url since jclouds seems to append
> it. But that didn't work. I'll update this thread if I find something in
> jclouds that is the problem.
>
>
>
> On Thu, Jan 23, 2014 at 9:23 PM, Clay Gerrard <clay.gerrard at gmail.com>wrote:
>
>> ah ok, so are these two clusters setup as part of a single swauth
>> installation?  Are you using one as the auth system with service endpoints
>> to the other (i.e.
>> http://gholt.github.io/swauth/dev/api.html#set-service-endpoints)?
>>
>> Or are these two separate clusters which should be configured the same
>> but seem to exhibit different behaviors based on the same input?
>>
>> Also - what client?  What is the auth url being given to it?  Can you try
>> to drop the v1.0?  The /v1.0/v1.0 thing doesn't seem like it should work.
>>
>> -Clay
>>
>>
>> On Thu, Jan 23, 2014 at 4:12 PM, Shrinand Javadekar <
>> shrinand at maginatics.com> wrote:
>>
>>> Yes, swauth.
>>>
>>>
>>> On Thu, Jan 23, 2014 at 1:52 PM, Clay Gerrard <clay.gerrard at gmail.com>wrote:
>>>
>>>> Is SwiftAuth... like Swauth?
>>>>
>>>> https://github.com/gholt/swauth/search?q=SwiftAuth&ref=cmdform
>>>>
>>>> or something else???
>>>>
>>>>
>>>> On Thu, Jan 23, 2014 at 10:44 AM, Shrinand Javadekar <
>>>> shrinand at maginatics.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am trying to debug a swift auth problem. There are two swift
>>>>> clusters using SwiftAuth for authentication.
>>>>>
>>>>> On one cluster, when the client wants to authenticate, I see a GET
>>>>> request being sent to:
>>>>>
>>>>> http://swift.domain.com/v1.0/v1.0
>>>>>
>>>>> along with the user-name and password. It receives a 200 OK from the
>>>>> server along with the X-Storage-Token and X-Auth-Token. The client is
>>>>> successfully authenticated and things work perfectly.
>>>>>
>>>>> On the other cluster, when the client wants to authenticate, I see a
>>>>> GET request being sent to:
>>>>>
>>>>> https://swift2.anotherdomain.com/v1.0/v1.0
>>>>>
>>>>> along with the username and password. In this case, the client
>>>>> receives a 404 NOT FOUND response. If I use
>>>>> https://swift2.anotherdomain.com/v1.0, things work fine.
>>>>>
>>>>> Is there a config option in swift to either ignore the second "v1.0"
>>>>> in the path or maybe handle it in some other way so that the auth succeeds?
>>>>>
>>>>> Thanks in advance.
>>>>> -Shri
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list:
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>>> Post to     : openstack at lists.openstack.org
>>>>> Unsubscribe :
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140129/7814017d/attachment.html>