sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Edelson <jus...@justinedelson.com>
Subject Re: [hackathon] health checks
Date Tue, 18 Sep 2018 23:15:04 GMT
Hi Georg,
Great. It looks like I misread Stefan's notes as being more dramatic than
they actually were intended to be :)

Regards,
Justin

On Tue, Sep 18, 2018 at 4:48 PM Georg Henzler <slingml@ghenzler.de> wrote:

> Hi Justin,
>
> there was quite some discussion at adaptTo() around this topic already. So
> as it stands all requirements to run Sling-based applications in Kubernetes
> are met already by Sling Health Checks (you just create two tags for
> readiness and liveness each). HCs were developed from the first day with
> the goal to have them used by load balancers (and not only manual). Also
> Sling HCs are more mature in terms of parallel execution, timeout handling,
> response customizing and special handling like asynchronous checks.


> Now the system readyness framework was mostly created to have something on
> Felix level and the capabilities of the Sling Health Checks weren’t known.
>
> I do agree that it would make sense to have it on Felix level though (more
> visible to the non-Sling world, as a low level mechanism maybe best located
> at the lowest framework level). The dependencies of Sling HC to Sling are
> minimal today already: It’s Sling thread pool (a felix pendant or just a
> plain java one can be used) and Sling Scheduler (also this can easily be
> replaced by the standard java mechanism).


> > It might make more sense to invert this and identify what the readyness
> framework does (mostly in its OOTB checks and servlets)
> > and merge that functionality into Sling Health Checks and then move Sling
> > Health Checks (or solid chunks of it) to Felix.
>
> This was the intention, but let’s wait for the feedback from Andrei and
> Christian.
>
> -Georg
>
> Sent from my iPhone
>
> > On 18. Sep 2018, at 16:31, Justin Edelson <justin@justinedelson.com>
> wrote:
> >
> > Hi,
> > After reviewing the presentation, this seems like kind of a stretch to
> me.
> > IIUC, the System Readyness Framework is (as its name would suggest)
> solely
> > concerned with "readyness"  and "liveness" (as seen in the example use
> > cases on slide 3) and the API is explicitly designed for this purpose
> > without any opportunity for namespace extension (i.e. you can extend how
> > "readyness" and "liveness" are determined but you can't add new
> > categories). Sling Health Checks is concerned with a broader concept of
> > "health" with no restrictions on namespacing. There are all kinds of
> > reasons why a system may be considered "ready" but still fails specific
> > health checks. In other words, I'm doubtful that there is an overlap here
> > at a framework level. What would make sense is a bridge where a subset of
> > health checks could be fed into the readyness framework (i.e. if these X
> > health checks pass, the system is considered "ready" and/or "alive"). But
> > I'd strongly suggest that the gamut of expression possible with the
> health
> > check framework goes far beyond the scope of what the readyness framework
> > is designed to do. It might make more sense to invert this and identify
> > what the readyness framework does (mostly in its OOTB checks and
> servlets)
> > and merge that functionality into Sling Health Checks and then move Sling
> > Health Checks (or solid chunks of it) to Felix.
> >
> > Or perhaps I've misunderstood the intention of this email/F2F discussion.
> > But the way this looks is that we are going to take something with a
> decent
> > install base and replace it with something a few months old and a much
> > smaller functional scope. Just doesn't make sense to me.
> >
> > Regards,
> > Justin
> >
> > On Thu, Sep 13, 2018 at 1:03 PM Stefan Seifert <sseifert@pro-vision.de>
> > wrote:
> >
> >> - currently there is some overlap between sling health checks and the
> new
> >> felix system readyness framework presented [1]
> >> - the idea is to bring this together within felix
> >> - provide a facade for the sling healthcheck API for backwards
> >> compatibility
> >>
> >> stefan
> >>
> >> [1]
> >>
> https://adapt.to/2018/en/schedule/system-readiness-framework-makes-deployment-automation-a-breeze.html
> >>
> >>
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message