Hi Juca
So just to be clear, this means that there is no server side validation to ensure the user
is able to read from/write to the supplied tenant? This would have to be handled in the
client aswell?
Regards
Gary
----- Original Message -----
(this email uses the Hawkular naming as proposed by lponce)
It seems there has been some confusion about the situation around the
multi tenancy in Hawkular Services. Most of what was discussed today on
IRC was already discussed in a way or another before, but here's a
summary of the previous discussions + what was discussed today on IRC:
Hawkular Services, except Agent:
* Tenant data is not going to be derived from Hawkular Services Auth Data.
* Tenancy is to be determined by the client and sent to Hawkular
Services via the "Hawkular-Tenant" header.
* As tenancy is not to be determined at Hawkular Services, there's no
point in having Accounts anymore. Most, if not all, components have
already a "remove Accounts dependency" JIRA. If you need help on this
task, let me know
* Removing Accounts != removing tenancy support. Multi tenancy is still
a requirement for Hawkular Services!
* If the tenant is not provided (ie: Hawkular-Tenant HTTP header is
non-existent or invalid), your endpoint should return a "400 - Bad Request".
* We might still have multi tenancy on Hawkular. But that's irrelevant
for your component.
Agent and non-Hawkular Services:
* Agent will allow the user to set a tenant on standalone.xml . By
default, it will be set to "hawkular"
* The Hawkular Ruby Gem, used by MiQ, will use tenancy information from
MiQ when available. By default, it will be set to "hawkular"
* OpenShift already sends Hawkular-Tenant to Hawkular Metrics
- Juca.
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev