epi-project / brane-documentation

Repository that contains the high-level documentation of the Brane framework. Written for use with mdBook.
Apache License 2.0
2 stars 2 forks source link

Document setup policy reasoner #22

Open DanielVoogsgerd opened 1 month ago

DanielVoogsgerd commented 1 month ago

Right now, it is quite the struggle to get the policy reasoner setup with Brane. It does not help that there is very little (or any?) documentation on it, by itself this would not be a problem (for me), but considering there is quite the layer of "helpers" when starting and creating images, it becomes very opaque what needs to be done to get everything to work nicely.

I think I'm through most of it, though, so let this be a reminder to add the docs when I finally have everything up and running.

Things that are still unclear:

Lut99 commented 1 month ago

What do you mean by "helpers"?

And also, uhh that is unexpected. I don't think there's been a time where the reasoner has been working in the Brane container before we implemented this change, so it should be in the Dockerfile? Check Dockerfile.rls. But yes we desperately need policy-reasoner docs, lol, to document all this.

Note, by the way, that this flag is for the BraneApiStateResolver connector to tell it where to find a node.yml that explains where to find said brane-api. Should be easy to add (but again, weird it wasn't there before).

DanielVoogsgerd commented 1 month ago

What do you mean by "helpers"?

The elaborate build infrastructure, i.e. main.py, branectl (start), and docker buildx mostly. They are nice, but when debugging they create separation between what I am doing and what ends up actually happening, this can be a bit of a pain when you aren't intimately familiar with what is actually being done. So I end up spending a significant amount of time figuring out why something is cached, or why a flag isn't passed from x to y.

With this problem in particular, I wouldn't know where this nodefile should have been provided, for example.

We will figure it out, though.

Lut99 commented 1 month ago

I see, right. You make a fair point.

What would help towards this? Collapse the helpers, or provide better documentation? I think that documenting the build system is actually not a bad idea regardless xD but do you think that would help you in this?

FYI, the nodefile is pointed-to by branectl (through branectl -n ...), then it passes the path as an env to the docker-compose-worker.yml file which then mounts it as a volume (at least, it should). The path which it mounts to in the container should be given as argument to the policy-reasoner binary in the compose file (through command:), but maybe it mounts at the default location and doesn't both. Or the Dockerfile.rls sets this itself with CMD (though I doubt that).

DanielVoogsgerd commented 1 month ago

What would help towards this? Collapse the helpers, or provide better documentation? I think that documenting the build system is actually not a bad idea regardless xD but do you think that would help you in this?

The thing that would help the most is getting the framework to work as a whole. If I have a working version of Brane it is way easier to make changes and not get lost in these kinds of problems, because there is something that works that I can reference that I know will work, but we are working on that, and I think quite close.

From that point, I think it is just some small changes here and there that would really help, but we'll see when we get there.

The big thing that I think we should reconsider is the way make.py is written. I am not entirely sure how it should be, but right now it is too big, abstract, and complex. It is basically one big OOP wrapper, with some really terse logic (the targets part). I do think we can improve on that in various ways, but I think we have bigger fish to fry.

Lut99 commented 1 month ago

Lol. Yeah, it's a beast xD

Fair enough, then, let's keep it like this for now until your instance works. RE that: don't hesitate to hit me up if you encounter something!