<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 28, 2017 at 9:50 AM, mathieu bultel <span dir="ltr"><<a href="mailto:mbultel@redhat.com" target="_blank">mbultel@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<span class="gmail-"><br>
<br>
On 09/28/2017 05:05 AM, Emilien Macchi wrote:<br>
> I was reviewing <a href="https://review.openstack.org/#/c/487496/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/487496/</a> and<br>
> <a href="https://review.openstack.org/#/c/487488/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/487488/</a> when I realized that we still<br>
> didn't have any test coverage for minor updates.<br>
> We never had this coverage AFICT but this is not a reason to not push<br>
> forward it.<br>
</span>Thank you for the review and the -2! :)<br>
So I'm agree with you, we need CI coverage for that part, and I was<br>
wondering how I can put quickly a test in CI for the minor update.<br>
But before that, just few things to take in account regarding those reviews:<br>
<br></blockquote><div><br></div><div><div>agree on the need for the ci coverage, but disagree on blocking this. by the same logic we should not have landed anything minor update related during the previous cycle. This is the very last part for <a href="https://bugs.launchpad.net/tripleo/+bug/1715557">https://bugs.launchpad.net/tripleo/+bug/1715557</a> - wiring up the mechanism into client and what's more matbu has managed to do it 'properly' with a tripleo-common mistral action wired up to the tripleoclient cli. <br></div><div><br></div><div>I don't think its right we don't have coverage but I also don't think its right to block these last patches, </div><div><br></div><div>thanks</div></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
1/ Those patches are needed for Pike and we are pretty (pretty, pretty)<br>
late.<br>
The reviews was implemented 2 or 3 weeks ago, but we have made a lot of<br>
tests with both, dev and QE environments (QE more complex and realistic<br>
than dev env or even CI env, Ceph nodes, multi computes and controllers)<br>
to be sure to have something clearly working with less bugs as possible.<br>
I think it is..<br>
<br>
2/ All those patches are touching code which is not (and never) tested<br>
by CI at all... which is bad, but Rome was not built in one day, right ?<br>
;)  No job for config download, no job for minor update, no job for ...<br>
Yes I can iterate, there is a lot of features in TripleO without CI<br>
coverage.<br>
<br>
3/ Config download code has no CI tests at all except unit tests of<br>
course and the minor update "core" feature has been already implemented<br>
and merged. Those reviews are "only" CLI implementations.<br>
<br>
4/ I tried to push unit tests on all parts of the reviews, I think it's<br>
an acceptable tests status for now, to get this landed. Unit tests can<br>
be, in some cases, more relevant than big CI (integration) tests.<br>
<br>
5/ Why, instead of blocking the reviews, not make a follow up review<br>
with the CI coverage ? I know it would be better to make it now, or even<br>
early, but I think it can be sane to just create a blocker LP and<br>
implement the workflow for Master.<br>
<br>
6/ In the mean time, I think we need to work on a workflow for the<br>
future features to implement regarding CI.<br>
Can someone from the CI squad can help to implement new features ? Or<br>
new features only belong to the DFG which creates it ?  (If so, I would<br>
say for Upgrades, hey guys we don't care about upgrading your stuffs, do<br>
it yourself and fix your bugs ;))<br>
<br>
So I understand the concerns but my worries here is that this feature is<br>
needed for Pike and implementing a new job now, will take very long time<br>
and add more delay for the workflow to have it in P.<br>
If the target was for Queens, I would say "yes, lets push a great CI<br>
coverage for this feature".<br>
<br>
Can we make a consensus ?<br>
<span class="gmail-im gmail-HOEnZb"><br>
> During Ocata and Pike, we saw that having upgrade jobs were extremely<br>
> useful to actually test the workflow that our users are supposed to do<br>
> in production, I see zero reason to not doing the same for minor<br>
> updates.<br>
> I don't want to be the bad guy here but i've -2 the 2 patches until we<br>
> find some consensus here (sorry matbu, it's not against you or your<br>
> code in specific, but more generally speaking about re: implementing<br>
> features without CI coverage).<br>
><br>
> I'm really willing to help and start to work on tripleo-quickstart<br>
> roles this week, if someone agrees to pair with me - so we could make<br>
> progress and have that coverage. Even if the new job would fail,<br>
> that's OK we know the process might work (or not, TBH, I haven't tried<br>
> it, probably shardy and some other folks know more about it). Once we<br>
> have the workflow in place, then iterate into matbu's patches and make<br>
> it work in CI so we can ship it and be proud to have the feature<br>
> tested.<br>
> That's IMHO how we should write our software.<br>
><br>
> If there is any feedback on this, please let us know here, otherwise<br>
> I'll keep my -2 until we've got this coverage in place. Also please<br>
> someone (maybe matbu?) raise your hand if you want to pair up and do<br>
> this quickly.<br>
><br>
> Thanks,<br>
<br>
<br>
<br>
</span><div class="gmail-HOEnZb"><div class="gmail-h5">______________________________<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></div></div>