Hi Dmitry!

1. as I mentioned above, we should have an interface, and if interface
doesn't
    provide required information, you will have to fix it in two places,
    in Nailgun and in external-serializers, instead of a single place i.e.
in Nailgun,
    another thing if astute.yaml is a bad interface and we should provide
another
    versioned interface, or add more data into deployment serializer.
2. it can be handled in python or any other code (which can be wrapped into
tasks),
    why should we implement here another entity (a.k.a external
serializers)?

Thanks,

On Wed, Jan 28, 2015 at 2:45 PM, Dmitriy Shulyak <dshul...@mirantis.com>
wrote:

>
>> It's not clear what problem you are going to solve with putting
>> serializers
>> alongside with deployment scripts/tasks.
>>
> I see two possible uses for specific serializer for tasks:
> 1. Compute additional information for deployment based not only on what is
> present in astute.yaml
> 2. Request information from external sources based on values stored in
> fuel inventory (like some token based on credentials)
>
> For sure there is no way for this serializers to have access to the
>> database,
>> because with each release there will be a huge probability to get this
>> serializers broken for example because of changes in database schema.
>> As Dmitry mentioned in this case solution is to create another layer
>> which provides stable external interface to the data.
>> We already to have this interface where we support versioning and backward
>> compatibility, in terms of deployment script it's astute.yaml file.
>>
> That is the problem, it is impossible to cover everything by astute.yaml.
> We need to think on a way to present all data available in nailgun as
> deployment configuration
>
>
>
>
> __________________________________________________________________________
> 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

Reply via email to