Tom,

We are seeing the 405 error when we go directly against Cloud Auth – now that the LB rule has been removed.  Is this a problem that you guys are looking into?

Thanks,

Jeff

From: Nicholas Mistry <<email address hidden><mailto:<email address hidden>>>
Date: Wed, 9 Nov 2011 13:56:56 -0600
To: Jeff Highley <<email address hidden><mailto:<email address hidden>>>
Cc: Tom Hopkins <<email address hidden><mailto:<email address hidden>>>, Antony Messerli <<email address hidden><mailto:<email address hidden>>>, Ziad Sawalha <<email address hidden><mailto:<email address hidden>>>
Subject: Re: Auth LB change Nov 15

Correction.  *content  not contact.
--
Nicholas N. Mistry
work: 210.312.4806   mobile:210.452.5630

From: Nicholas Mistry <<email address hidden><mailto:<email address hidden>>>
Date: Wed, 9 Nov 2011 13:38:31 -0600
To: Jeff Highley <<email address hidden><mailto:<email address hidden>>>
Cc: Tom Hopkins <<email address hidden><mailto:<email address hidden>>>, Antony Messerli <<email address hidden><mailto:<email address hidden>>>, Tom Hopkins <<email address hidden><mailto:<email address hidden>>>, Ziad Sawalha <<email address hidden><mailto:<email address hidden>>>
Subject: Re: Auth LB change Nov 15

Jeff,
In the email I sent to Tom, I included requests for both the original endpoint and the redirect.     This "testing" is actually just a preliminary verification step, just to be sure we are getting back valid contact before trying the nova-client stuff.

Copying the content here for your review:

Alex,

I am trying to verify the JSON fixes in the auth2.0 staging environment, before trying novaclient.   Seems like something has changed and im now getting a 301 redirect and a 405 back.   Can you take a look into this?

Thanks

-N

MFV25BDF91:novatest nich3909$ curl -X POST https://auth.staging.us.ccp.rackspace.net/v2.0/tokens -d '{"auth":{"tenantName": "5801124", "passwordCredentials":{"username":"cp24c","password":"Jtester1"}}}' -H "Content-type: application/json" --verbose --insecure
* About to connect() to auth.staging.us.ccp.rackspace.net port 443 (#0)
*   Trying 10.13.75.159... connected
* successfully set certificate verify locations:
*   CAfile: /opt/local/share/curl/curl-ca-bundle.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-SHA
* Server certificate:
* subject: C=US; ST=Texas; O=Rackspace; OU=Chris Maier; CN=auth.staging.us.ccp.rackspace.net
* start date: 2011-09-15 19:18:47 GMT
* expire date: 2021-09-12 19:18:47 GMT
* common name: auth.staging.us.ccp.rackspace.net (matched)
* issuer: C=US; ST=Texas; L=San Antonio; O=Rackspace; OU=System Administration; CN=Rackspace Internal Root CA; <email address hidden><mailto:<email address hidden>>
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> POST /v2.0/tokens HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-apple-darwin10.8.0) libcurl/7.22.0 OpenSSL/1.0.0e zlib/1.2.5 libidn/1.22
> Host: auth.staging.us.ccp.rackspace.net
> Accept: */*
> Content-type: application/json
> Content-Length: 100
>
* upload completely sent off: 100out of 100 bytes
< HTTP/1.1 301 Moved Permanently
< Content-Type: text/html
< Date: Wed, 09 Nov 2011 17:49:44 GMT
< Location: https://ord.staging.idm.api.rackspace.com/cloud/v2.0/
< Connection: Keep-Alive
< Content-Length: 0
<
* Connection #0 to host auth.staging.us.ccp.rackspace.net left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):




MFV25BDF91:novatest nich3909$ curl -X POST https://ord.staging.idm.api.rackspace.com/cloud/v2.0/tokens -d '{"auth":{"tenantName": "5801124", "passwordCredentials":{"username":"cp24c","password":"Jtester1"}}}' -H "Content-type: application/json" --verbose --insecure
* About to connect() to ord.staging.idm.api.rackspace.com port 443 (#0)
*   Trying 10.12.89.50... connected
* successfully set certificate verify locations:
*   CAfile: /opt/local/share/curl/curl-ca-bundle.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using DHE-RSA-AES256-SHA
* Server certificate:
* subject: C=US; ST=Texas; O=Rackspace; OU=Justin Ellis; CN=auth.api.rackspace.com
* start date: 2011-04-07 19:31:30 GMT
* expire date: 2017-04-05 19:31:30 GMT
* common name: auth.api.rackspace.com (does not match 'ord.staging.idm.api.rackspace.com')
* issuer: C=US; ST=Texas; L=San Antonio; O=Rackspace; OU=System Administration; CN=Rackspace Internal Root CA; <email address hidden><mailto:<email address hidden>>
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> POST /cloud/v2.0/tokens HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-apple-darwin10.8.0) libcurl/7.22.0 OpenSSL/1.0.0e zlib/1.2.5 libidn/1.22
> Host: ord.staging.idm.api.rackspace.com
> Accept: */*
> Content-type: application/json
> Content-Length: 100
>
* upload completely sent off: 100out of 100 bytes
>>>* HANGS HERE FOR A BIT *<<<
< HTTP/1.1 405 Method Not Allowed
< Server: nginx/0.8.53
< Date: Wed, 09 Nov 2011 17:49:44 GMT
< Content-Type: text/plain;charset=UTF-8
< Connection: keep-alive
< X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 3.1 Java/Sun Microsystems Inc./1.6)
< Content-Length: 0
<
* Connection #0 to host ord.staging.idm.api.rackspace.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):



