Open Stack

On Thu, Oct 11, 2012 at 07:15:31AM -0400, Eoghan Glynn wrote:
> > > I'm struggling with the separate tenant idea, as there doesn't seem
> > > to be
> > > a way of recovering the original identity (which presumably you
> > > would
> > > need when querying the metrics in you use-case, or just
> > > auditing/billing
> > > etc. in the general case).
> > 
> > So I can see this being a problem generally, but within the limited
> > heat use-case, we simply have to enforce one INSTACE_USER for every
> > instance, and map the INSTANCE_USER to the actual instance resource
> > internally. Non-ideal though..
> 
> 
> Wouldn't Heat need to map to both the instance *and* the original
> owner/tenant associated with the instance?

Realised my previous reply didn't address this point;

So as described in my previous reply, each (unique) instance is associated
with exactly one stack, which is associated with exactly one owner/tenant

Metrics are internally associated with a stack, so once the metric data is
published, we don't actually care anymore where it came from.

This ties back into my previous comment about "internal management
complexity", we'd need to do some/all of the following if the proxy users
were in a separate tenant:
- Map proxy users to an instance (maybe just create the user with the uuid
  of the instance)
- Maintain a lookup table (or look up in the database, accross all tenants)
  of instance IDs->stacks
- Or have the instance know what stack it belongs to, and pass that as a
  dimension to the metric, then validate this during PutMetricData
- Allow some sort of cross-tenant trust/acl to allow metric data to be
  published from the "proxy tenant" to each of the stack-owning tenants
  (this breaks our current internal per-tenant topolgy and context-based
  separation

All in all, I think this approach is fundamentally too complex, so I think
we are better sticking to keeping all of the "real" and "proxy" users in the
same tenant, then working out a manageable way to lock-down the proxy users
such that things remain secure.

Steve