+1 for separate tasks/graph validation library In my opinion we may even migrate graph visualizer to this library, cause it is most usefull during development and to demand installed fuel with nailgun feels a bit suboptimal
On Tue, Feb 17, 2015 at 12:58 PM, Kamil Sambor <[email protected]> wrote: > Hi all, > > 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. > > 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). > Reasons why we should have validation in all three repositories: > 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) > 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) > 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) > 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. > > As a core reviewers of repositories we should keep the same reviewers as > we have in fuel-core. > > How validator should looks like: > separate repo, to install using pip > need to return correct schema for selected version of fuel > should be able to validate schema for selected version and ignore selected > fields > validate graph from selected tasks > > Pros and cons of this solution: > pros: > one place to keep validation > 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 > 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) > easy distribution of code between repositories and easy to use by external > developers > cons: > new repository that needs to be managed (and included into CI/QA/release > cycle) > new dependency for fuel-library, fuel-web, fuel-plugins (fuel plugin > builder) of which developer need to be aware of > > Please comments and give opinions. > > Best regards, > Kamil Sambor > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
