Yep, it's already set up through Gerrit and the openstack GitHub organization :) Sorry, was copy-paste fail on my part!
https://github.com/openstack/openstack-integration-tests Cheers! jay On Wed, Sep 21, 2011 at 3:15 PM, Joseph Heck <[email protected]> wrote: > 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
