Open Stack

Hi Dmitry,

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.

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.

The only solution which I see is to separate the data from the graph, not
to send
this information to user.

Thanks,

On Thu, Jan 22, 2015 at 5:18 PM, Dmitriy Shulyak <dshulyak at mirantis.com>
wrote:

> Hi guys,
>
> I want to discuss the way we are working with deployment configuration
> that were redefined for cluster.
>
> In case it was redefined by API - we are using that information instead of
> generated.
> With one exception, we will generate new repo sources and path to manifest
> if we are using update (patching feature in 6.0).
>
> Starting from 6.1 this configuration will be populated by tasks, which is
> a part of granular deployment
> workflow and replacement of configuration will lead to inability to use
> partial graph execution API.
> Ofcourse it is possible to hack around and make it work, but imo we need
> generic solution.
>
> Next problem - if user will upload replaced information, changes on
> cluster attributes, or networks, wont be reflected in deployment anymore
> and it constantly leads to problems for deployment engineers that are using
> fuel.
>
> What if user want to add data, and use generated of networks, attributes,
> etc?
> - it may be required as a part of manual plugin installation (ha_fencing
> requires a lot of configuration to be added into astute.yaml),
> - or you need to substitute networking data, e.g add specific parameters
> for linux bridges
>
> So given all this, i think that we should not substitute all information,
> but only part that is present in
> redefined info, and if there is additional parameters they will be simply
> merged into generated info
>
> __________________________________________________________________________
> 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/20150122/3d2e89ef/attachment.html>