8:29 a.m.
Hi all,
See [1]. Pushed it to test [2], and with it it failed as expected [3].
But check-patch didn't fail, and IIUC didn't run any sub-jobs for any
suite, no idea why. I think that's a problem... Any idea?
Thanks,
[1] https://gerrit.ovirt.org/#/c/90922/
[2] https://gerrit.ovirt.org/#/c/90873/
[3]
http://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-tes...
--
Didi
9:27 a.m.
On 6 May 2018 at 16:29, Yedidyah Bar David <didi(a)redhat.com> wrote:
Hi all,
See [1]. Pushed it to test [2], and with it it failed as expected [3].
But check-patch didn't fail, and IIUC didn't run any sub-jobs for any
suite, no idea why. I think that's a problem... Any idea?
This is a known issue with the deployment files - since they are linked to
directly from the suits` 'LagoInitFile's, and not as symlinks in the suits`
directories, STDCI can tell which suits they belong to.
We've discussed this before and decides to make symlinks - but I guess this
wasn't implemented yet. Gal, Daniel - any status update about the
implementation?
--
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
12:53 a.m.
On Sun, May 6, 2018 at 5:27 PM, Barak Korren <bkorren(a)redhat.com> wrote:
On 6 May 2018 at 16:29, Yedidyah Bar David <didi(a)redhat.com> wrote:
>
> Hi all,
>
> See [1]. Pushed it to test [2], and with it it failed as expected [3].
> But check-patch didn't fail, and IIUC didn't run any sub-jobs for any
> suite, no idea why. I think that's a problem... Any idea?
>
This is a known issue with the deployment files - since they are linked to
directly from the suits` 'LagoInitFile's, and not as symlinks in the suits`
directories, STDCI can tell which suits they belong to.
We've discussed this before and decides to make symlinks - but I guess this
wasn't implemented yet. Gal, Daniel - any status update about the
implementation?
Personally I prefer to get rid of all the symlinks.
Each suite should have a configuration file in some format, that lists
what lago init file(s) it uses, what test scenarios it runs, what deploy
scripts, etc.
I realize that I do not have the full picture and that real
life is more complicated. But symlinks are not the solution. symlinks are
designed to _hide_ the fact they are links, not to serve as a configuration
store. Text files do the latter better, imo. They are easier to work with -
easier to read and edit, both manually and by a program, easier to track in
git, etc.
Best regards,
--
Didi
2:31 a.m.
On 7 May 2018 at 08:53, Yedidyah Bar David <didi(a)redhat.com> wrote:
On Sun, May 6, 2018 at 5:27 PM, Barak Korren
<bkorren(a)redhat.com> wrote:
>
>
> On 6 May 2018 at 16:29, Yedidyah Bar David <didi(a)redhat.com> wrote:
>>
>> Hi all,
>>
>> See [1]. Pushed it to test [2], and with it it failed as expected [3].
>> But check-patch didn't fail, and IIUC didn't run any sub-jobs for any
>> suite, no idea why. I think that's a problem... Any idea?
>>
>
> This is a known issue with the deployment files - since they are linked
to
> directly from the suits` 'LagoInitFile's, and not as symlinks in the
suits`
> directories, STDCI can tell which suits they belong to.
>
> We've discussed this before and decides to make symlinks - but I guess
this
> wasn't implemented yet. Gal, Daniel - any status update about the
> implementation?
Personally I prefer to get rid of all the symlinks.
Each suite should have a configuration file in some format, that lists
what lago init file(s) it uses, what test scenarios it runs, what deploy
scripts, etc.
I realize that I do not have the full picture and that real
life is more complicated. But symlinks are not the solution.
I respectfully disagree.
symlinks are
designed to _hide_ the fact they are links,
that is a very poor kind of hiding considering everything shows up in 'ls
-l'
not to serve as a configuration
store.
They have been used for that in many systems including sysV init....
Text files do the latter better, imo. They are easier to work with -
easier to read and edit, both manually and by a program,
Manually - maybe - though 'ln -s' and 'rm' for a specific link can be
easier then navigating a big file
Automatically - hell no - most configuration files require a full blown
parser, and even if your file is simple enough to be reliably processed by
sed and awk, 'ln' and 'rm' are simpler.
easier to track in
git, etc.
Again, nope - putting different things in one file almost guarantees merge
conflicts down the line, these can almost never happen with symlinks.
I think that as a developer used to working with source - you seem to be
prone to the 'with a hammer everything looks like a nail' kind of bias.
What is easy for you to do with your IDE may seem to you to be universally
easy.
But all of this is besides the point - the suits being based on a simple
directory structure had allowed us to leverage simple and generic
pattern-based conditional execution capabilities in STDCI V2 to make
check-patch smartly run things in parallel. Getting this to work if the
configuration was based on some OST-specific format would have been much
harder, and would have probably required additional code both in OST and
STDCI.
--
Barak Korren
RHV DevOps team , RHCE, RHCi
Red Hat EMEA
redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
2540
days inactive
2541
days old
3 comments
2 participants
participants (2)
-
Barak Korren -
Yedidyah Bar David