--



--
Nicholas N. Mistry
work: 210.312.4806   mobile:210.452.5630

From: Jeff Highley <<email address hidden><mailto:<email address hidden>>>
Date: Wed, 9 Nov 2011 13:26:12 -0600
To: Nicholas Mistry <<email address hidden><mailto:<email address hidden>>>, Antony Messerli <<email address hidden><mailto:<email address hidden>>>
Cc: Tom Hopkins <<email address hidden><mailto:<email address hidden>>>
Subject: Re: Auth LB change Nov 15

Any chance you can try your 'test' through the following endpoint instead -

https://ord.staging.idm.api.rackspace.com/cloud/v2.0/

This is where the redirection was pointing to, which has passed all the functional tests, so it will help us trouble shoot if something is not working correctly.

Thank you,

Jeff

From: Tom Hopkins <<email address hidden><mailto:<email address hidden>>>
Date: Wed, 9 Nov 2011 12:53:09 -0600
To: Jeff Highley <<email address hidden><mailto:<email address hidden>>>, Chris Maier <<email address hidden><mailto:<email address hidden>>>, Ravi Rachakonda <<email address hidden><mailto:<email address hidden>>>, Jenny Vo <<email address hidden><mailto:<email address hidden>>>, Sri Pasuparthi <<email address hidden><mailto:<email address hidden>>>, Vic Watkins <<email address hidden><mailto:<email address hidden>>>, Patty Santana <<email address hidden><mailto:<email address hidden>>>, Alex Silva <<email address hidden><mailto:<email address hidden>>>
Cc: Itari Ighoroje <<email address hidden><mailto:<email address hidden>>>, Chris Bohannon <<email address hidden><mailto:<email address hidden>>>, Glen Kuklewski <<email address hidden><mailto:<email address hidden>>>, Nicholas Mistry <<email address hidden><mailto:<email address hidden>>>, Antony Messerli <<email address hidden><mailto:<email address hidden>>>
Subject: RE: Auth LB change Nov 15

Adding Nicholas and Ant to this thread

Nicholas was executing a test against Cloud Auth 2.0 and the redirection to IDM caused a failure.


From: Jeff Highley
Sent: Wednesday, November 09, 2011 12:17 PM
To: Chris Maier; Ravi Rachakonda; Tom Hopkins; Jenny Vo; Sri Pasuparthi; Vic Watkins; Patty Santana; Alex Silva
Cc: Itari Ighoroje; Chris Bohannon; Glen Kuklewski
Subject: Re: Auth LB change Nov 15

For production, we can look into a SAN ssl cert, that has both rackspace.com and rackspacecloud.com to solve the host name mismatch issue.  I haven't used them before so not sure if they go on to both pieces of infrastructure or just the cloud side.  Anyone familiar with them?

This LB redirect is supposed to be an interim solution till we make some code changes so that when someone gets the versions on auth.api.rackspacecloud.com they don't see v2.0.  We will only publicly acknowledge (Nova documentation, communication to beta users, etc.)  the idm.api.rackspace.com/v2.0/.  The intent is to guarantee day 1 that everyone is going through the Global Auth router for v2.0.  So cost/effort of doing the above or any solution should be weighed.

Thanks,

Jeff

From: Chris Maier <<email address hidden><mailto:<email address hidden>>>
Date: Wed, 9 Nov 2011 09:06:08 -0600
To: Ravi Rachakonda <<email address hidden><mailto:<email address hidden>>>, Tom Hopkins <<email address hidden><mailto:<email address hidden>>>, Jenny Vo <<email address hidden><mailto:<email address hidden>>>, Sri Pasuparthi <<email address hidden><mailto:<email address hidden>>>, Vic Watkins <<email address hidden><mailto:<email address hidden>>>, Patty Santana <<email address hidden><mailto:<email address hidden>>>, Alex Silva <<email address hidden><mailto:<email address hidden>>>, Jeff Highley <<email address hidden><mailto:<email address hidden>>>
Subject: Re: Auth LB change Nov 15

