<div dir="ltr"><div><div><div><div><div><div><div>Alex,<br><br></div>the problem is that you're working and focusing mostly on release specific code like featuresets and some scripts. But tripleo-quickstart(-extras) and tripleo-ci is much *much* more than set of featuresets. Only 10% of the code may be related to releases and branches, while other 90% is completely independent and not related to releases.<br><br></div>So in 90% code we DO need to backport every change, take for example the latest patch to extras: <a href="https://review.openstack.org/#/c/570167/">https://review.openstack.org/#/c/570167/</a>, it's fixing reproducer. If oooq-extra was branched, we would need to backport this fix to every and every branch. And the same for all other 90% of code, which is complete nonsense. <br></div>Just because not using "{% if release %}" construct - to block the whole work of CI team and make the CI code is absolutely unmaintainable?<br><br></div>Some of release related templates we moved recently from tripleo-ci to THT repo like scenarios, OC templates, etc. If we discover another things in oooq that could be moved to branched THT I'd be only happy for that.<br></div><br>Sometimes it could be hard to maintain one file in extras templates with different logic for releases, like we have in tempest configuration for example. The solution is to create a few release-related templates and use one that match the current branch. It doesn't affect 90% of code and still "branch-like" approach. But I didn't see other scripts that are so release dependent. If we'll have ones, we could do the same. For now I see "{% if release %}" construct working very well.<br><br></div>I didn't see still any advantage of branching CI code, except of a little bit nicer jinja templates without "{% if release ", but amount of disadvantages is so huge, that it'll literally block all current work in CI.<br><br></div>Thanks<br><div><div><br><div><div><div><div><div><div><br></div></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 23, 2018 at 7:04 PM, Alex Schultz <span dir="ltr"><<a href="mailto:aschultz@redhat.com" target="_blank">aschultz@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 Wed, May 23, 2018 at 8:30 AM, Sagi Shnaidman <<a href="mailto:sshnaidm@redhat.com">sshnaidm@redhat.com</a>> wrote:<br>
> Hi, Sergii<br>
><br>
> thanks for the question. It's not first time that this topic is raised and<br>
> from first view it could seem that branching would help to that sort of<br>
> issues.<br>
><br>
> Although it's not the case. Tripleo-quickstart(-extras) is part of CI code,<br>
> as well as tripleo-ci repo which have never been branched. The reason for<br>
> that is relative small impact on CI code from product branching. Think about<br>
> backport almost *every* patch to oooq and extras to all supported branches,<br>
> down to newton at least. This will be a really *huge* price and non<br>
> reasonable work. Just think about active maintenance of 3-4 versions of CI<br>
> code in each of 3 repositories. It will take all time of CI team with almost<br>
> zero value of this work.<br>
><br>
<br>
</span>So I'm not sure I completely agree with this assessment as there is a<br>
price paid for every {%if release in [...]%} that we have to carry in<br>
oooq{,-extras}.  These go away if we branch because we don't have to<br>
worry about breaking previous releases or current release (which may<br>
or may not actually have CI results).<br>
<span class=""><br>
> What regards patch you listed, we would have backport this change to *every*<br>
> branch, and it wouldn't really help to avoid the issue. The source of<br>
> problem is not branchless repo here.<br>
><br>
<br>
</span>No we shouldn't be backporting every change.  The logic in oooq-extras<br>
should be version specific and if we're changing an interface in<br>
tripleo in a breaking fashion we're doing it wrong in tripleo. If<br>
we're backporting things to work around tripleo issues, we're doing it<br>
wrong in quickstart.<br>
<span class=""><br>
> Regarding catching such issues and Bogdans point, that's right we added a<br>
> few jobs to catch such issues in the future and prevent breakages, and a few<br>
> running jobs is reasonable price to keep configuration working in all<br>
> branches. Comparing to maintenance nightmare with branches of CI code, it's<br>
> really a *zero* price.<br>
><br>
<br>
</span>Nothing is free. If there's a high maintenance cost, we haven't<br>
properly identified the optimal way to separate functionality between<br>
tripleo/quickstart.  I have repeatedly said that the provisioning<br>
parts of quickstart should be separate because those aren't tied to a<br>
tripleo version and this along with the scenario configs should be the<br>
only unbranched repo we have. Any roles related to how to<br>
configure/work with tripleo should be branched and tied to a stable<br>
branch of tripleo. This would actually be beneficial for tripleo as<br>
well because then we can see when we are introducing backwards<br>
incompatible changes.<br>
<br>
Thanks,<br>
-Alex<br>
<div class="HOEnZb"><div class="h5"><br>
> Thanks<br>
><br>
><br>
> On Wed, May 23, 2018 at 3:43 PM, Sergii Golovatiuk <<a href="mailto:sgolovat@redhat.com">sgolovat@redhat.com</a>><br>
> wrote:<br>
>><br>
>> Hi,<br>
>><br>
>> Looking at [1], I am thinking about the price we paid for not<br>
>> branching tripleo-quickstart. Can we discuss the options to prevent<br>
>> the issues such as [1]? Thank you in advance.<br>
>><br>
>> [1] <a href="https://review.openstack.org/#/c/569830/4" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/569830/4</a><br>
>><br>
>> --<br>
>> Best Regards,<br>
>> Sergii Golovatiuk<br>
>><br>
>> ______________________________<wbr>______________________________<wbr>______________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Best regards<br>
> Sagi Shnaidman<br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Best regards<br></div>Sagi Shnaidman<br></div></div>
</div>