Hi Felix
On Mon, Nov 12, 2012 at 10:55 AM, Felix Meschberger <fmesc...@adobe.com> wrote:
> Hi Julian
>
> Am 12.11.2012 um 10:33 schrieb Julian Sedding:
>
>> Hi Amit
>>
>> Thanks for taking a stab at multi-tenancy support. I have looked at
>> your patch and I re-read Felix' draft spec on the wiki[0].
>>
>> The code and the spec leave me with some thoughts. Sorry for the
>> lengthy reply, the thoughts are still pretty fresh in my mind.
>>
>> The spec states that multi-tenancy support is targeted to a hosted
>> scenario, where several Sling applications (let's simplify to
>> websites) run side by side.
>
> Yes, that was an initial though. But running different applications for
> different tenants is a tricky thing because the Java platform does not allow
> use to properly sandbox those applications and thus to prevent on application
> from starving another application.
>
> For now, only the TenantProvider/Tenant part is implemented and we did not
> consider the tenant-specific ResourceResolution yet.
So if you are omitting the main feature of tenants as described in
"Problem Scope" in the draft specification[0] ("Here you might want to
separate the resolution of resources for each client."), why call the
feature "multi-tenancy support", why reference the specification and
why implement the interfaces described in the specification? The
problem scope statement does not mention the requirement to sand-box
applications. While I understand that sand-boxing may be desirable (or
even required) for some use-cases, it certainly is not necessary for
every use-case (e.g. one company runs several brand web-sites on the
same Sling instance).
Multi-tenancy support can certainly encompass a multitude of features
that are provided "per-tenant". Script resolution is one of them,
tenant-specific users may be another one. Unfortunately the discussion
of what "multi-tenancy support" should mean in Sling has not happened
(yet?) on this mailing list.
[0] https://cwiki.apache.org/SLING/multitenancy-support.html
>
>> I think this can easily be extended to
>> cases where a large corporation runs websites of several brands on the
>> same Sling instance. Assuming our brands are "banana", "kiwi" and
>> "lemon", we'd have a content structure like this:
>>
>> "tenants": {
>> "banana": { ... },
>> "kiwi": { ... },
>> "lemon": { ... }
>> }
>>
>> The main purpose of multi-tenancy support (as per my interpretation of
>> the spec) is to be able to use different rendering scripts for
>> different tenants, which is expressed via the concept of the
>> ResourceResolver(Factory)#searchPath.
>>
>> Assuming we want the "banana" and "lemon" websites to be rendered with
>> the "yellow" application and the "kiwi" website with the "green"
>> application (and assuming we don't use CSS for this...), we might want
>> our rendering scripts organized like this:
>>
>> "apps": {
>> "yellow": { ... },
>> "green": { ... },
>> "shared": { ... }
>> }
>>
>> As far as I can see, the currently committed code doesn't enhance the
>> search paths yet. However, it looks like it is intended that tenants
>> get resolved mapped from the paths of any of the following:
>> * user home path (e.g. /home/users/banana/julian; this is kind of CQ
>> specific, afaik jackrabbit still uses the system workspace for users
>> by default, so there's no /home/users)
>> * resource path (e.g. /tenants/kiwi)
>>
>> So if I request the page /tenants/kiwi logged in as julian, I could
>> get two different resolutions, depending on whether the implementation
>> adapts the Resource (/tenants/kiwi), which leads to the tenant "green"
>> or the ResourceResolver backed by the user julian, which leads to the
>> tenant "yellow".
>
> I think if you are logged in, you are being run under the hood of the tenant
> to which you as the logged in user belong. So in your case, the tenant would
> be "green".
No, it would be "yellow". But that's not the point, the point is that
rendering the same content might lead to different script resolution.
This feels very awkward to me.
>
> As a member of the "green" tenant you might not even have access the kiwi
> tree. In which case, there is no reason to assume the request resource path
> to be the tenant to consider.
I would avoid mixing up the concept of tenants and access control.
They are certainly complementary, but the user julian may equally well
have access to /tenants/kiwi. In that case we need to answer the
question if the tenant is identified by the logged in user or by the
content tree being rendered.
>
> As a consequence, I agree, that the anonymous user by itself is not running
> under the hood of a tenant.
>
>
>>
>> Considering that most requests to websites are "anonymous", I suggest
>> that multi-tenancy support should only care about the resource being
>> requested, not about the requesting user, This also guarantees
>> consistent results for rendering.
>
> This (and the following) raise good questions. And we are not ready to answer
> them (yet) and we are not even considering per-tenant applications (for above
> stated reasons).
I hope that we can approach answering some of those questions on the
mailing list.
>
> So we left out tenant-awareness of the ResourceResolver by intent.
>
>>
>> Looking at the problem from this angle, script resolution (i.e.
>> looking up the resource type relative path) needs depend on the
>> location of the requested resource. This in turn rules out the
>> possibility to adapt a ResourceResolver to a tenant, because the RR
>> does not have a path. Also setting injecting the search path into the
>> RR is troublesome, because /tenants/kiwi might include resources from
>> /tenants/banana by reference and would thus need to trigger the
>> "yellow" rendering for these includes (or are there arguments against
>> this?).
>>
>> Given the above thoughts, I would allow adapting a Resource to a
>> Tenant. The Tenant would correspond to the Resource itself or to an
>> ancestor of the Resource (i.e. hierarchical inheritance). Since the
>> tenant would thus correspond to a Resource, maybe it makes sense to
>> have the Tenant interface extend from Resource. If no Tenants are
>> configured, the attempt to adapt a Resource to a tenant may return
>> null or a default Tenant, which is rooted at the resource tree's root
>> (maybe this would simplify implementations).
>
> Even though a Tenant may correspond a Resource (which is wrong, because at
> best a Resource corresponds to a Tenant) this does not imply a Tenant is a
> Resource. Because this is an implementation detail of implementing the Tenant
> interface. The Tenant interface is just representing a concept of a
> collection of users sharing some common setup.
I am describing a possible approach on how identification of tenants
could work IMO, so how can you say that it is wrong? I maintain that
given such an implementation, a Tenant may correspond to a Resource
(I'd call it the Tenant's root resource) and a Resource may *belong*
to a Tenant (i.e. it is a descendant resource of the Tenant's root
resource).
>
>>
>> All of this raises the question of the consistency of search paths, as
>> the ResourceResolver cannot convey tenant specific search paths,
>> however the script resolution would need to depend upon tenant
>> specific search paths. To me it seems that multi-tenancy support might
>> require the extension of some sling concepts. This extension could
>> (and should IMHO) be implemented as a hook, which allows to manipulate
>> script resolution. Having such a hook should decouple the
>> multi-tenancy implementation from the core of sling and possibly allow
>> for alternative implementations.
>
> That's another reason why we won't go for tenant-aware script resolution yet.
> This whole thing cannot and should not be simply backed into the existing
> implementations. Your stated reasons are one part of this, another part is
> bloating the existing implementations and making them more complex.
So what exactly does the "multi-tenancy support" that is currently
being developed do? What value does it provide? Sorry, given that you
state that the script resolution won't be implemented (unless you
eventually decide to bloat the core), I do not understand what you are
trying to achieve.
>
> The current idea is just:
>
> * A ResourceResolver representing a user (just like JCR Session does) can be
> adapted to a Tenant to which the user "belongs".
Given the concerns I laid out a ResourceResolver cannot (and should
not) be adapted to a Tenant.
> * A Resource can be adapted to a Tenant under the assumption that the
> respective Resource belongs to one of the Tenant's data areas in the
> repository.
IMO only this assumption makes sense and I would therefore base an
implementation entirely on this assumption.
This leaves us with the *Request as the final important object. As a
request in Sling is always bound to a Resource, I would say argue that
adapting a *Request to a Tenant would also be fine, as long as it is
implemented as slingRequest.getResource().adaptTo(Tenant.class).
Regards
Julian
>
> Hope this helps.
>
> Regards
> Felix
>
>>
>> WDYT?
>>
>> Regards
>> Julian
>>
>> [0] https://cwiki.apache.org/SLING/multitenancy-support.html
>>
>>
>> On Mon, Nov 12, 2012 at 3:35 AM, Amit.. Gupta. <amitg...@adobe.com> wrote:
>>> Thanks Felix.
>>>
>>> I will work on the web console plugin.
>>>
>>> Thanks,
>>> Amit
>>>
>>> -----Original Message-----
>>> From: Felix Meschberger [mailto:fmesc...@adobe.com]
>>> Sent: 10 November 2012 04:23
>>> To: users@sling.apache.org
>>> Subject: Re: Multi-tenancy support in Sling - SLING-2656
>>>
>>> Hi Amit
>>>
>>> Thanks alot. I have applied your patch with some changes (see SLING-2656
>>> for details). I placed it as th extensions/tenant module in the contrib
>>> section for now. As of now it only provides the Tenant API but no
>>> integration with the rest in Sling. As such it is of use mainly to
>>> multi-tenancy aware uses.
>>>
>>> I think we should just provide read access through the TenantProvider and
>>> leave management (create, update, delete) to some administrative tooling;
>>> e.g. a web console plugin.
>>>
>>> I also removed the default configuration which does not relate to Sling.
>>>
>>> Would you be able to come up with a Web Console Plugin for management ?
>>>
>>> Regards
>>> Felix
>>>
>>> Am 08.11.2012 um 11:03 schrieb Amit.. Gupta.:
>>>
>>>> Hi All,
>>>>
>>>> I have created an issue [0] to track support for multi-tenancy in sling.
>>>>
>>>> I have also added a first cut implementation that provides basic building
>>>> blocks [1]
>>>>
>>>> [1] provides following
>>>>
>>>> * Tenant and TenantProvider abstraction at sling
>>>>
>>>> * Basic JCR based TenantProvider
>>>>
>>>> * An adapter factory to adapt resourceResolver to tenant, based on
>>>> logged in user
>>>>
>>>> TODO:
>>>>
>>>> * externalize the logic of identifying tenant based on logged in
>>>> User.
>>>>
>>>> * Add support to resolve resource to a tenant, for use cases where
>>>> there is no logged in user and execution is happening in some admin
>>>> context. i.e. observation listener.
>>>>
>>>> With above basic support, we can later add support for new Tenant Aware
>>>> JcrResourceResolver.
>>>>
>>>> Please comment on the patch/issue.
>>>>
>>>> Thanks,
>>>> Amit
>>>> [0] https://issues.apache.org/jira/browse/SLING-2656
>>>> [1] https://github.com/amitxlnc/sling/compare/mt
>>>>
>>>>
>>>>
>>>>
>>>
>