Thank you for the feedback, the redirection part appears to be working.  However, we now appear to have SSL issues – the targets provided below are serving SSL certificates that are host mismatch for the names provided…

UK / London:
https://ord.auth.api.rackspacecloud.com/v1.1/

https://ord.auth.api.rackspacecloud.com/v2.0/


US:
https://auth.staging.us.ccp.rackspace.net/v1.1/

https://auth.staging.us.ccp.rackspace.net/v2.0/


We have been telling our developers to use: https://ssl.corp.rackspace.com/ to issue certificates for internal applications.  We also generally have the root CA from that URL loaded in to most of our trusted keystores.



For production, we are going to need to figure out a solution to this problem:

https://ord.idm.api.rackspace.com – since we are not cutting everything over and "auth.api.rackspace.com" will remain with the Cloud on its current IP, we need to fix the SSL certificate for Nov 15 as well.


Chris



From: Ravi Rachakonda <<email address hidden><mailto:<email address hidden>>>
Date: Tue, 8 Nov 2011 17:36:42 -0600
To: Tom Hopkins <<email address hidden><mailto:<email address hidden>>>, Jenny Vo <<email address hidden><mailto:<email address hidden>>>, Sri Pasuparthi <<email address hidden><mailto:<email address hidden>>>, Vic Watkins <<email address hidden><mailto:<email address hidden>>>, Patty Santana <<email address hidden><mailto:<email address hidden>>>, Chris Maier <<email address hidden><mailto:<email address hidden>>>, Alex Silva <<email address hidden><mailto:<email address hidden>>>, Jeff Highley <<email address hidden><mailto:<email address hidden>>>
Subject: RE: Auth LB change Nov 15

Tom,

Is the PDF showing the GTM (global) urls?

Thanks
Ravee
DevOps
________________________________
From: Ravi Rachakonda
Sent: Tuesday, November 08, 2011 5:33 PM
To: Tom Hopkins; Jenny Vo; Sri Pasuparthi; Vic Watkins; Patty Santana; Chris Maier; Alex Silva; Jeff Highley
Subject: RE: Auth LB change Nov 15
Urls for staging:

GA:
ord.staging.idm.api.rackspace.com
lon.staging.idm.api.rackspace.com

Foundation API:

ord.staging.rackidm.api.rackspace.com
lon.staging.rackidm.api.rackspace.com


Urls for Production:

GA:
ord.idm.api.rackspace.com     ---  US  ORD
dfw.idm.api.rackspace.com     ---  US  DFW

lon.idm.api.rackspace.com       --- UK     -> latest code is not yet deployed here. Will update once it is done



Foundation API:
ord.rackidm.api.rackspace.com  --- US  ORD
dfw.rackidm.api.rackspace.com  --- US DFW

lon.rackidm.api.rackspace.com  --- UK LON  -> latest code is not yet deployed here. Will update once it is done

Thanks
Ravee
DevOps
________________________________
From: Tom Hopkins
Sent: Tuesday, November 08, 2011 5:23 PM
To: Jenny Vo; Sri Pasuparthi; Ravi Rachakonda; Vic Watkins; Patty Santana; Chris Maier; Alex Silva; Jeff Highley
Subject: RE: Auth LB change Nov 15
Ravi,
Can you assist in correcting the URLs for GA idm?

From: Chris Maier
Sent: Tuesday, November 08, 2011 4:13 PM
To: Alex Silva; Tom Hopkins
Cc: Jenny Vo; Sri Pasuparthi; Ravi Rachakonda; Vic Watkins; Patty Santana
Subject: Re: Auth LB change Nov 15

So, I think I have a workable rule in US staging, however, no love from the URL provided for GA idm endpoint in DNS

Try clicking on these and let me know if this is the expected behavior


https://auth.staging.us.ccp.rackspace.net/v1.1/

https://auth.staging.us.ccp.rackspace.net/v2.0


Chris

From: Alex Silva <<email address hidden><mailto:<email address hidden>>>
Date: Tue, 8 Nov 2011 15:50:47 -0600
To: Tom Hopkins <<email address hidden><mailto:<email address hidden>>>
Cc: Jenny Vo <<email address hidden><mailto:<email address hidden>>>, Sri Pasuparthi <<email address hidden><mailto:<email address hidden>>>, Ravi Rachakonda <<email address hidden><mailto:<email address hidden>>>, Chris Maier <<email address hidden><mailto:<email address hidden>>>, Vic Watkins <<email address hidden><mailto:<email address hidden>>>, Patty Santana <<email address hidden><mailto:<email address hidden>>>
Subject: Re: Auth LB change Nov 15

Thanks Jenny!

On Nov 8, 2011, at 4:43 PM, Tom Hopkins wrote:

