Hi, On 1 August 2016 at 11:02, Carsten Ziegeler <cziege...@apache.org> wrote:
> Well, I think you're misinterpreting my comments - I never said that it > will require a special tooling - I said it would be insane to edit a > complex setup by editing nodes in the repository. > I was, apologies and thank you for the clarification. No special tooling *and* a simple set of rules that are natural to communicate and document. I don't have a strong opinion on merging or inheritance, provided its simple to use and the result if obvious with no strange side effects to catch a deployer out. > > Clearly with devops automation you have some tooling already in place > which is using text files and does something to start AEM, so you can > add the stuff there - or - the configuration are content packages after > all, so if the automation supports content packages in some form, you're > done. > Agreed. Best Regards Ian > > Carsten > > > Hi, > > > > I think it must be possible to configure a Sling/AEM instance without > using > > specific Sling/AEM tooling to create and manage the source configuration. > > The reason I say this is almost all serious deployments use some form of > > DevOps automation ranging from Puppet/Chef/AWS etc through to > > Docker/Mesos/Kubernetes etc. Almost without exception those systems work > > with configuration stored in text files (property, json, yaml etc), often > > stored in Git/SVN/Hg, edited by a human in a text editor. There are > systems > > that only allow config via a GUI, but most of those only used, under > > sufferance, when there is no other option, (or competing product). The > > "customer" here is not a Sling/AEM expert, but a DevOps engineer who has > > never seen either before. > > > > If the only way to configure Sling/AEM is via special Sling/AEM tooling > > then we will have made the job of the TechOps/DevOps team even harder. > > > > I can think of lots of ways that merging at the property level could be > > made to work, but if we are not able to communicate clearly how it works, > > and all the potential side effects, to those whose job it is to make > > Sling/AEM work in production then we will have failed. If we have to > resort > > to validation tools, compilers, special editors thats an indication the > > system is so complex we are not able to document it in plain english. > For > > that reason, I beg, please keep whatever solution is chosen as simple as > > possible. > > > > I did try to document "object" level inheritance (ie aggregating > > properties), with all the side effects, but when I realised it was not > > going to be simple, I gave up and went back "object" level merging, which > > is brutal and simple by comparison. > > > > Best Regards > > Ian > > > > > > > > On 1 August 2016 at 08:29, Carsten Ziegeler <cziege...@apache.org> > wrote: > > > >>> Hi everyone, > >>> > >>> I personally see a tooling based approach complicated due to the > >> ownership > >>> scenarios. > >> Let's assume two scenarios, configuration A and configuration B inherits > >> from A. > >> > >> Now, if we support merging, someone is allowed to change A, adds a new > >> property and this automatically influences B - and in this case the > >> person who made changes to A does not even need to have access rights to > >> change anything for B. (Which I think is scary). > >> > >> If we don't support inheritance, there is still someone who is allowed > >> to make a change to A - at first this has no influence on B. If that > >> same person is allowed to also change B and wants to "inherit" the new > >> property to B, the tooling will allow so. > >> > >> With that respect, not having automatic inheritance sounds like the > >> better option when it comes to access rights. > >> > >> Carsten > >> > >>> We are talking about context aware configuration that typically > >>> would be applied by some runtime user that might have limited write > >> access > >>> (just for a specific context). The assumption that who writes to the > >>> inheriting configuration node also has write access to the subsequent > >>> levels is something we cannot and should not make here. I know multiple > >>> customer scenarios where a central site (including global > configuration) > >>> was maintained by a central marketing organization while the markets > >> owned > >>> their own sites - so they declare inheritance (pull) instead of having > >> the > >>> global one pushed. > >>> > >>> The one thing in between that I could imagine might work sufficiently > is > >>> referencing (by path to property) instead of inheritance. This still > >>> provides the lookup of "inheritance" at runtime where changes are > >> reflected > >>> in the lookup immediately but at the same time gets rid of magic > >>> inheritance rules. > >>> > >>> Just a thought about an alternative in between. > >>> > >>> Cheers > >>> Dominik > >>> > >>> On Mon, Aug 1, 2016 at 8:36 AM, Carsten Ziegeler <cziege...@apache.org > > > >>> wrote: > >>> > >>>>>> ... if you have merging (or inheritance) then you change the > >>>>>> attribute of a parent and this influences all childs and you > >>>>>> have no idea what happens there... > >>>>> > >>>>> We can create a felix console plugin that shows for a given > >>>>> context path and config name the value of the property and the > >>>>> path from where it was taken - that way both developers and ops > >>>>> can quickly check what's going wrong if results are unexpected. > >>>>> > >>>>>> I personally think this comes all down to tooling ... > >>>>> > >>>>> So this could mean e.g. an additional maven plugin, which handles > >>>>> merging of configurations and then the runtime can work without > >>>>> merging. The problem I see with that is that > >>>>> * you end up having two similar configuration model types (one in > >>>>> the source code that supports merging and one effective one for > >>>>> the runtime) - this makes the mechanism harder to understand > >>>>> for everyone > >>>>> * the tooling has to be created and IMHO it'll not be easier/less > >>>>> code than creating a smarter runtime (even if we take into > >>>>> account that we have to create the felix console plugin to make > >>>>> it traceable) > >>>>> > >>>> First of all, you need tooling anyway. It would be foolish to make > >>>> these configurations without any tooling by hand. Tooling can easily > >>>> be customized to anyones needs without tampering the implementation. > >>>> The implementation at runtime can be simply and effective. > >>>> > >>>> We had similar discussions while starting the work for the OSGi > >>>> Configurator which allows you to put OSGi configurations into a bundle > >>>> which then get applied at runtime. My initial proposal had all the > >>>> things requested here as well (merging, inheritance etc.). It turned > >>>> out that this messed up the specification and made the implementation > >>>> extraordinary complicated. While moving this into the tooling which > >>>> creates the bundles in the first place solves all the problems. > >>>> > >>>> Just think of all the different cases you have to solve once you > >>>> start support merging. And not to mention the runtime implications as > >>>> you have to do the merging dynamically at runtime as well, or you > >>>> start introducing all kinds of caching again. All of this is not > >>>> required if you move this to the tooling level. > >>>> > >>>> Regards > >>>> > >>>> Carsten > >>>> > >>>> -- > >>>> Carsten Ziegeler > >>>> Adobe Research Switzerland > >>>> cziege...@apache.org > >>>> > >>>> > >>> > >> > >> > >> > >> > >> -- > >> Carsten Ziegeler > >> Adobe Research Switzerland > >> cziege...@apache.org > >> > >> > > > > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org > >
