Hi Marcel, 2012/1/11 Marcel Offermans <[email protected]>: > tl;dr -> I agree with the current implementation, necessary only when we run > in a multi tenant container > > First of all, thanks Bram for extending the documentation > at http://www.amdatu.org/confluence/display/Amdatu/Amdatu+Core+Tenant. After > reading it, I have some concerns about visibility that I wanted to discuss.
Thanks (again) for feedback and sorry for a slow reply. I am a little "under the wheather" :( I am struggeling a little with these requirements. On the one hand some things are (or should be) given / implicit / generic, while on the other hand that may not be as apparent to stakeholders. > Let me start with the requirements. I agree with FREQ1 to 4, I'm not too > sure about including 5 here. To me, management and monitoring is an "aspect" > that you can enable for the whole platform (or not) if you need it. On the > one hand, you could therefore argue that FREQ5 should be mentioned here, on > the other hand, by using OSGi services and Configuration Admin, making > multi-tenancy "manageable" can implicitly always be done. Therefore, I would > argue that we do not explicitly mention this as a functional requirement for > every project that we do, but instead cover this when designing our > management and monitoring subproject. A perfect example :) I am not sure it is just an aspect. A particular one at the very least, because it is not just about the configuration of the multi-tenancy mechanism itself but also the application itself. Eg. I don't what just a ConfigAdmin/Tenant/logging/performance JMX bean (JMX just as an example) but I want it to be able to "scope" to a tenant. I agree that defining that a a seperate package/project makes sense, but I also think we at least need to have some idea of how this works before we can commit to the entire multi-tenancy mechanism at all. > Similarly, NFREQ1 and 5 to me are "global requirements" that apply to our > whole platform (and subprojects). We should probably put them on a separate > page. Agreed, I think it is a good idea to introduce these as "architectural guidelines" that apply to all design/implementation choices. Again, just trying to make them explicit here to get a feel for work and deliverables. > Back to visibility. > > First the part that I agree about: scoping visibility of tenant specific > services to just that tenant. That makes sense, you don't want tenant A to > invoke a service that was scoped to tenant B. > > I'm a bit hesitant about platform vs application scope and the VUC1 to 5 use > cases: > > Let's take the ConfigurationAdmin example you start with in VUC1: > > In the "normal" (no tenants) OSGi scenario, having only one single > ConfigurationAdmin is just fine. By design, it has different configurations > for different service.pid's, which nicely scopes each configuration to its > own managed service. More in general, I am very hesitant to introduce any > form of scoping in this scenario, because I don't think it's needed. True and acceptable as long as we do not have the ambition to scope applications (without tenants). Note that one could envision two different applications being provisioned onto one management agent where both applications use UserAdmin, but they must not be shared. The tenant scoping mechanism could also work in this case if we add named logical scoping based on amdatu.application. eg somethying like: ------------------------ objectClass = org.osgi.service.log.LogService service.id = 161 amdatu.tenant = tenant1 amdatu.application = app1 ------------------------ Now even without tenants you still have application scoping. Not saying this is a required use-case but I think we need to discuss and decide on that. For now this is just background on what I mean with "application scope" as something that covers all tenant instances of an application but NOT platform (or another app). Whether implicit or explicit. > In the "tenant" scenario, we of course do have a ConfigurationAdmin per > tenant, and here we run into a visibility issue if we also want to have a > "platform" CA because: > 1) With the filters we have now (show all services that have a tenant id > that matches mine PLUS all services that do not have a tenant id at all) > that would expose two CAs to a tenant (this is VUC1, right?). Right, this is why in the current code I removed the "PLUS all services that do not have a tenant id at all" with a (configurable) but fixed list of allowed services. Currently just LogService and JaxRSSpi. > 2) Also, for other platform services, unaware of tenants, that would expose > ALL CAs (this comes close to what you describe in VUC2). True > The scenario in VUC4 has two variations: > 1) The application uses another LogService implementation, therefore a > different bundle, which means we can "adapt" that bundle to be tenant aware. Yes, but.. 1) there is a (potential) requirement for being able to use a reuse a single service(registration) (of an expensive) service over all tenants. 2) still any MT unaware platform service would see it unless we intervene. Eg by wrapping all platform components in a platform bundlecontext and/or extending the mechanism with hooks. > 2) The application uses a single LogService implementation, which means this > bundle should provide separate services for both the tentants and the > platform. Yes, but still any MT unaware platform service would see it unless we intervene. Eg by wrapping all platform components in a platform bundlecontext and/or extending the mechanism with hooks. > With VUC5 do you mean a LogService that uses the tenant aware bundle > activator to ensure that each tenant has its own LogService? By default, > such services should only be visible to the tenant they belong to. You run > into the issue that if you have a "platform" service that is not aware of > tenants, that it will see all LogServices (like explained above in tenant > scenario, option 2). Is that what you mean here? Correct > My summary so far: > > If we do not have tenants, we do not need any special scoping. Unless we want to scope apps as well > If we do have tenants, we might want to introduce some kind of notion of a > "platform" scope. And "application" scope. Meaning that tenant specific component must not see certain platform services (eg. ManagedService), but also platform must not see specific tenant services (eg. ManagedService). > Actually, at this point I am looking at the latest code changes, and see > that you pretty much implemented this by allowing three different scopes for > a tenant aware bundle: > 1) "platform", implemented as a "special" tenant (similarly to how the > framework is a special bundle in OSGi) Yes, but for isolation to work we must wrap every platform bundle in this scope. Otherwise a non wrapped standard bundle may react to tenant services. > 2) "tenant", meaning a bundle produces and consumes services that are tenant > aware Yes, but but this does NOT provide an application scoped (singleton) service solution. Thus we don't have the !platform option which is something that may be usefull to application from a functional and/or performance perspective. > 3) "both", or 1+2, meaning you get services for all tenants, PLUS a special > "platform" one. Yes, but still no application scope. > As far as I can see, this addresses all issues mentioned above, so I don't > think I have any concerns with the current implementation (and we maybe only > need to clarify when to and when not to use scoping). And really like to challenge that with regard to the application scope some more :) Again, even if we wont ever support multiple logically scoped application, there seem to be some subtle differences between service intended to act within the different scopes. I'll try and cook up some more specific examples. grz Bram > Greetings, Marcel > > > _______________________________________________ > Amdatu-developers mailing list > [email protected] > http://lists.amdatu.org/mailman/listinfo/amdatu-developers > _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
