k8s lookup return a dictionary #9
Comments
|
@jobcespedes Thanks for reporting this issue. I can confirm when there is the only an item returned by API, lookup plugin returns a dictionary. diff --git a/plugins/lookup/k8s.py b/plugins/lookup/k8s.py
index fc4558c..a52f698 100644
--- a/plugins/lookup/k8s.py
+++ b/plugins/lookup/k8s.py
@@ -278,7 +278,11 @@ class KubernetesLookup(K8sAnsibleMixin):
if self.name:
return [k8s_obj.to_dict()]
- return k8s_obj.to_dict().get('items')
+ items = k8s_obj.to_dict().get('items')
+
+ if len(items) == 1:
+ return [items]
+ return itemsI will check if there are any other cases where it returns a dictionary. |
|
@Akasurde the fix will introduce a breaking change from a user perspective. Maybe we can try to target 2.0.0 because of that. |
|
@jobcespedes Could you please confirm if this fix resolves your issue and let me know? Thanks. |
Confirm it returns a list with one item |
Always return list from k8s lookup plugin Fixes: ansible-collections#9 Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com>
Always return list from k8s lookup plugin Fixes: ansible-collections#9 Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com>
Always return list from k8s lookup plugin Fixes: ansible-collections#9 Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com>
Always return list from k8s lookup plugin Fixes: ansible-collections#9 Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com>
Always return list from k8s lookup plugin Fixes: #9 Signed-off-by: Abhijeet Kasurde <akasurde@redhat.com>
|
I reported some issues surrounding this - see: #147 FWIW: I think this issue was incorrect - it said in the description: "Using the k8s lookup, it returns a dictionary. I was expecting a list." You should not expect a list from lookup, you should expect a string. You should expect a list from query. Only if you pass "wantlist=True" should you expect lookup to return a list. At least, that is how I read the ansible docs here: https://docs.ansible.com/ansible/latest/plugins/lookup.html#forcing-lookups-to-return-lists-query-and-wantlist-true Notice it says, Notice it says "default behavior of lookup is to return a string of comma separated values." - thus, lookup should not return a list unless you specify "wantlist=True". The reason for me posting this comment here is - I would like confirmation if my analysis above is correct or if it is wrong in some way. |
|
A list is expected in my interpretation from the k8s lookup docs: https://docs.ansible.com/ansible/latest/collections/community/kubernetes/k8s_lookup.html#return-_list @jmazzitelli I am probably not the best person to confirm whether you are correct or not. However, reading what you shared, it doesn't tell me a lookup plugin should not return a list. ¿Do you think k8s lookup should return a representation of k8s objects in a string of comma separated values? |
Based on that doc you referenced: https://docs.ansible.com/ansible/latest/collections/community/kubernetes/k8s_lookup.html#return-_list it does seem to say it returns a list always. But even today (even with this issue fixed) that is not true. It does not return a list when you use So, I dunno - the documentation conflicts here and the implementation is confused. Based on this page: https://docs.ansible.com/ansible/latest/plugins/lookup.html#forcing-lookups-to-return-lists-query-and-wantlist-true the lookup should not be returning a list by default (without So the behavior of k8s lookup is STILL not returning a list always (e.g. in the case you use It's a big jumble. ...shrug... we'd need someone on the ansible collections team to respond. Something needs to change - the docs, the implementation. I dunno :) |
|
@jobcespedes @jmazzitelli I will work on this and confirm. |
SUMMARY
Using the k8s lookup, it returns a dictionary. I was expecting a list
ISSUE TYPE
COMPONENT NAME
k8s lookup
ANSIBLE VERSION
CONFIGURATION
OS / ENVIRONMENT
Fedora 32
STEPS TO REPRODUCE
EXPECTED RESULTS
A list; even though, there is only one item
ACTUAL RESULTS
A dict. There is only one item
The text was updated successfully, but these errors were encountered: