<div dir="ltr">Every job contains topology file too, like "1cont_1comp" for example. And generally could be different jobs that run the same featureset024 but with different topologies. So I think the topology part is necessary too.<br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 4, 2017 at 8:45 PM, Emilien Macchi <span dir="ltr"><<a href="mailto:emilien@redhat.com" target="_blank">emilien@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Jun 30, 2017 at 11:06 AM, Jiří Stránský <<a href="mailto:jistr@redhat.com">jistr@redhat.com</a>> wrote:<br>
> On 30.6.2017 15:04, Attila Darazs wrote:<br>
>><br>
>> = Renaming the CI jobs =<br>
>><br>
>> When we started the job transition to Quickstart, we introduced the<br>
>> concept of featuresets[1] that define a certain combination of features<br>
>> for each job.<br>
>><br>
>> This seemed to be a sensible solution, as it's not practical to mention<br>
>> all the individual features in the job name, and short names can be<br>
>> misleading (for example ovb-ha job does so much more than tests HA).<br>
>><br>
>> We decided to keep the original names for these jobs to simplify the<br>
>> transition, but the plan is to rename them to something that will help<br>
>> to reproduce the jobs locally with Quickstart.<br>
>><br>
>> The proposed naming scheme will be the same as the one we're now using<br>
>> for job type in project-config:<br>
>><br>
>> gate-tripleo-ci-centos-7-{<wbr>node-config}-{featureset-<wbr>config}<br>
>><br>
>> So for example the current "gate-tripleo-ci-centos-7-ovb-<wbr>ha-oooq" job<br>
>> would look like "gate-tripleo-ci-centos-7-ovb-<wbr>3ctlr_1comp-featureset001"<br>
><br>
><br>
> I'd prefer to keep the job names somewhat descriptive... If i had to pick<br>
> one or the other, i'd rather stick with the current way, as at least for me<br>
> it's higher priority to see descriptive names in CI results than saving time<br>
> on finding featureset file mapping when needing to reproduce a job result.<br>
> My eyes scan probably more than a hundred of individual CI job results<br>
> daily, but i only need to reproduce 0 or 1 job failures locally usually.<br>
><br>
> Alternatively, could we rename "featureset001.yaml" into<br>
> "featureset-ovb-ha.yaml" and then have i guess something like<br>
> "gate-tripleo-ci-centos-7-ovb-<wbr>3ctlr_1comp-ovb-ha" for the job name? Maybe<br>
> "ovb" would be there twice, in case it's needed both in node config and<br>
> featureset parts of the job name...<br>
<br>
</div></div>I'm in favor of keeping jobnames as simple as possible.<br>
To me, we should use something like gate-tripleo-ci-centos-7-ovb-<wbr>featureset001<br>
<br>
So we know:<br>
<br>
- it's a tripleo gate job running on centos7<br>
- it's OVB and not multinode<br>
- it's deploying featureset001<br>
<br>
Please don't mention HA or ceph or other features in the name because<br>
it would be too rigid in case of featureset would change the coverage.<br>
<br>
Note: if we go that way, we also might want to rename scenario jobs<br>
and use featureset in the job name.<br>
Note2: if we rename jobs, we need to keep doing good work on<br>
documenting what featureset deploy and make<br>
<a href="https://github.com/openstack/tripleo-quickstart/blob/master/doc/source/feature-configuration.rst" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>tripleo-quickstart/blob/<wbr>master/doc/source/feature-<wbr>configuration.rst</a><br>
more visible probably.<br>
<br>
My 2 cents.<br>
<span class="im HOEnZb"><br>
> Or we could pull the mapping between job name and job type in an automated<br>
> way from project-config.<br>
><br>
> (Will be on PTO for a week from now, apologies if i don't respond timely<br>
> here.)<br>
><br>
><br>
> Have a good day,<br>
><br>
> Jirka<br>
><br>
>><br>
>> The advantage of this will be that it will be easy to reproduce a gate<br>
>> job on a local virthost by typing something like:<br>
>><br>
>> ./quickstart.sh --release tripleo-ci/master \<br>
>>       --nodes config/nodes/3ctlr_1comp.yml \<br>
>>       --config config/general_config/<wbr>featureset001.yml \<br>
>>       <virthost><br>
>><br>
>> Please let us know if this method sounds like a step forward.<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>
<br>
<br>
</span><span class="HOEnZb"><font color="#888888">--<br>
Emilien Macchi<br>
</font></span><div class="HOEnZb"><div class="h5"><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>