CC to Chris and Vic -

From: Tom Hopkins
Sent: Tuesday, November 08, 2011 3:42 PM
To: Jeff Highley; Jenny Vo; Sri Pasuparthi; Ravi Rachakonda; Alex Silva
Cc: Patty Santana
Subject: RE: Auth LB change Nov 15
Importance: High

Thanks Jeff

Alex and Jenny,
Can you help with the Cloud URLs?

From: Jeff Highley
Sent: Tuesday, November 08, 2011 3:40 PM
To: Tom Hopkins
Cc: Chris Maier; Buck Williams; Glen Kuklewski; Ann Steimel; Wendy Shepperd
Subject: Re: Auth LB change Nov 15

Tom,

I've filled in the Global Auth information with the details that I have.  Production GTMs are being configured, I don't expect this to change, but will let you know if it does.

Thanks,

Jeff

From: Tom Hopkins <<email address hidden><mailto:<email address hidden>>>
Date: Tue, 8 Nov 2011 15:35:31 -0600
To: Tom Hopkins <<email address hidden><mailto:<email address hidden>>>, Jeff Highley <<email address hidden><mailto:<email address hidden>>>
Cc: Chris Maier <<email address hidden><mailto:<email address hidden>>>, Buck Williams <<email address hidden><mailto:<email address hidden>>>, Glen Kuklewski <<email address hidden><mailto:<email address hidden>>>, Ann Steimel <<email address hidden><mailto:<email address hidden>>>, Wendy Shepperd <<email address hidden><mailto:<email address hidden>>>
Subject: RE: Auth LB change Nov 15


Creating the NEB and CCM tickets …

What are the correct URLs for all of the following?

Cloud US Staging



Cloud UK Staging



Cloud US Production

auth.api.rackspacecloud.com/v2.0/<http://auth.api.rackspacecloud.com/v2.0/>

Cloud UK Production



Global US Staging

 staging.idm.api.rackspace.com/cloud/v2.0/

Global UK Staging

lon.staging.idm.api.rackspace.com/cloud/v2.0/

Global US Production

idm.api.rackspace.com/v2.0/<http://idm.api.rackspace.com/v2.0/>

Global UK Production

 lon.idm.api.rackspace.com/v2.0/


Please advise ASAP.  Thanks

From: Tom Hopkins
Sent: Tuesday, November 08, 2011 3:28 PM
To: Jeff Highley
Cc: Chris Maier; Buck Williams; Glen Kuklewski; Ann Steimel; Wendy Shepperd
Subject: RE: Auth LB change Nov 15
Importance: High

All,
I talked with Chris just before receiving this.   He said they do need a CCM and it is undecided if they can fit this in.  This will require a NEB ticket for staging and a CCM for production.

I will open a NEB and CCM.   If we can be as specific as possible in the CCM it will help.  In this manner whomever it is assigned to can make the change without chasing us down.  This will help it get prioritized.

Is this description as detailed as we can get?
“ Apply a rule such that auth.api.rackspacecloud.com<http://auth.api.rackspacecloud.com> redirects /v2.0/ to idm.api.rackspace.com/v2.0/”<http://idm.api.rackspace.com/v2.0/”>

Tom

From: Jeff Highley
Sent: Tuesday, November 08, 2011 3:15 PM
To: Chris Maier
Cc: Buck Williams; Tom Hopkins; Glen Kuklewski
Subject: Re: Auth LB change

Chris,

Just wanted to check on this.  Any issues getting this into production on the 15th?

Thanks,

Jeff

From: Jeff Highley <<email address hidden><mailto:<email address hidden>>>
Date: Mon, 31 Oct 2011 11:01:00 -0500
To: Chris Maier <<email address hidden><mailto:<email address hidden>>>
Cc: Buck Williams <<email address hidden><mailto:<email address hidden>>>
Subject: Re: Auth LB change

Chris,

We need a rule on the auth.api.rackspacecloud.com<http://auth.api.rackspacecloud.com> that redirects /v2.0/ to idm.api.rackspace.com/v2.0/<http://idm.api.rackspace.com/v2.0/>.  No one should be able to go to auth.* v2.0 directly.  Open to other options on handling this.  Attached is a deck that explains this, this is the new approach in place of the dns flip.

Thank you,

Jeff

From: Buck Williams <<email address hidden><mailto:<email address hidden>>>
Date: Mon, 31 Oct 2011 10:44:36 -0500
To: Chris Maier <<email address hidden><mailto:<email address hidden>>>, Jeff Highley <<email address hidden><mailto:<email address hidden>>>
Subject: Auth LB change

Jeff,

Talking with Chris – his team owns the LB for Auth. The complexity of the change will determine what path we need to take.

Please let us know what the change is.

Thanks,
Buck