Can we clone this into the Openstack repo so that it's clear: a) there is a central set of openstack integration and functional tests b) that it is THE place to add in common, cross-cutting tests
I don't really care which setup we use as the OpenStack project - Soren's is fine, just needs to be central and open, and ideally have a set of approvers for adding tests through Gerrit (I suggest we just start with Soren and grow it from there) -joe On Sep 21, 2011, at 11:31 AM, Jay Pipes wrote: > All good, Jesse. > > I think it would be appropriate to either create a new smoketest that > stresses the flow you outline below, or add a new integration test to > here: > > https://github.com/sorenh/openstack-integration-tests > > Otherwise, testing will by nature be a manual process.... > > Cheers! > -jay > > On Wed, Sep 21, 2011 at 4:16 AM, Jesse Andrews <[email protected]> wrote: >> As part of the release meeting today we talked about getting a preview >> release of keystone + dash + diablo working asap. This is an attempt to >> summarize the major interfaces. Ziad and team have an identity guide (they >> are updating and can share asap) to help flush this out. >> >> Here is what I see needs implemented to make Dash + Nova + Keystone work >> together. This is a subset of the auth spec (what Ziad & team are working >> to support Diablo as these are the contracts between those services) >> >> 1. CREATE TOKEN: (enduser api) POST /v2.0/tokens >> post data: >> https://github.com/openstack/keystone/blob/master/keystone/content/common/samples/auth_credentials.json >> response: >> https://github.com/openstack/keystone/blob/master/keystone/content/common/samples/auth.json >> >> 2. VALIDATE TOKEN: (admin api) GET >> /v2.0/tokens/(token)?[belongs_to=(tenant_id)] >> response: >> https://github.com/openstack/keystone/blob/master/keystone/content/common/samples/validatetoken.json >> >> 3. TENANTS FOR TOKEN: (user api) GET /v2.0/tenants >> returns: >> https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/docbkx/samples/tenants.json >> >> These 3 APIs are the meat of the keystone auth api (disregarding CRUD >> operations for users/tenants) >> >> Flow: >> >> * user visits a web console to login to openstack >> * dashboard uses keystone to authenticate (dashboard has no internal user >> system, and shouldn't store username/password in session/shared state) >> * since there can be a many to many relationship between users and tenants, >> the user might need to specify the tenant they want to operate on before >> talking with services like nova/glance/... >> * A service like NOVA need to validate (via http proxy or middleware) the >> token and return a USER, TENANT (previously known as a project in nova), and >> a list of roles. >> >> Notes: >> >> * a tenant is a "project" in nova and an "account" in swift. Think of it as >> the entity that "owns" the resources. >> * a user is the acting entity. >> * while keystone implements many-to-many tenant/user support, services >> should support many-to-many, one-to-many, one-to-one - as the API makes no >> assumptions about the hierarchical nature of the users/tenants >> * when getting the response to the "create unscoped token", I write that it >> returns "stuff". While it technically returns the roles, serviceCatalog, >> userinfo (same structure as for the scoped token), it isn't guaranteed to be >> the complete list of roles/endpoints for every tenant the user is a member >> of. >> * since the goal of the dashboard is to toggle visibility/functionality >> based on capabilities presented in the service catalog, we ask for a scoped >> token that has the capabilities for the tenant / user pair. >> * I use nova as my example but the approach is generalized. >> * crud operations for users/tenants exists both in "keystone-manage" and api >> calls. While dashboard has had user management capabilities in the past, we >> might rely on command line user management for the first release of the >> preview. >> * mistakes in this summary are mine (please correct me)… up until a few >> hours ago I had assumed the relationship betweens tenants/users and tokens >> was subtly different. >> >> >> >> >> >> >> >> ps. The swimlane (sequence diagram) was generated with sdedit (sourceforge) >> and is attached for patches :) >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : [email protected] >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> >> > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
