Comments (13)
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:
- 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.
- We maintain a skuba package ourselves.
- 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.
from rookcheck.
Related Issues (20)
- Fix total number of workers HOT 1
- libvirt test-requirements.txt
- Possible race condition when creating the ansible inventory directory structure HOT 4
- tmp directory not created
- use openstack's clouds.yaml for getting cloud configuration instead of environment variables HOT 1
- Skuba package update breaks when kernel-default-base is present and kernel-default used
- test_basic fails HOT 1
- Should the quickstart suggest to install system tox using pip? HOT 1
- Rookcheck want more packages than needed HOT 1
- Should support openSUSE Leap 15.2 from the box HOT 1
- Rookcheck want libcloud auth module when I want libvirt HOT 4
- Libvirt duplication key error HOT 22
- libvirt & k8s upstream fails with: Unable to connect to the server: dial tcp 192.168.128.52:6443: i/o timeout HOT 4
- Image files are always downloaded multiple times. HOT 2
- Allow setting of workspace HOT 1
- Handle failures from rook build thread
- kernel-default installation failed with latest openSUSE 15.1 OpenStack image HOT 1
- Add SES support HOT 2
- Handle failures in node boot thread
- Minimal worker nodes
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rookcheck.