Open Stack

> > Maybe I'm missing something fundamental, might make sense to walk
> > through a hypothetical case ...
> > 
> > - Bob has two instances, webserver & DB both of type m1.medium
> >
> So Bob is a member of tenant "T1", and creates a stack (associated
> with T1), which contains the instances
> 
> > - Alice has a single instance, mailserver of type m1.medium
> >
> > - Bob and Alice are associated with different tenants
> 
> So she is a member of tenant T2
>  
> > - Heat creates 3 new proxy users, webserver_user, DB_user &
> >   mailserver_user
> 
> So webserver_user, DB_user are in T1, mailserver_user is in T2


OK, cool, so that's basically the opposite of what I understood by
"separate tenant" idea mooted earlier. 

As long as the generated {instance}_users are always associated with
the same tenant as the original instance owner then, yep, no mapping
is necessarily required, as long as everything we need to do after
the fact is scoped at the tenant level (e.g. there's no requirement
for per-user chargeback for the {instance}_user's API calls, mapping
back to the original user's identity).

I'm not sure what the "seperate tenant" idea was aiming to achieve
from a lock-down perspective, given that the limited-karma role
would be associated with the user as the opposed the tenant. Anyway
it seems that idea has fallen by the wayside ...

Cheers,
Eoghan


 
> T1 will only have visibility (and hence be able to publish metric
> data for)
> stacks owned by T1, so webserver_user, DB_user can only publish
> metric data
> for Bobs stack(s)/instances, and vice-versa for T2
>  
> > - cfn-push-stats assumes the identity of {instance}_user when
> >   reporting metrics from within each instance
> > 
> > - Bob calls GetMetricStatistics with his original identity,
> >   requesting dimension InstanceType=m1.medium
> >
> > - we expect only the metrics for webserver & DB to be aggregated,
> >   but not mailserver (or?)
> >
> Bob can only see watch rules (and hence metric-data) for stacks owned
> by T1,
> so we query the DB and get results for webserver & DB (not mailserver
> as
> it's owned by T2), which I think is what is expected.
> 
> That said, the current heat cloudwatch implementation doesn't support
> query/filter by dimension, or GetMetricStatistics (yet), and we do
> need to
> improve our DB schema to allow this to be done efficiently.  The
> basic
> mapping describe above should remain the same though (maybe will get
> more
> complex when we decouple heat orchestration and cloudwatch..)
> 
> Steve
>