Open Stack

Hi,


On 09/28/2017 05:05 AM, Emilien Macchi wrote:
> I was reviewing https://review.openstack.org/#/c/487496/ and
> https://review.openstack.org/#/c/487488/ when I realized that we still
> didn't have any test coverage for minor updates.
> We never had this coverage AFICT but this is not a reason to not push
> forward it.
Thank you for the review and the -2! :)
So I'm agree with you, we need CI coverage for that part, and I was
wondering how I can put quickly a test in CI for the minor update.
But before that, just few things to take in account regarding those reviews:

1/ Those patches are needed for Pike and we are pretty (pretty, pretty)
late.
The reviews was implemented 2 or 3 weeks ago, but we have made a lot of
tests with both, dev and QE environments (QE more complex and realistic
than dev env or even CI env, Ceph nodes, multi computes and controllers)
to be sure to have something clearly working with less bugs as possible.
I think it is..

2/ All those patches are touching code which is not (and never) tested
by CI at all... which is bad, but Rome was not built in one day, right ?
;)  No job for config download, no job for minor update, no job for ...
Yes I can iterate, there is a lot of features in TripleO without CI
coverage.

3/ Config download code has no CI tests at all except unit tests of
course and the minor update "core" feature has been already implemented
and merged. Those reviews are "only" CLI implementations.

4/ I tried to push unit tests on all parts of the reviews, I think it's
an acceptable tests status for now, to get this landed. Unit tests can
be, in some cases, more relevant than big CI (integration) tests.

5/ Why, instead of blocking the reviews, not make a follow up review
with the CI coverage ? I know it would be better to make it now, or even
early, but I think it can be sane to just create a blocker LP and
implement the workflow for Master.

6/ In the mean time, I think we need to work on a workflow for the
future features to implement regarding CI.
Can someone from the CI squad can help to implement new features ? Or
new features only belong to the DFG which creates it ?  (If so, I would
say for Upgrades, hey guys we don't care about upgrading your stuffs, do
it yourself and fix your bugs ;))

So I understand the concerns but my worries here is that this feature is
needed for Pike and implementing a new job now, will take very long time
and add more delay for the workflow to have it in P.
If the target was for Queens, I would say "yes, lets push a great CI
coverage for this feature".

Can we make a consensus ?

> During Ocata and Pike, we saw that having upgrade jobs were extremely
> useful to actually test the workflow that our users are supposed to do
> in production, I see zero reason to not doing the same for minor
> updates.
> I don't want to be the bad guy here but i've -2 the 2 patches until we
> find some consensus here (sorry matbu, it's not against you or your
> code in specific, but more generally speaking about re: implementing
> features without CI coverage).
>
> I'm really willing to help and start to work on tripleo-quickstart
> roles this week, if someone agrees to pair with me - so we could make
> progress and have that coverage. Even if the new job would fail,
> that's OK we know the process might work (or not, TBH, I haven't tried
> it, probably shardy and some other folks know more about it). Once we
> have the workflow in place, then iterate into matbu's patches and make
> it work in CI so we can ship it and be proud to have the feature
> tested.
> That's IMHO how we should write our software.
>
> If there is any feedback on this, please let us know here, otherwise
> I'll keep my -2 until we've got this coverage in place. Also please
> someone (maybe matbu?) raise your hand if you want to pair up and do
> this quickly.
>
> Thanks,