<p dir="ltr">I don't have a strong opinion about any option, as long as we have something in place I'm happy. </p>
<p dir="ltr">But regarding option 1.A: what would be done for newton once these templates are moved to t-h-t. Would they be backported? What about mitaka?</p>
<div class="gmail_extra"><br><div class="gmail_quote">On 24 Nov 2016 17:55, "Carlos Camacho Gonzalez" <<a href="mailto:ccamacho@redhat.com">ccamacho@redhat.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think would be cool to go with option, +1 to 1.A<br>
<br>
IMHO,<br>
- Easier to read.<br>
- Easier to maintain.<br>
- We don't make backports, instead we guarantee backwards compatibility.<br>
- We'll re-use experience from Puppet OpenStack CI.<br>
<br>
On Wed, Nov 23, 2016 at 10:13 PM, Giulio Fidente <<a href="mailto:gfidente@redhat.com">gfidente@redhat.com</a>> wrote:<br>
> hi Emilien,<br>
><br>
> thanks for putting some thought into this. We have a similar problem to test<br>
> RGW which was only added in Newton.<br>
><br>
><br>
> On 11/23/2016 03:02 AM, Emilien Macchi wrote:<br>
>><br>
>> == Context<br>
>><br>
>> In Newton we added new multinode jobs called "scenarios".<br>
>> The challenged we tried to solve was "how to test the maximum of<br>
>> services without overloading the nodes that run tests".<br>
>><br>
>> Each scenarios deploys a set of services, which allows us to<br>
>> horizontally scale the number of scenarios to increase the service<br>
>> testing coverage.<br>
>> See the result here:<br>
>> <a href="https://github.com/openstack-infra/tripleo-ci#service-testing-matrix" rel="noreferrer" target="_blank">https://github.com/openstack-<wbr>infra/tripleo-ci#service-<wbr>testing-matrix</a><br>
>><br>
>> To implement this model, we took example of Puppet OpenStack CI:<br>
>> <a href="https://github.com/openstack/puppet-openstack-integration#description" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>puppet-openstack-integration#<wbr>description</a><br>
>> We even tried to keep consistent the services/scenarios relations, so<br>
>> it's consistent and easier to maintain.<br>
>><br>
>> Everything was fine until we had to add new services during Ocata cycles.<br>
>> Because tripleo-ci repository is not branched, adding Barbican service<br>
>> in the TripleO environment for scenario002 would break Newton CI jobs.<br>
>> During my vacations, the team created a new scenario, scenario004,<br>
>> that deploys Barbican and that is only run for Ocata jobs.<br>
>> I don't think we should proceed this way, and let me explain why.<br>
>><br>
>> == Problem<br>
>><br>
>> How to scale the number of services that we test without increasing<br>
>> the number of scenarios and therefore the complexity of maintaining<br>
>> them on long-term.<br>
>><br>
>><br>
>> == Solutions<br>
>><br>
>> The list is not exhaustive, feel free to add more.<br>
>><br>
>> 1) Re-use experience from Puppet OpenStack CI and have environments<br>
>> that are in a branched repository.<br>
>> environments.<br>
>> In Puppet OpenStack CI, the repository that deploys environments<br>
>> (puppet-openstack-integration) is branched. So if puppet-barbican is<br>
>> ready to be tested in Ocata, we'll patch<br>
>> puppet-openstack-integration/<wbr>master to start testing it and it won't<br>
>> break stable jobs.<br>
>> Like this, we were successfully able to maintain a fair number of<br>
>> scenarios and keep our coverage increasing over each cycle.<br>
>><br>
>> I see 2 sub-options here:<br>
>><br>
>> a) Move CI environments and pingtest into<br>
>> tripleo-heat-templates/<wbr>environments/ci/(scenarios|<wbr>pingtest). This repo<br>
>> is branched and we could add a README to explain these files are used<br>
>> in CI and we don't guarantee they would work outside TripleO CI tools.<br>
>> b) Branch tripleo-ci repository. Personally I don't like this solution<br>
>> because a lot of patches in this repo are not related to OpenStack<br>
>> versions, which means we would need to backport most of the things<br>
>> from master.<br>
><br>
><br>
> I'd +1 this idea. It sounds like we could make the scenarios generic enough<br>
> to be usable also outside CI? Maybe they can serve as samples?<br>
> --<br>
> Giulio Fidente<br>
> GPG KEY: 08D733BA<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>
<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>
</blockquote></div></div>