Re: [openstack-dev] [Fuel] Separating granular tasks validator
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 e...@mirantis.com 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 dshul...@mirantis.com 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 ksam...@mirantis.com 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Separating granular tasks validator
+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 dshul...@mirantis.com 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 ksam...@mirantis.com 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Separating granular tasks validator
+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 ksam...@mirantis.com 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
