Tools » teuthology

This would have the awesome side effect of being able to tell from the lockdb what distro/version one expects to find on a machine.

I'm wondering where might be a sane place to put this in our job yamls.

Unrelated, do you think using a regex to match would be a good idea? I haven't thought it through; it just occured to me.

Zack Cerza wrote:

I'm wondering where might be a sane place to put this in our job yamls.

Unrelated, do you think using a regex to match would be a good idea? I haven't thought it through; it just occured to me.

regex might be handy, although I'm not sure that we need it yet.

right now when we force install of an os/version on vps, we do this:

maetl:supported 05:12 PM $ pwd
 /home/sage/src/ceph-qa-suite/distros/supported
 maetl:supported 05:12 PM $ cat ubuntu_14.04.yaml 
 os_type: ubuntu
 os_version: "14.04"

can we reuse this same syntax? that would let us run the same suite (like, the upgrades) on bare metal as on vps, and each job would end up selecting machines that have the right os installed.

Looks like my work in #8544 is going to be useful after all. I can use it to populate paddles with node information.

Edit: I'll elaborate:

Remote.distro.name will look like 'ubuntu' or 'centos'
Remote.distro.release will look like '12.04' or '6.5'

I should add a Remote.arch - should I get that from uname -i or uname -p?

I am thinking that adding a new subtask to teuthology.task.internal, executed after lock_machines(), could push values back to paddles.

It seems to me that name, and release and arch would be enough information to store in paddles. We already store arch, and name as distro - we just need to make sure they get updated. I can add a distro_version field easily.

Edit2: I'm not actually sure if anything uses the distro value in the locks db. In that case I could rename it to os_type and we could use os_version - so that when we get Ceph running on iPads we have one less thing to worry about ;)

Remote.arch using uname -p:
https://github.com/ceph/teuthology/commit/cf20f3e0aaba88e205285f9cddf558e7aef3239e

Inventory work for paddles:
https://github.com/ceph/paddles/pull/45

Paddles work is merged.

Lots of auto-population added - details in #7400.

Looks like we already have teuthology-suite checking for exclude_arch and exclude_os_type. Adding exclude_os_version would probably be easy.

Of course, making it do something for non-vps is not trivial.

Um, so, here's a question: do we have any non-ubuntu machines in the lab that I can actually test this against?

There are a few rhel7 recently installed

Ah, I found Sandon's email from when he re-imaged a few. They are:

plana31
plana37
plana40
plana54
plana91

Unfortunately they are all locked at the moment.

Whoa-boy. Turns out the handling of os_type and os_version in teuthology is very tangled.

paddles can now lock machines for you based on os_type and os_version
https://github.com/ceph/paddles/commit/756bb69af45fcd50768aba9ecd263907fde827da

aaand, RHEL6 doesn't have /etc/os-release. I guess I'm doing a smidge more parser work.

Merged os_type and os_version filtering.

The erasure code use case is to create a yaml including a task that runs a rados task using an erasure coded pool using the isa plugin. This yaml file should be used by all upgrade suites, to demonstrate that the erasure coded pool using the isa plugin can indeed be used after the upgrade. Such a test is relevant for all intel architectures that run an operating system for which the plugin was compiled.

For reference the isa plugin rados task

Negative constraints: #9637