<div dir="ltr">Thank you guys for response.<br>There is no cons, so we migrate validation to separate repo.<div><br></div><div>Best regards,</div><div>Kamil Sambor</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 18, 2015 at 9:34 AM, Evgeniy L <span dir="ltr"><<a href="mailto:eli@mirantis.com" target="_blank">eli@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 dir="ltr">+1 to extract validators for granular deployment tasks<div><br></div><div>Dmitry, do you mean that we should create some cli to generate graph</div><div>picture? Or just make it as a module and then use it in Nailgun?</div><div><br></div><div>Thanks,</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 17, 2015 at 4:31 PM, Dmitriy Shulyak <span dir="ltr"><<a href="mailto:dshulyak@mirantis.com" target="_blank">dshulyak@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 dir="ltr">+1 for separate tasks/graph validation library<div><br></div><div>In my opinion we may even migrate graph visualizer to this library, cause<br></div><div>it is most usefull during development and to demand installed fuel with nailgun feels a bit suboptimal</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Tue, Feb 17, 2015 at 12:58 PM, Kamil Sambor <span dir="ltr"><<a href="mailto:ksambor@mirantis.com" target="_blank">ksambor@mirantis.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div><font face="arial, helvetica, sans-serif">Hi all,</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">I want to discuss separating validation from our repositories to one. On this moment in fuel we have validation for granular deployment tasks in 3 separate repositories so we need to maintain very similar code in all of them. New idea that we discussed with guys assumes to keep this code in one place. Below are more details.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Schema validator should be in separate repo, we will install validator in fuel-plugin, fuel-lib, fuel-nailgun. Validator should support versions (return schemas and validate them for selected version).</font></div><div><font face="arial, helvetica, sans-serif">Reasons why we should have validation in all three repositories:</font></div><div><font face="arial, helvetica, sans-serif">nailgun: we need validation in api because we are able to send our own tasks to nailgun and execute them (now we validate type of tasks in deployment graph and during installation of plugin)</font></div><div><font face="arial, helvetica, sans-serif">fuel-library: we need to check if tasks schema is correct defined in task.yaml files and if tasks not create cycles (actually we do both things)</font></div><div><font face="arial, helvetica, sans-serif">fuel-plugin: we need to check if defined tasks are supported by selected version of nailgun (now we check if task type are the same with hardcoded types in fuel-plugin, we not update this part since a while and now there are only 2 type of tasks: shell and puppet)</font></div><div><font face="arial, helvetica, sans-serif">With versioning we shouldn't have conflicts between nailgun serialization and fuel-plugin because plugin will be able to use schemas for specified version of nailgun.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">As a core reviewers of repositories we should keep the same reviewers as we have in fuel-core.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">How validator should looks like:</font></div><div><font face="arial, helvetica, sans-serif">separate repo, to install using pip</font></div><div><font face="arial, helvetica, sans-serif">need to return correct schema for selected version of fuel</font></div><div><font face="arial, helvetica, sans-serif">should be able to validate schema for selected version and ignore selected fields</font></div><div><font face="arial, helvetica, sans-serif">validate graph from selected tasks</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Pros and cons of this solution:</font></div><div><font face="arial, helvetica, sans-serif">pros:</font></div><div><font face="arial, helvetica, sans-serif">one place to keep validation</font></div><div><font face="arial, helvetica, sans-serif">less error prone - we will eliminate errors caused by not updating one of the repos, also it will be easy to test if changes are correct and compatible with all repos</font></div><div><font face="arial, helvetica, sans-serif">easier to develop (less changes in cases when we add new type of task or we change schemas of tasks - we edit just one place)</font></div><div><font face="arial, helvetica, sans-serif">easy distribution of code between repositories and easy to use by external developers</font></div><div><font face="arial, helvetica, sans-serif">cons:</font></div><div><font face="arial, helvetica, sans-serif">new repository that needs to be managed (and included into CI/QA/release cycle)</font></div><div><font face="arial, helvetica, sans-serif">new dependency for fuel-library, fuel-web, fuel-plugins (fuel plugin builder) of which developer need to be aware of</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Please comments and give opinions.</font></div><div><font face="arial, helvetica, sans-serif"><br></font></div><div><font face="arial, helvetica, sans-serif">Best regards,</font></div><div><font face="arial, helvetica, sans-serif">Kamil Sambor</font></div></div>
<br></div></div>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>