Merge feature of Console should allow to merge microservices

[flower-of-the-bridges]

Hi

Currently, I'm facing issues with the merge feature provided by the console. I have the following situation:

• feat/microservice-1 where I've added a mongodb-reader
• feat/microservice-2 where I've added an api-gateway

I want to have the mongodb-reader inside the feat/microservice-2 while keeping the api-gateway.
However, the merge tool doesn't provide this option since my only option is to replace their respective configuration.

The merge tool should also allow the user to keep both microservices, instead of replacing one with the other.

[davidebianchi]

Hi @giovf96, you can edit the right editor and copy/paste the mongodbreader configuration from the left editor to have the desired result.
This resolves your needs?

[flower-of-the-bridges]

Yes, that could resolve my needs, but for a user that does not know the console configuration, this operation is not clearly shown by the interface, and also it's something that can be done by any merge editor, so I can't see the benefits of using this feature for such cases

[davidebianchi]

It's shown by any merge editor because it's a difficult logic to add to diff by key.
The benefits is to separate the different resources, and give more feedback about what is changed (a git merge of the configuration is a really pain), do you not agree?
We could think how to improve it in the future, maybe we could separate with one page per different resources in the future. What do you think about?

[flower-of-the-bridges]

Yes, I agree with you that the separation between resources is really useful to better identify what is changed inside the console.
The idea of having a separation inside resources could be helpful to better manage these cases.

For example, in the workload section what can be done is to have a subsection for each microservice. In that case, the interface would have notified me that the merge is introducing a new microservice into the configuration, and then I can choose either to delete it or keep it.

This is a similar behavior that already happens in the Config Map sections, and that can be applied also to workloads end endpoints

[akelity]

This feature has been positively evaluated and may be considered for inclusion in the roadmap in the future, depending on priorities and overall specific needs.