On 7 May 2018 at 08:53, Yedidyah Bar David <didi@redhat.com> wrote:

On Sun, May 6, 2018 at 5:27 PM, Barak Korren <bkorren@redhat.com> wrote:
>
>
> On 6 May 2018 at 16:29, Yedidyah Bar David <didi@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