<div dir="ltr"><div><div><div><div>Hi,<br><br>> pregenerated catalogs for the Noop tests to become the very first<br>> committed state in the data regression process has to be put in the<br>> *separate repo*<br><br></div>+1 to that, we can put this new repo into .fixtures.yml<br><br>> note, we could as well move the tests/noop/astute.yaml/ there<br><br></div>+1 here too, astute.yaml files are basically configuration fixtures, we can put them into .fixtures.yml as well<br><br></div>Regards,<br></div>Alex<br><div><div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 30, 2015 at 1:03 PM, Bogdan Dobrelya <span dir="ltr"><<a href="mailto:bdobrelia@mirantis.com" target="_blank">bdobrelia@mirantis.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 20.11.2015 17:41, Bogdan Dobrelya wrote:<br>
>> Hi,<br>
>><br>
>> let me try to rephrase this a bit and Bogdan will correct me if I'm wrong<br>
>> or missing something.<br>
>><br>
>> We have a set of top-scope manifests (called Fuel puppet tasks) that we use<br>
>> for OpenStack deployment. We execute those tasks with "puppet apply". Each<br>
>> task supposed to bring target system into some desired state, so puppet<br>
>> compiles a catalog and applies it. So basically, puppet catalog = desired<br>
>> system state.<br>
>><br>
>> So we can compile* catalogs for all top-scope manifests in master branch<br>
>> and store those compiled* catalogs in fuel-library repo. Then for each<br>
>> proposed patch CI will compare new catalogs with stored ones and print out<br>
>> the difference if any. This will pretty much show what is going to be<br>
>> changed in system configuration by proposed patch.<br>
>><br>
>> We were discussing such checks before several times, iirc, but we did not<br>
>> have right tools to implement such thing before. Well, now we do :) I think<br>
>> it could be quite useful even in non-voting mode.<br>
>><br>
>> * By saying compiled catalogs I don't mean actual/real puppet catalogs, I<br>
>> mean sorted lists of all classes/resources with all parameters that we find<br>
>> during puppet-rspec tests in our noop test framework, something like<br>
>> standard puppet-rspec coverage. See example [0] for networks.pp task [1].<br>
>><br>
>> Regards,<br>
>> Alex<br>
>><br>
>> [0] <a href="http://paste.openstack.org/show/477839/" rel="noreferrer" target="_blank">http://paste.openstack.org/show/477839/</a><br>
>> [1]<br>
>> <a href="https://github.com/openstack/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular/openstack-network/networks.pp" rel="noreferrer" target="_blank">https://github.com/openstack/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular/openstack-network/networks.pp</a><br>
><br>
> Thank you, Alex.<br>
> Yes, the composition layer is a top-scope manifests, known as a Fuel<br>
> library modular tasks [0].<br>
><br>
> The "deployment data checks", is nothing more than comparing the<br>
> committed vs changed states of fixtures [1] of puppet catalogs for known<br>
> deployment paths under test with rspecs written for each modular task [2].<br>
><br>
> And the *current status* is:<br>
> - the script for data layer checks now implemented [3]<br>
> - how-to is being documented here [4]<br>
> - a fix to make catalogs compilation idempotent submitted [5]<br>
<br>
</div></div>The status update:<br>
- the issue [0] is the data regression checks blocker and is only the<br>
Noop tests specific. It has been reworked to not use custom facts [1].<br>
New uuid will be still generated each time in the catalog, but the<br>
augeas ensures it will be processed in idempotent way. Let's make this<br>
change [2] to the upstream puppet-nova as well please.<br>
<br>
[0] <a href="https://bugs.launchpad.net/fuel/+bug/1517915" rel="noreferrer" target="_blank">https://bugs.launchpad.net/fuel/+bug/1517915</a><br>
[1] <a href="https://review.openstack.org/251314" rel="noreferrer" target="_blank">https://review.openstack.org/251314</a><br>
[2] <a href="https://review.openstack.org/131710" rel="noreferrer" target="_blank">https://review.openstack.org/131710</a><br>
<br>
- pregenerated catalogs for the Noop tests to become the very first<br>
committed state in the data regression process has to be put in the<br>
*separate repo*. Otherwise, the stackalytics would go mad as that would<br>
be a 600k-liner patch to an OpenStack project, which is the Fuel-library<br>
now :)<br>
<br>
So, I'm planning to use the separate repo for the templates. Note, we<br>
could as well move the tests/noop/astute.yaml/ there. Thoughts?<br>
<div class="HOEnZb"><div class="h5"><br>
> - and there is my WIP branch [6] with the initial committed state of<br>
> deploy data pre-generated. So, you can checkout, make any test changes<br>
> to manifests and run the data check (see the README [4]). It works for<br>
> me, there is no issues with idempotent re-checks of a clean committed<br>
> state or tests failing when unexpected.<br>
><br>
> So the plan is to implement this noop tests extention as a non-voting CI<br>
> gate after I make an example workflow update for developers to the<br>
> Fuel wiki. Thoughts?<br>
><br>
> [0]<br>
> <a href="https://github.com/openstack/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular" rel="noreferrer" target="_blank">https://github.com/openstack/fuel-library/blob/master/deployment/puppet/osnailyfacter/modular</a><br>
> [1]<br>
> <a href="https://github.com/openstack/fuel-library/tree/master/tests/noop/astute.yaml" rel="noreferrer" target="_blank">https://github.com/openstack/fuel-library/tree/master/tests/noop/astute.yaml</a><br>
> [2] <a href="https://github.com/openstack/fuel-library/tree/master/tests/noop/spec" rel="noreferrer" target="_blank">https://github.com/openstack/fuel-library/tree/master/tests/noop/spec</a><br>
> [3] <a href="https://review.openstack.org/240015" rel="noreferrer" target="_blank">https://review.openstack.org/240015</a><br>
> [4]<br>
> <a href="https://github.com/openstack/fuel-library/blob/master/tests/noop/README.rst" rel="noreferrer" target="_blank">https://github.com/openstack/fuel-library/blob/master/tests/noop/README.rst</a><br>
> [5] <a href="https://review.openstack.org/247989" rel="noreferrer" target="_blank">https://review.openstack.org/247989</a><br>
> [6] <a href="https://github.com/bogdando/fuel-library-1/commits/data_checks" rel="noreferrer" target="_blank">https://github.com/bogdando/fuel-library-1/commits/data_checks</a><br>
><br>
><br>
<br>
<br>
--<br>
Best regards,<br>
Bogdan Dobrelya,<br>
Irc #bogdando<br>
<br>
__________________________________________________________________________<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.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>