Implement CaaSP support about rookcheck HOT 13 CLOSED

It looks like CaaSP do not provide a container for skuba. So our options are to build our own in IBS, or us go get. I'm inclined to do the latter as it is more straight forward. We can also point go at a specific release branch (or tag).

from rookcheck.

Can we just install the skuba rpm package?

from rookcheck.

Yes sure. Can't even remember why I used to install using the go build process

from rookcheck.

I'm not sure if it is packaged for non-SUSE distros.

We can place it in bindep anyway with the correct platform filter. We can also tag it as a CaaSP feature so if this tool is used by other devs to test upstream rook on a ubuntu/other distro then it shouldn't matter.

I'll take this one.

from rookcheck.

But we want to test (imo first) what SUSE delivers, not skuba+ubuntu or something like that. So I would prefer to first install skuba from a RPM package and later build it from source

from rookcheck.

Thinking about it there is no skuba RPM for openSUSE afaik, so that would mean we have to go the way of spawning a new machine running SLE to be able to add skuba

from rookcheck.

I thought there was, but having double checked it looks like there are only community packages.

So 3 options:

1. We boot another node just for running skuba. This will make the hardware/provisioning look quite different if it is a skuba deployment vs kubeadm.
2. We maintain a skuba package ourselves.
3. We build skuba like we're building rook.

I'm inclined to go with option 3 as the simplest to do and maintain. The only disadvantage is that we won't be testing official packages, but I'm not sure if that'll matter. We're not trying to test skuba, we're trying to test CaaSP. If we're building a pinned version/branch of skuba then the installed CaaSP should be pretty much the same as one from a package.

Thoughts?

from rookcheck.

Or we just say (for now) skuba needs to be available on the machine where the tests are executed.

from rookcheck.

Yep, that's a good solution for keeping this unblocked.

@brunoleon: do you want to continue your work on the assumption that skuba is installed?

from rookcheck.

I'll assume skuba is installed on the machine launching the test first.

In a second time I think it is better to spawn another instance for this. May be a SLES container with skuba would do to lower the resource requirements.

from rookcheck.

Once CaaSP is installed we also need the rook-k8s-yaml package which contains the yaml file for rook deployment on k8s.

I think this is an added reason to have "control" machine from where to execute:

• skuba commands
• kubectl commands

from rookcheck.

Once CaaSP is installed we also need the rook-k8s-yaml package which contains the yaml file for rook deployment on k8s.

That's true for testing packaged yaml, but we'll need some controls to point to various versions/releases and maybe development versions etc.

However, I think that's a separate ticket/todo item. For now, this item is about installing CaaSP, from there we can install the upstream/master rook onto it. Then later on we'll open a ticket about installing SES rook rather than upstream.

from rookcheck.

#52

from rookcheck.