Port `network_load_balancers` to the database generator

[stgraber]

Incus uses a built-in code generator for most of its database interactions. Unfortunately not all entities have yet been moved over to that mechanism, causing us to have far more SQL code in our code tree than we'd really like.

The goal here is to define new code generated functions in internal/server/db/cluster/ and then remove the old implementation from internal/server/db/ transitioning everything over to the new generated functions.

A recent example of the database generator being used can be found here: https://github.com/lxc/incus/pull/655

Note that some of the syntax has since evolved, so you may want to look at the current version of networks_integrations.go to see how to invoke the generator.

[davidbockelman]

Hello, I'm a student at UT in Professor Chidambaram's Virtualization course. Could me and my partner take on this issue?

[stgraber]

For sure!

[OGCbn]

I am @davidbockelman's partner; could I be added?

[davidbockelman]

My partner and I are curious about the implementation. As of this moment, we believe we will create a file inside the cluster directory which will hold 3 main things: type NetworkLoadBalancer struct type NetworkLoadBalancerFilter struct and a toAPI function, does this seem to align with what the final product will look like?

Also, are we changing the call sites so that the functions in the original network_load_balancers.go are no longer used? In that case, would the non-sql logic then go into our new cluster/network_load_balancers.go file?

Finally, we are having some issues with the generated files not having the correct imports. For example, in all of the generated .interface.mapper.go files, the import "context" statement is missing, but was there previously when we forked the repo. Is this an issue with our new network_load_balancers.go file or with how we are running go generate?

[stgraber]

does this seem to align with what the final product will look like?

Yep, that combined with the comments at the top of the file should get make update-schema to generate the mapper files with the actual functions.

Also, are we changing the call sites so that the functions in the original network_load_balancers.go are no longer used? In that case, would the non-sql logic then go into our new cluster/network_load_balancers.go file?

Yeah, the old network_load_balancers.go file will need to completely go away. If the logic is really database specific, ti can go in cluster/network_load_balancers.go but that's somewhat rare, we usually end up with most of the logic being relocated to the caller's package. So in this case, likely split between cmd/incusd/network_load_balancer.go and internal/server/network/driver_ovn.go as those should be where most/all calls to the load balancer DB functions should currently be located.

[stgraber]

Finally, we are having some issues with the generated files not having the correct imports. For example, in all of the generated .interface.mapper.go files, the import "context" statement is missing, but was there previously when we forked the repo. Is this an issue with our new network_load_balancers.go file or with how we are running go generate?

You may want to try a make update-schema run before doing any changes to confirm that it's behaving as expected.

stgraber@dakara:~/Code/lxc/incus (git:stgraber/main)$ git status
On branch stgraber/main
Your branch is ahead of 'github-stgraber/main' by 25 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean
stgraber@dakara:~/Code/lxc/incus (git:stgraber/main)$ make update-schema
cd cmd/generate-database && go build -o /home/stgraber/Code/go/bin/generate-database -tags "libsqlite3"  && cd -
/home/stgraber/Code/lxc/incus
go generate ./...
gofumpt -w ./internal/server/db/
goimports -w ./internal/server/db/
Code generation completed
stgraber@dakara:~/Code/lxc/incus (git:stgraber/main)$ git status
On branch stgraber/main
Your branch is ahead of 'github-stgraber/main' by 25 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean
stgraber@dakara:~/Code/lxc/incus (git:stgraber/main)$ 

[davidbockelman]

I believe I fixed the issues that caused the CI pipeline to fail on my PR, could you @stgraber check it out and run the pipeline again? I apologize if this is not the standard way of resolving issues in a PR, I'm new to open-source contribution.