Re: [RT] The various roles of (multitenant) content
Hi Stefan, On Fri, Aug 22, 2014 at 2:03 PM, Stefan Seifert sseif...@pro-vision.de wrote: System content: Defines how a specific version of the system behaves. Multiple system versions can coexist in a shared content repository (as we demonstrated in [1], in a limited way) this is for example configuration - but as you describe it mainly system-level configuration (e.g. OSGI configuration). what is with the other types of configuration on the different levels (regions, tenants, sites). they do not belong into the role system content, but they do not fit in the other roles as well... I agree, that content might be called tenant-specific application content maybe? ... Application content: Extensions or overrides of system content, that modify how the system behaves. Usually tenant-specific, or maybe shared between a group of tenants ... i assume the whole application bundle falls into this category? but an application bundle usually consist of both OSGi bundles (system role) and scripts (application context role) Currently I don't think we have a way to make OSGI services specific to a tenant, unless the method signatures require tenant information. This is a whole topic in itself. -Bertrand
Re: [RT] The various roles of (multitenant) content
Hi, On Mon, Aug 18, 2014 at 7:35 PM, Ruben Reusser r...@headwire.com wrote: ...looking at this it seems the same functionality would be handy for feature flags, no?... Not sure what you mean by that, can you explain more? -Bertrand
RE: [RT] The various roles of (multitenant) content
hello betrand. i try to find the bridge to the multitenancy scenarios i've described in [1]: Deliverable content: Displayed on a website or mobile app for example. Can be global, shared between a group of tenants or tenant-specific. this is what i've called content in the wiki page. may be page content, media assets etc., everything the editors enter into the system. i18n translations may fall into this role as well. System content: Defines how a specific version of the system behaves. Multiple system versions can coexist in a shared content repository (as we demonstrated in [1], in a limited way) this is for example configuration - but as you describe it mainly system-level configuration (e.g. OSGI configuration). what is with the other types of configuration on the different levels (regions, tenants, sites). they do not belong into the role system content, but they do not fit in the other roles as well. Application content: Extensions or overrides of system content, that modify how the system behaves. Usually tenant-specific, or maybe shared between a group of tenants if an application is installed to be used by all tenants (e.g. massive multi site scenario), it may be global application-level overrides as well. but this fits in your group of tenants picture, where the group is all tenants. i assume the whole application bundle falls into this category? but an application bundle usually consist of both OSGi bundles (system role) and scripts (application context role). Module state content: The typical example is workflow models and state, which is not deliverable but persistent and might be partially shared. other examples are background jobs using sling event/job infrastructure. this is not module-related, or i do not understand clearly what you mean with model in this context. Instance-specific transient content: Transient content that's relevant to a single Sling instance. Compiled scripts, for example. Not needed when the Sling instance starts. ok stefan [1] https://cwiki.apache.org/confluence/x/So2uAg
[RT] The various roles of (multitenant) content
Hi, I'm working on various experiments (like [1]) related to continuous deployment with Sling, and having a clearer definition of the various roles of the content that a typical Sling applications manages would help. I'm saying roles instead of types on purpose, to avoid confusion with Content-Type ;-) There's a lot of ties between this and our recent discussions about multi-tenancy, so refining this tentative list of roles might help for that as well. Does this list fit with your use cases? Do people see other roles? My context is a number of Sling instances sharing a common content repository. Deliverable content: Displayed on a website or mobile app for example. Can be global, shared between a group of tenants or tenant-specific. System content: Defines how a specific version of the system behaves. Multiple system versions can coexist in a shared content repository (as we demonstrated in [1], in a limited way) Application content: Extensions or overrides of system content, that modify how the system behaves. Usually tenant-specific, or maybe shared between a group of tenants Module state content: The typical example is workflow models and state, which is not deliverable but persistent and might be partially shared. Instance-specific transient content: Transient content that's relevant to a single Sling instance. Compiled scripts, for example. Not needed when the Sling instance starts. WDYT? -Bertrand [1] https://github.com/ArtyomStetsenko/sling-devops-experiments
Re: [RT] The various roles of (multitenant) content
Hi, Is configuration part of application content or system content or both? I can see that in a clustered environment you might want to have configuration shared centrally amongst many versions of the running application, but you might also need configuration local to a running version, so that upgrades don't require all running instances to be taken offline. Best Regards Ian On 18 August 2014 10:12, Bertrand Delacretaz bdelacre...@apache.org wrote: Hi, I'm working on various experiments (like [1]) related to continuous deployment with Sling, and having a clearer definition of the various roles of the content that a typical Sling applications manages would help. I'm saying roles instead of types on purpose, to avoid confusion with Content-Type ;-) There's a lot of ties between this and our recent discussions about multi-tenancy, so refining this tentative list of roles might help for that as well. Does this list fit with your use cases? Do people see other roles? My context is a number of Sling instances sharing a common content repository. Deliverable content: Displayed on a website or mobile app for example. Can be global, shared between a group of tenants or tenant-specific. System content: Defines how a specific version of the system behaves. Multiple system versions can coexist in a shared content repository (as we demonstrated in [1], in a limited way) Application content: Extensions or overrides of system content, that modify how the system behaves. Usually tenant-specific, or maybe shared between a group of tenants Module state content: The typical example is workflow models and state, which is not deliverable but persistent and might be partially shared. Instance-specific transient content: Transient content that's relevant to a single Sling instance. Compiled scripts, for example. Not needed when the Sling instance starts. WDYT? -Bertrand [1] https://github.com/ArtyomStetsenko/sling-devops-experiments
Re: [RT] The various roles of (multitenant) content
Hi, On Mon, Aug 18, 2014 at 2:56 PM, Ian Boston i...@tfd.co.uk wrote: ... Is configuration part of application content or system content or both? ... We probably need a more fine-grained definition for configs - for now I see the following types of configuration: a) Global system-level config, like the URL of a remote logging server. This can be either pure OSGi configs or based on shared repository content with suitable access control. b) Version-specific system config, where Sling instances that run the same version of system and application code share the same config. Also manageable in the content repository with access control. c) Application or tenant-specific config. Using non-OSGi configs which are just content in the repository, picked up on the fly by services that process a tenant-specific request, works. But I don't think we currently have a solution for tenant-specific configuration of OSGi services, unless the services are specifically designed for that. So I'd say with our current installer there is configuration both in system and application content. and tenant-specific configurations require specific code for now. -Bertrand
Re: [RT] The various roles of (multitenant) content
looking at this it seems the same functionality would be handy for feature flags, no? Ruben On 8/18/2014 6:19 AM, Bertrand Delacretaz wrote: Hi, On Mon, Aug 18, 2014 at 2:56 PM, Ian Boston i...@tfd.co.uk wrote: ... Is configuration part of application content or system content or both? ... We probably need a more fine-grained definition for configs - for now I see the following types of configuration: a) Global system-level config, like the URL of a remote logging server. This can be either pure OSGi configs or based on shared repository content with suitable access control. b) Version-specific system config, where Sling instances that run the same version of system and application code share the same config. Also manageable in the content repository with access control. c) Application or tenant-specific config. Using non-OSGi configs which are just content in the repository, picked up on the fly by services that process a tenant-specific request, works. But I don't think we currently have a solution for tenant-specific configuration of OSGi services, unless the services are specifically designed for that. So I'd say with our current installer there is configuration both in system and application content. and tenant-specific configurations require specific code for now. -Bertrand
