<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 7 May 2018 at 08:53, Yedidyah Bar David <span dir="ltr"><<a href="mailto:didi@redhat.com" target="_blank">didi@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, May 6, 2018 at 5:27 PM, Barak Korren <<a href="mailto:bkorren@redhat.com">bkorren@redhat.com</a>> wrote:<br>
><br>
><br>
> On 6 May 2018 at 16:29, Yedidyah Bar David <<a href="mailto:didi@redhat.com">didi@redhat.com</a>> wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> See [1]. Pushed it to test [2], and with it it failed as expected [3].<br>
>> But check-patch didn't fail, and IIUC didn't run any sub-jobs for any<br>
>> suite, no idea why. I think that's a problem... Any idea?<br>
>><br>
><br>
> This is a known issue with the deployment files - since they are linked to<br>
> directly from the suits` 'LagoInitFile's, and not as symlinks in the suits`<br>
> directories, STDCI can tell which suits they belong to.<br>
><br>
> We've discussed this before and decides to make symlinks - but I guess this<br>
> wasn't implemented yet. Gal, Daniel - any status update about the<br>
> implementation?<br>
<br>
</span>Personally I prefer to get rid of all the symlinks.<br>
<br>
Each suite should have a configuration file in some format, that lists<br>
what lago init file(s) it uses, what test scenarios it runs, what deploy<br>
scripts, etc.<br>
<br>
I realize that I do not have the full picture and that real<br>
life is more complicated. But symlinks are not the solution. </blockquote><div><br></div><div>I respectfully disagree.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">symlinks are<br>
designed to _hide_ the fact they are links, </blockquote><div><br></div><div>that is a very poor kind of hiding considering everything shows up in 'ls -l'<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">not to serve as a configuration<br>
store. </blockquote><div><br></div><div>They have been used for that in many systems including sysV init....<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Text files do the latter better, imo. They are easier to work with -<br>
easier to read and edit, both manually and by a program, </blockquote><div><br></div><div>Manually - maybe - though 'ln -s' and 'rm' for a specific link can be easier then navigating a big file<br></div><div>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.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">easier to track in<br>
git, etc.<br></blockquote><div><br></div><div>Again, nope - putting different things in one file almost guarantees merge conflicts down the line, these can almost never happen with symlinks.<br></div><div><br></div><div>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.<br></div></div><br></div><div class="gmail_extra">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.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Barak Korren<br>RHV DevOps team , RHCE, RHCi<br>Red Hat EMEA<br><a href="http://redhat.com" target="_blank">redhat.com</a> | TRIED. TESTED. TRUSTED. | <a href="http://redhat.com/trusted" target="_blank">redhat.com/trusted</a></div>
</div></div>