[Hawkular-dev] Looking for a first project to integrate accounts

[Lukas Krejci]

Sorry for a long and slightly confused email - I am probably too
ingrained with the current design to understand how this should work.

----- Original Message -----
> From: "Juraci Paixão Kröhling" <jpkroehling at redhat.com>
> To: "Lukas Krejci" <lkrejci at redhat.com>, "Discussions around Hawkular development" <hawkular-dev at lists.jboss.org>
> Sent: Tuesday, 21 April, 2015 2:29:28 PM
> Subject: Re: [Hawkular-dev] Looking for a first project to integrate accounts
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 04/21/2015 02:07 PM, Lukas Krejci wrote:
> > In inventory, we have a simple concept of tenants, environments and
> > resources, where tenants are unique and share no information and
> > environments model the usual split of the infrastructure into dev,
> > testing, production, et al.
> > 
> > How would you change that model to play nicely with the accounts
> > concepts of users and organizations?
> 
> The "persona" model was made with *our* concept of tenant in mind. So,
> a tenant could be either a real person or an organization, depending
> on which persona is currently selected on the UI (or which header was
> sent via curl). So, you could safely take a persona as the tenant.
> 

Is sharing of information possible between personas? It is not possible
in inventory between tenants currently so this is the part where I
struggle a bit.

You can imagine the inventory's tenants as "access points" to disjoint
subgraphs in the inventory. You only can access any data if you know
your tenant. Also, and possibly more importantly, no entity in
inventory is required to have a "globally" unique identifier. The only 
thing unique is the path to the entity, starting at the tenant, then down
the environment, etc.

So if a user is a tenant they will not be able to even reference data
from other tenants.

I guess the my main struggle is that the inventory is modelled after
a "physical" layout of the monitoring data - data belongs to some tenant
and can be further classified/narrowed down by the environment, etc.

In accounts, users/orgs/personas are very fluid concepts that can inherit
from each other, etc. while the classification of the data they access
is not that fluid.

Or am I completely missing the point here? (given my confusion right now,
that's more than likely :) ).

> If you also use the "Resource" concept in Account's side, you could
> also have a way to display resources from a sub-tenant to the parent
> (ie: from "Acme Financial" to "Acme, Inc").
> 
> > IMHO replacing inventory's tenants with accounts' organizations
> > might be a way forward but I am not sure. If it was the case, how
> > would you envision syncing the organization info between accounts
> > and inventory?
> 
> I think the inventory needs only to know what's the current tenant,
> and leave the permissions part to the accounts API. If there's
> something you might need to accomplish a particular task, we could add
> this as a feature to the accounts part.
>

Inventory's tenant is a crucial part to be able to address any entity.
So "knowing a current tenant" to check for permissions is quite ok, but
I am not sure I can "just know the current tenant" to be able to address
the data.
 
I.e. 2 users are supposed to access data from agent "A" in environment
"staging" for "Acme, Inc.", while a third user is supposed to access data
from agent "A" in environment "staging" for "Redhat, Inc."

I suppose that our model should allow for more organizations (in a SaaS
sense, not accounts sense) to have the environment called "staging" and
that their agents should be independent.

Remember that inventory doesn't have a unique ID of the "staging"
environments for the particular organizations. Currently this is resolved
by having a set of tenants that are required to have unique names
and that you can use to start composing your path to the agents, i.e.
"Acme/staging/A" or "Redhat/staging/A".

If persona is a tenant, how would that work?

> - - Juca.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQEcBAEBCAAGBQJVNkKoAAoJECKM1e+fkPrXtOcH/0LQiJv13ImuDSQF1+jkNbll
> P5t0zgxkCYs/2jsHD5KVGCc6lsq0HKfDjNv6/oqurNZyrUP0u5ATZxt2HDYxtrjm
> IYugq7Kg1P64eLwjXaVD7/WFaOaR8np4EXhd6OtKjfz8DyD1GSl8fTRQPGelK+ff
> gi+PEFbhMEkHkzG3TL2zhciBvueeS+TT+LH/bOnHX49gC826ABjK5LDN+YROPE/a
> ezytelXVkFyzyKBZjA31baHCAyr3G1qgA7Rq5Dg24VHUYgIRdg2O/ado2VhRTmPL
> Hw5hk+5BpS5m1tkEw9sFQPiCXKvPD0okJZcd6KzATyu0pJYsMNOxXfc42fOkOZI=
> =85NR
> -----END PGP SIGNATURE-----
>