Open Stack

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 <eli at 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 <dshulyak at 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 <ksambor at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150223/50dc1102/attachment.html>