Thank you guys for response. There is no cons, so we migrate validation to separate repo.
Best regards, Kamil Sambor On Wed, Feb 18, 2015 at 9:34 AM, Evgeniy L <[email protected]> wrote: > +1 to extract validators for granular deployment tasks > > Dmitry, do you mean that we should create some cli to generate graph > picture? Or just make it as a module and then use it in Nailgun? > > Thanks, > > On Tue, Feb 17, 2015 at 4:31 PM, Dmitriy Shulyak <[email protected]> > wrote: > >> +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 >> >> > > __________________________________________________________________________ > 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
