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 <jus...@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 <sseif...@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 >> >> >>
