This PR copies the flagstore implementation from ECSC 2022.
To support multiple flagstores, multiple checker scripts have to be provided by the service authors. Each flagstore is then registered as a seperate service. Additionally, service categories group the flagstores to provide the "real" services.
Tested locally and the python checkerlib is confirmed working. I have tested multiple flagstore result combinations and they all behave as expected (OK+OK -> OK, OK+FAULTY -> FAULTY, OK+NOT CHECKED -> NOT CHECKED, etc.)
I suspect that the go checkerlib will need refactoring, because each (python) checker function additionally returns a message that is shown on the scoreboard. However, the go checkerlib has not been adapted to support this. I don't know whether we want to keep that feature. Furthermore, I know next to nothing about go, therefore someone else would need to take a look at it if we decide to keep it.
Additionally, I'm not sure about the scoring formula. AFAIK, each service group gets SLA points equal to COUNT(FLAGSTORE) iff all of them are OK. This should be easy to adapt though, once we decide on what scoring formula to use.
There is still some commented out SQL, which should be removed before merging.
This PR copies the flagstore implementation from ECSC 2022.
To support multiple flagstores, multiple checker scripts have to be provided by the service authors. Each flagstore is then registered as a seperate service. Additionally, service categories group the flagstores to provide the "real" services.
Tested locally and the python checkerlib is confirmed working. I have tested multiple flagstore result combinations and they all behave as expected (
OK+OK -> OK,OK+FAULTY -> FAULTY,OK+NOT CHECKED -> NOT CHECKED, etc.)I suspect that the go checkerlib will need refactoring, because each (python) checker function additionally returns a message that is shown on the scoreboard. However, the go checkerlib has not been adapted to support this. I don't know whether we want to keep that feature. Furthermore, I know next to nothing about go, therefore someone else would need to take a look at it if we decide to keep it.
Additionally, I'm not sure about the scoring formula. AFAIK, each service group gets SLA points equal to
COUNT(FLAGSTORE)iff all of them are OK. This should be easy to adapt though, once we decide on what scoring formula to use.There is still some commented out SQL, which should be removed before merging.
Resolves #77