keep_keys: fix keeping all lists, even wrong ones

[gaelgatelement]

SUMMARY

keep_keys since #370 was keeping all lists items, even if there's no match in the key of the list.

ISSUE TYPE

COMPONENT NAME

keep_keys

[softwarefactory-project-zuul]

Build succeeded.
https://ansible.softwarefactory-project.io/zuul/buildset/f7bd8eda78c349ecb5381213fcef5023

✔️ ansible-galaxy-importer SUCCESS in 3m 48s
✔️ build-ansible-collection SUCCESS in 5m 52s

[softwarefactory-project-zuul]

Build succeeded.
https://ansible.softwarefactory-project.io/zuul/buildset/3505ef78098e4704b7a4f53da2fe2c79

✔️ ansible-galaxy-importer SUCCESS in 7m 36s
✔️ build-ansible-collection SUCCESS in 7m 09s

[MPStudyly]

Any progress on this fix? The previous change just blew up our play, as we heavily rely on keep_keys to work as expected. Seeing how breaking code was merged within a few days and the fix lying around over a month is not very promising :/

[roverflow]

@gaelgatelement @MPStudyly We are currently evaluating this. Initially, we had to make a tough decision to implement this change, as there are cases where a greedy approach to retaining keys is necessary. We are now planning to introduce an additional attribute, which will serve as a toggle to enable a non-greedy approach. This should serve all the usecases that are out there. If @gaelgatelement is open to making these adjustments in this PR, we’d greatly appreciate it; otherwise, it may take us some time to release those changes from our end.

[MPStudyly]

@gaelgatelement @roverflow any update on this? We're still stuck on v5.1.0 of this collection due to this change in behavior :/

[gaelgatelement]

Unfortunately I'm now lacking the time to implement the non-greedy version. Surely it's about keeping both keep_keys methods and adding a flag to use one or the other?

[MPStudyly]

Unfortunately I'm now lacking the time to implement the non-greedy version.

Sad to hear :(

Surely it's about keeping both keep_keys methods and adding a flag to use one or the other?

Exactly, we rely on the old behavior to filter data from a structure "dictated" by a role we are relying on. This was conveniently doable with the previous behavior of keep_keys, but isn't anymore as of now.
Besides hoping for soon introduction of the behavior restoring flag, we're actively working in untangling our implementation to hopefully be able to omit this filter all together. The latter is not necessarily done due to the change in its behavior, but because it often is unclear where what info got removed when vars are resolved.