[openstack-dev] [Fuel] Cluster replaced deployment of provisioning information

Evgeniy L eli at mirantis.com
Wed Jan 28 16:52:45 UTC 2015


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 <dshulyak at 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-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/20150128/191ff834/attachment.html>


More information about the OpenStack-dev mailing list