Hi Guillaume, it can indeed be a problem when checks arrive late as the ready state of the system can then be green too early. So one approach is to configure a list of expected checks. This is easy to implement but requires manual config.
Another approach I thought about is to use the ServiceComponentRuntime to check which check components are present and wait until they com up. This only works for checks implemented in DS but might be quite convenient. Christian 2018-04-17 14:16 GMT+02:00 Guillaume Nodet <[email protected]>: > I like it a lot, the API is simple and extensible enough. Really nice work > ! > I'm just a bit nervous about having such a low-level component depend on an > external extender... > > I think it's missing one bit though: some kind of expectations. I.e. it > checks existing stuff, but it does not cover missing stuff. I suppose it > could be implemented specifically using custom checks, but I think there is > still a hole, which is the fact that those custom checks are not > available. So I wonder if there should be an additional built-in check > that would grab a configuration entry, turn that into a list of mandatory > checks and be green if all those check are available, yellow/red > otherwise. This would ensure your container does not switch between > green/yellow while the container is booting/provisioning. > > 2018-04-17 10:02 GMT+02:00 Christian Schneider <[email protected]>: > > > Dear Felix community, > > > > during the last weeks Andrei Dulvac and I worked on a small framework to > > check if an OSGi based system is fully up. > > > > Our work originated in testing sling modules and whole sling instances. > We > > soon found though that the concept is more general than sling and can be > > applied to any OSGi based system. > > > > The system readiness framework has a SystemReadinessMonitor service that > > reports the aggregated state of the system. It delegates to > > SystemReadinessCheck services that each check for a certain aspect. We > > implemented a first check based on a list of expected top level services. > > The system can be customised by adding specific checks for your > > application. For example we plan to add sling specific checks inside the > > sling project. > > > > In addition to simply detecting if the system is ready we also created a > DS > > based root cause analysis that can be very helpful to detect why a set of > > components does not come up as expected. > > > > We would like to donate this project to the Apache Felix project as it > > might get more attention there by people that are not related to sling. > The > > project is Apache licensed from the start and we already got a basic > > documentation as well as good test coverage. > > > > We currently host it in this github repository: > > https://github.com/dulvac/system-readiness > > > > The packages are still mentioning sling but of course we would change > this > > to felix if this community is interested in the donation. > > > > Best regards > > > > Christian and Andrei > > > > > > -- > > -- > > Christian Schneider > > http://www.liquid-reality.de > > > > Computer Scientist > > http://www.adobe.com > > > > > > -- > ------------------------ > Guillaume Nodet > -- -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
