On Mon, 2016-08-01 at 11:34 +0100, Ian Boston wrote:
> Hi,
>
> On 1 August 2016 at 11:02, Carsten Ziegeler <[email protected]>
> 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.
I think it's possible to have merging on a less fine-grained level, and
thus more controllable, by using multiple nodes for the same
configuration instance.
For example:
Global: {
'services' : {
'serviceA' {
'endpoint' : 'https://api.com/foo'
'params': {
'timeout': 500
}
}
}
}
Site: {
'services' : {
'serviceA' {
'endpoint' : '
https://stage.api.com/foo'
}
}
}
the override only affects the 'endpoint' parameter. If at somepoint we decide
to add a 'retryCount' parameter to 'params' this will also be propagated to
inherited configurations.
Of course, this comes with the caveats that:
- we need to decide upfront what about how configurations are split into nodes
- we won't always be able to split configurations into nodes so that all
properties are overrideable
Robert
>
>
> >
> >
> > 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 <[email protected]
> > > >
> > 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 <cziegeler@a
> > > > > pache.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
> > > > > > [email protected]
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Carsten Ziegeler
> > > > Adobe Research Switzerland
> > > > [email protected]
> > > >
> > > >
> > >
> >
> >
> >
> >
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > [email protected]
> >
> >
