To Store Or Not To Store

[Lut99]

Work with the refactor of the policy reasoner to extract the Brane stuff from it is progressing smoothly. Over at the reasoner, the lib-refactor-branch contains all the new work; and similarly, Brane has the lib-refactor branch as well to receive the new changes.

Currently, though, I'm at the point where I'm ready to re-introduce the policy store into the picture. I'm rather confident that I might as well use the opportunity and split it into a new service (will create a new policy-store repository soon).

However, I'm now facing two design decisions I'd like your input on @DanielVoogsgerd:

1. Should we structure the store repository the same as the reasoner repository (i.e., library-focused)? My argument for is that the projects are more homogeneous in structure and that we buy ourselves flexibility over at the store proejct; but the counter-point is that I think the store is actually quite agnostic to what it actually stores (some metadata + raw strings; should be sufficient). So we might just want to create a single binary out of it. But I'm not sure.
2. How do we want to combine the two services in Brane? Should I create a single brane-chk container that runs both binaries, to simulate the structure we had before? Or should we spawn another service on the worker that represents the policy store? I thought about using the brane-reg to also store policies, but I think that's unwise because we want none of the policy store API to be outward facing (only the domain itself should be able to check/change them, naturally).

Let me know what you think :)

[DanielVoogsgerd]

1. If there is a clear boundary where you can split the project into a library and binary, I am generally in favour of doing so, as it allows for easy extension in case somebody else comes along with some new perspective. If there is one canonical way of implementing that library, I think we should use src/main.rs for that binary. If other fringe ways of using the library come to light, they can move to src/bin/
2. I think we should go with a single brane-chk container. From a Brane perspective, it functions as one service, so separating it into two just adds complexity. There is one main reason to separate them into two services from a practical standpoint, and that would be in order to allow load balancing the expensive checking, but I think it is unwise to worry about that for now.

Both points come with a big condition that it should not increase either your workload or the complexity too much. E.g. for point 1, if the boundary between what is library and what is binary becomes too vague, just implement it as a boundary and keep it simple. Having a useless library because everything of substance has to move to the binary because it is implementation dependent, it is not of any use to have it as a library.

Unfortunately, my domain knowledge of Brane is still only a fraction of yours, so take my opinion with a grain of salt.

[Lut99]

You make good points! It's decided, then, I'll aim to implement the store akin to a library too with a binary wrapper (at least for now; if it turns out we need multiple, we can move them to Brane just like we did with the reasoner); and I'll create a single container for both the reasoner and the store.

Thanks :)