Fix dir creation when cocci_cache is missing

[kvaps]

When drbd tarball created from github source code, it does not contain any patches.
spaas binary can't create directory cocci_cache/_, because cocci_cache does not exists:

root@cb6f63ef8e10:/# /spaas -addr ":2020" -patchcache /var/cache/saas/patches -tarcache /var/cache/saas/tarballs --debug --keeptmpdir
2022-06-09T22:19:33.381Z	DEBUG	spaas/main.go:170	adding /var/cache/saas/tarballs/drbd-9.1.7.tar.gz to the tarball cache
2022-06-09T22:19:36.182Z	ERROR	spaas/main.go:399	Could not generate patch: Could not create cocci dir: mkdir /tmp/saas3305441620/drbd-9.1.7/drbd/drbd-kernel-compat/cocci_cache/_: no such file or directory	{"type": "error", "remoteAddr": "127.0.0.1:35236", "code": 400}
main.(*server).errorf
	/usr/local/go/spaas/main.go:399
main.(*server).spatchCreate.func1
	/usr/local/go/spaas/main.go:189
net/http.HandlerFunc.ServeHTTP
	/usr/local/go/src/net/http/server.go:2084
github.com/gorilla/mux.(*Router).ServeHTTP
	/go/pkg/mod/github.com/gorilla/mux@v1.7.3/mux.go:212
main.(*server).ServeHTTP
	/usr/local/go/spaas/main.go:124
net/http.serverHandler.ServeHTTP
	/usr/local/go/src/net/http/server.go:2916
net/http.(*conn).serve
	/usr/local/go/src/net/http/server.go:1966

[rck]

just to make things clear:

• As the user you send the server 2 things: The DRBD tarball version and the your compat.h
• The server needs a basline to generate the patch for, it does that by fetching the upstream tarball with the version you sent (or it uses the cache).
• Now the crucial part: it sends back that patch, which will apply because you had an upstream tarball and the server had the same upstream tarball and therefore the generated patch will apply

When you send an "old" version, but from a tarball you generated from git (that can be arbitrarily different compared to what the "old" version still refers to), you mix code in a way it is not intended. The upstream tarball your version refers to basically - depending on the changes in git - has nothing to do with your actual tarball, and it is pure luck if the generated patch (generated for the upstream version and your git compat.h) still applies.

But you know all of that and you don't fetch the actual tarball, but you place the exact git tarball under the upstream name in the tarball cache directory? And you make sure the service is restarted so it does not serve old patches for another fake version from another git commit? and you know that this faked combination only works exactly for the fake tarball on the server and the exact fake tarball you build on the system? How do you avoid that your systems run into the real saas on drbd.io but use yours instead? fake drbd.io? patch it? Why not just run spatch locally? Or build patches for the kernels you support and include them into the tarball?

[kvaps]

The reason I'm doing this, is that some of our customers and community users have isolated environments without connection to the internet. They came with problem of building drbd module in such environments.

Of course, adding coccinelle dependency to the image is made it working, but the container has grown for 523 megabytes.

I was considering to run spaas in separate container since this logic is already implemented in drbd building process, so it can connect to some spaas running as a service locally in the same Kubernetes cluster.

When you send an "old" version, but from a tarball you generated from git (that can be arbitrarily different compared to what the "old" version still refers to), you mix code in a way it is not intended. The upstream tarball your version refers to basically - depending on the changes in git - has nothing to do with your actual tarball, and it is pure luck if the generated patch (generated for the upstream version and your git compat.h) still applies.

Not exactly, I just build drbd release tarballs from the source code using specific version tag. I just call make tarball instead of downloading it from pkg.linbit.com. In the end I get pretty similar tarball as upstream one but without compatibility patches, which originally can be found under drbd/drbd-kernel-compat/cocci_cache directory.

you place the exact git tarball under the upstream name in the tarball cache directory? And you make sure the service is restarted so it does not serve old patches for another fake version from another git commit?

This all is done by docker at the building time and updated automatically by the deckhouse-controller (our opinioned Kubernetes operator)

How do you avoid that your systems run into the real saas on drbd.io but use yours instead? fake drbd.io? patch it?

I was considering to prepare patch for drbd and piraeus projects to allow specifying saas server in enviroment variable.

Why not just run spatch locally? Or build patches for the kernels you support and include them into the tarball?

We already doing this.

Actually, we don't know what OS and kernels our customers are using exactly, we're working hard on support all of them.
Implementing spaas would allow to avoid having additional 523 megabytes of dependencies for drbd-kernel-injector container image and make it possible to build drbd module in isolated environments.

[rck]

Thanks for the explanation, always interesting with what ideas our users come up :). And sure, if you use the git tags, then the tarball should be reasonably compatible to the upstream tarball