Open Stack

On 11/24/2015 10:50 AM, Henry Nash wrote:
> Some good ideas here, Adam.  I would think that some of the real “diagnostic APIs” might only be available via keystone-manage, rather than an exposed API.


I'd like to get away from the assumption that you have physical access 
to the machines to do operations like these.  The "config in the 
database" approach means that this stuff is going to be far more 
dispersed.  So, while and Admin-only API might be appropriate, it should 
still be remotely accessable.

>
> Henry
>> On 24 Nov 2015, at 03:07, Adam Young <ayoung at redhat.com> wrote:
>>
>> Figuring out what is or is not going to work when a user tries to perform an operation in OpenStack can be frustrating.  I've had a few people ask me for help specifically for configuring LDAP.  With Federation , things will get better.  I mean Worse.
>>
>> What kind of diagnostic tooling do we need?  I know the basics:
>>
>> If I have a known good user in LDAP, can they

Looks like I over edited here.  Should have read "can they authenticate 
using that account."


>>   .  This is the first thing, and it can be done by asking for an unscoped token.
>>
>> Once they have an unscoped token, can they get a scoped token?  Same as before, but adding the project ID or domain name/project name to the token request.
>>
>> OK...what about if the users don't want to give you their password? With LDAP, we can do OpenStack user show to see if the user is in the backend.  With Federation...not so much.
>>
>>
>> Recently, I was trying to debug an issue where a server create failed due to errors in the service to service communication; Neutron could not make the call it needed to Nova due to the service user not having the Admin role.  The thing is, the service user was not an actual user, but rather a Service principal authenticate via Kerberos.  I think this is an indicator of the things to come.
>>
>>
>> We need an API that will show, given as set of post-validated credentials, communicated via Federation, what will the token validation response look like.  We'll need user domain id, user id, project, roles, and service catalog.
>>
>> What else do we need diagnostically?  I know that setting up LDAP is especially tricky, and multiple LDAP backends, added in live config, using the Database backend, is going to be particularly painful to troubleshoot.  We need to be able to start with:
>>
>> Is the LDAP account used to fetch users working properly?
>> If not, what do  the Actual LDAP queries look like?  Ideally, something we could pipe right into ldapsearch to confirm from the command line.
>>
>> Then, take a real user, and act like they are trying to authenticate, list the groups they should have, the roles they would be assigned, and the service catalog.  We need this stuff piece by piece, to be able to troubleshoot.
>>
>> Is there anything I am missing here? We are not going to have the luxury of cranking up logging and looking at data in a live running server;  My friend Hippa Sarbanes-Oxley has told me point blank that is a no-go.
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev