On Thu, Jan 22, 2015 at 7:59 PM, Evgeniy L <e...@mirantis.com> wrote:
> The problem with merging is usually it's not clear how system performs
> merging.
> For example you have the next hash {'list': [{'k': 1}, {'k': 2}, {'k':
> 3}]}, and I want
> {'list': [{'k': 4}]} to be merged, what system should do? Replace the list
> or add {'k': 4}?
> Both cases should be covered.
>
> What if we will replace based on root level? It feels enough for me.
Most of the users don't remember all of the keys, usually user gets the
> defaults, and
> changes some values in place, in this case we should ask user to remove
> the rest
> of the fields.
>
> And we are not going to force them delete something - if all information
is present than it is what user actually wants.
The only solution which I see is to separate the data from the graph, not
> to send
> this information to user.
>
Probably, i will follow same approach that is used for repo generation,
mainly because it is quite usefull for debuging - to see
how tasks are generated, but it doesnt solves two additional points:
1. There is constantly some data in nailgun becomes invalid just because we
are asking user to overwrite everything
(most common case is allocated ip addresses)
2. What if you only need to add some data, like in fencing plugin? It will
mean that such cluster is not going to be supportable,
what if we will want to upgrade that cluster and new serializer should be
used? i think there is even warning on UI.
__________________________________________________________________________
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
