2012/1/12 Marcel Offermans <[email protected]>: > On Jan 12, 2012, at 14:45 PM, Bram de Kruijff wrote: > > 2012/1/11 Marcel Offermans <[email protected]>: > > > 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. > > If you want to be able to "scope" to a tenant (even though I'm not 100% sure > what that means exactly), I would then mention that as a requirement > instead. Now it sounds like you're saying (and I'll generalize what you're > saying a bit for the sake of my argument): > > I want feature A to be manageable, which are really two separate > requirements to me: "I want feature A" and "I decide that feature A should > be accessible via management". And I'm arguing that the first is a > requirement for this project, the second is a requirement for our management > and monitoring system (that you can choose what features of a project can be > made manageable).
Fair enough :) > For a start, can you elaborate what "scoping to a tenant" means? With scoping to a tenant I mean "the world according to that a specific tenant". So if I ask for all services I get all services accessible to that tenant. If I ask for the configuration data or statistics I get the data for that tenant. Etc etc. This is what we do at the business end of our applications (tenant resolving on the web layer) and I think it makes sense to do something similar at the management side. As a very simple example consider the Felix web console as a management tool. It does not know how to deal with multiple config admins unless we "scope" it (and the same could be done for log/status/status feeds by simply relying on something like tenant resolving). I think in the end you would want to be able to monitor and manage a tenant instance as an application. The question whether you do it based on post-processing and filtering in custom clients (requiring oob knowledge) or building it on the runtime. > 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. > > > Well, if we doubt we can implement management and monitoring that way, we > should do a bit of prototyping to get a better feel for it. I still think it > has nothing to do directly with this specific mechanism... but when in doubt > we should experiment! True, though I think it is not that hard once we have the mt mechanism down. > 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. > > To be honest, I don't have the ambition to introduce application scoping at > all, with or without tenants. To me that is a separate feature and beyond > the scope of implementing multi-tenancy. I definitely don't think we should > implement it as part of multi-tenancy, and I'm hesitant to implement it at > all. Well I agree that "application scoping" in the sense of multiple applications is something that can be considered "a major scope creep". Sorry about that and I can see how we wont :) However "application scoping" in the sense of a logical separation between platform and applications remain something we must solve. There are and will be (application) services that must be accessible to all tenants (thus no tenant.id), are not logically suitable for an adapter pattern (too heavy / no added value) and MUST not interfere with platform in any way... some random notes: * As show before, the global services heuristics fails: (!(tenant.id=*)). Configurable scope filters may provides a solution: (&(!(tenant.id=*))(objectClass=AllowedApplicationService)) * Singleton heavy application services with tenant proxies to get into tenant scopes seems awkward and needlessly heavyweight (Service proxy pattern). * String[] for tenant.id could help out for application services as (tenant.id=x) matches registration properties tenant.id = [x,y,z]. However each change to the set of tenant will require modification of all service registration properties for these services. * String application.id could help in the same way to match service registrations without tenant.id but within a 'logical ' application and thus not requiring a heuristic. * For the latter scope=application is easiest and enough if no multiple app scoping is required. On the other hand application=someApp is not too far away then. * Without a first class application scope platform and the application share the configuration space which is insecure / fragile / prone to conflicts. * An application scope construct removes the need for a magic tenant.id for managing and hiding platform scope services. > Why? > > I can see the value of having lots of tenants that all use the exact same > set of bundles running in a single container because that probably performs > a bit better than having lots of containers (even though I think you've > demonstrated already that at least a couple of hundred containers can also > run side by side). To me it is more about the logic of scoping shared services. Even in a nested container scenario you need to decide what to expose to whom. > I definitely think that once you start running different applications, you > should move to an environment where you have multiple containers. If you end > up having containers that contain services that should be visible to other > containers, we can either (right now) use our REST endpoints or (at the end > of Q1) use Remote Services. I think till know we have only been discussing a single optionally multi-tenant application per management agent and I think that it may proof to be more then enough. Different applications different containers sounds reasonable to me. It is just that I think we need to have a powerful / flexible way to manage visibility anyway to cope with the use cases mentioned before. Also I feel a little uneasy with the fact that I have no way to separate platform/agent configuration from application configuration. > I've removed the rest of the mail for now, because I think we should first > try to agree on whether "application scoping" is in scope or not. So please think of this as ""application scoping" in the sense of a logical separation between platform and applications" thing for a moment :)" Use case: Application X is a multi-tenant frontend that uses a global UserAdmin backend that has different storage configuration than the one used by the platform itself for managing access control to platform functions. Could we solve this? Do we want to? :) grz Bram _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
