Remove Kowalski as a submodules?

[Theodlz]

We don't deploy Kowalski alongside SkyPortal, and probably never will for good reasons (both systems, based on their hardware requirements, really belong on 2 - or more - different machines).

I'm wondering if it wouldn't make sense to remove Kowalski as a submodule here, from the config, and from the launcher commands. This would make the repo a little bit more maintainable, and limit confusion for contributors.

But also, I think that without Kowalski, Fritz can really be a solid example of what a system that needs to add features on top of vanilla SkyPortal should look like.

[Theodlz]

@mcoughlin @profjsb @stefanv any thoughts? Maybe something to discuss at the Fritz weekly meeting

[Theodlz]

• obviously, since we haven't been deploying Kowalski with Fritz, it's also incredibly outdated (both the version pinned, config, ...)

[mcoughlin]

@Theodlz completely agreed.

[stefanv]

It would be good to have a way to do integration testing, if that isn't yet set up on either side.

[Theodlz]

@stefanv ah yes definitely. I think that can still happen on git. I'm thinking about pushing kowalski docker images to dockerhub soon, so not too hard to have it run here and pass it the SkyPortal token as an env variable (and vice versa).

[Theodlz]

And again this is just an idea. Documenting the existing code a bit mode and cleaning it up might be enough to separate the Fritz and Kowalski stuff enough that someone else can pretty much fork Fritz and modify it into their own skyportal custom app.

[Theodlz]

And first, I want to fix the existing integration testing with Kowalski