Open Stack

On Wed, Nov 13, 2013 at 10:04:04AM -0600, Dolph Mathews wrote:
> I guarantee there's a few things I'm forgetting, but this is my collection
> of things we discussed at the summit and determined to be good things to
> pursue during the icehouse timeframe. The contents represent a high level
> mix of etherpad conclusions and hallway meetings.
> 
> https://gist.github.com/dolph/7366031

Looks good, but I have some feedback on items which were discussed (either
in the delegation session or in the hallway with ayoung/jlennox), and are
high priority for Heat, I don't see these captured in the page above:

Delegation:
- Need a way to create a secret derived from a trust (natively, not via
  ec2tokens extension), and it needs to be configurable such that it
  won't expire, or has a very long expiry time. ayoung mentioned a
  credential mechanism, but I'm not sure which BP he was referring to, so
  clarification appreciated.

Client:
- We need a way to get the role-tenant pairs (not just the tenant-less
  role list) into the request context, so we can correctly scope API
  requests.  I raised this bug:

  https://bugs.launchpad.net/python-keystoneclient/+bug/1250982

  Related to this thread (reminder - which you said you'd respond to ;):

  http://lists.openstack.org/pipermail/openstack-dev/2013-November/018201.html

  This topic came up again today related to tenant-scoped nova flavors:

  http://lists.openstack.org/pipermail/openstack-dev/2013-November/019099.html

  Closely related to this bug I think:

  https://bugs.launchpad.net/keystone/+bug/968696

  I'd welcome discussion on how we solve the request-scoping issue
  openstack-wide, currently I'm thinking we need the role-tenant pairs (and
  probably role-domain pairs) in the request context, so we can correctly
  filter in the model_query when querying the DB while servicing the
  API request.

Thanks,

Steve