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). For a start, can you elaborate what "scoping to a tenant" means? > 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! >> 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. 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). 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'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. Greetings, Marcel
_______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
