On 10 October 2013 05:40, Felix Meschberger <fmesc...@adobe.com> wrote: > Hi > > Am 09.10.2013 um 09:05 schrieb Ian Boston: > >> Hi, >> >> On 9 October 2013 16:21, Felix Meschberger <fmesc...@adobe.com> wrote: >>> Hi >>> >>> Am 08.10.2013 um 10:40 schrieb Ian Boston: >>> >>>> Hi, >>>> The whitelist configuration in this servlet is causing some problems >>>> where the contents of the whitelist is potentially large and changing, >>>> since it requires constant re-configuration. >>> >>> What is the problem with that ? >> >> When the whitelist in the central discovery endpoint depends on the >> topology itself, it causes production deployment problems, especially >> when the configuration of the end point and the management of the >> topology of the production deployment are managed by different roles >> within the organisation. This is typical of many organisations. >> Engineers don't manage operations and TechOps don't manage >> engineering. Normally configuration would be managed by TechOps but > > Fully agreed ! Which is exactly the reason why conceptually we have to > separate development from deployment and which is why configuration *is* in > fact a deployment issue and not a development issue. > >> with Sling that doesn't appear to be the case. > > How come ? That is not the intent of how Sling should be used. >
Many systems that are managed by TechOps are configured by files on disk (eg Apache httpd.conf etc). As a result much of the tooling to manage production environments works best managing those files. Things that are not files on disk, are generally considered part of the application, unless the application itself is a TechOps application (eg Ldap). Sling (and tbh many Java applications) puts its configuration into database files or repositories, accessed only once the application is running which means TechOps cant use standard tools (Puppet, Cactus etc) to manage the application. TechOps have to use application level tooling and build systems (mvn) to interact with the configuration or take undocumented routes to configuring the application (eg manipulating the private Felix configuration files). Because OSGi makes it easy to configure components, applications based on Sling have large volumes of configuration, much of which is not so much about deployment, and more about configuring the application. In real life, that tends to be poorly documented and the effort level required for TechOps to write build, deploy and maintain those configuration files is too high. Hence the developer teams provide them as part of application startup for TechOps to deploy. There is nothing wrong with this, provided the configuration does not depend on the deployment topology. When it does, it falls between the gaps. There are 2 potential solutions: A. Create something along the lines of Puppet or Cactus to bring deployment level Sling configuration into line with those systems. (or whatever the chosen deployment tooling is). B. Ensure that configuration performed in Sling is not dependent on the deployment architecture and topology so that 99% of the configuration can be used unchanged when deploying 10 or 10000 instances. In this case, B is a lot less effort than A. A is not impossible, but it is not as simple as writing a puppet module with a few curl operations, for a start, deployment should be achievable with the application not running. In short, *if* all configuration is a deployment issue, then it should work with existing deployment tooling. Best Regards Ian
