Project

General

Profile

Bug #14240

teuthology-suite should check presence/translate to sha1 based on the actual request

Added by Dan Mick almost 4 years ago. Updated almost 4 years ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
Core
Target version:
-
Start date:
01/05/2016
Due date:
% Done:

0%

Source:
Development
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Crash signature:

Description

teuthology-suite does several things based on the 'default distro/version', including at least:

1) translating branch/tag to sha1
2) checking for presence of a requested branch/tag/sha1

This leads to confusing situations where, say, the centos gb thinks 'testing' is sha1a, but the ubuntu gb thinks it's sha1b, and so an otherwise-proper job fails or installs the wrong version.

There's no reason the gbs should have to be in sync.


Related issues

Related to teuthology - Bug #14307: ceph package for jewel not found in trusty gitbuilder Closed 01/08/2016

History

#1 Updated by Andrew Schoen almost 4 years ago

When this happens we see jobs fail like this: http://tracker.ceph.com/issues/14307

#2 Updated by Yuri Weinstein almost 4 years ago

  • Related to Bug #14307: ceph package for jewel not found in trusty gitbuilder added

#3 Updated by Andrew Schoen almost 4 years ago

  • Status changed from New to In Progress
  • Assignee set to Andrew Schoen

#4 Updated by Andrew Schoen almost 4 years ago

Pasting a conversation here from #sepia. There is concern that testing with a mix of sha1s per distro would not be ideal.

[10:51:29]  <jcsp>     ah -- so teuthology needs to do it by going straight to github to learn about what sha1s exist, and then poll the builders to learn which sha1s are built, and then make a decision
[10:52:36]  <andrewschoen>     jcsp: can you explain more why "having them (potentially) consist of a mix of versions is kind of scary"?
[10:52:40]  <jcsp>     er
[10:52:46]  <jcsp>     let me run my imagination wild for a second :-)
[10:53:04]      kefu (~kefu@114.92.107.250) left IRC (Max SendQ exceeded)
[10:53:08]  <jcsp>     so when we introduce bugs, I'll get a mixture of buggy and non buggy nodes
[10:53:13]  <yuriw>     *reality is wild !*
[10:53:18]  <jcsp>     and I'll look at the buggy node doing something strange
[10:53:31]      kefu (~kefu@114.92.107.250) joined the channel
[10:53:32]  <jcsp>     and then read the non-buggy node's log and eliminiate some particular failure mode based on its behaviour
[10:53:40]  <jcsp>     unless I *realise* they're running different versions
[10:53:55]  <jcsp>     in which case I have to look at every failure individually rather than ever being able to make generalisations
[10:53:57]  <jcsp>     also
[10:54:13]  <jcsp>     from a practical POV, when I read the code from a given test run, I go look at one config.yaml to see what sha1 it was
[10:54:16]  <jcsp>     and pull up the code
[10:54:24]  <jcsp>     if they're running different versions, I'm flipping back and forth potentially
[10:54:45]  <jcsp>     aaaalso
[10:54:53]  <jcsp>     I might add client vs. server changes in separate commits
[10:54:57]  <jcsp>     and one might depend on the other
[10:55:03]  <jcsp>     it's kind of endless really!
[10:55:24]  <jcsp>     having mixtures of proper, released versions is something that we explicitly test, and we make sure it works inasmuch as we support it
[10:55:35]  <jcsp>     but mixing around commits on master, that's just asking for trouble
[10:55:59]  <jcsp>     *rant over*

Also available in: Atom PDF